Waarom u zich zorgen moet maken wanneer de wachtwoorddatabase van een service wordt gelekt

Inhoudsopgave:

Waarom u zich zorgen moet maken wanneer de wachtwoorddatabase van een service wordt gelekt
Waarom u zich zorgen moet maken wanneer de wachtwoorddatabase van een service wordt gelekt
Anonim

Om uw werkelijke wachtwoord te bepalen, moet een aanvaller met toegang tot de database de hashes voor veelgebruikte wachtwoorden vooraf berekenen en vervolgens controleren of ze in de database voorkomen. Aanvallers doen dit met opzoektabellen: enorme lijsten met hashes die overeenkomen met wachtwoorden. De hashes kunnen dan worden vergeleken met de database. Een aanvaller zou bijvoorbeeld de hash voor "wachtwoord1" kennen en vervolgens kijken of accounts in de database die hash gebruiken. Als dat zo is, weet de aanvaller dat hun wachtwoord "wachtwoord1" is.

Om dit te voorkomen, moeten services hun hashes "zouten".In plaats van een hash van het wachtwoord zelf te maken, voegen ze een willekeurige string toe aan de voorkant of het einde van het wachtwoord voordat ze het hashen. Met andere woorden, een gebruiker zou het wachtwoord "wachtwoord" invoeren en de service zou het zout toevoegen en een wachtwoord hashen dat meer op "password35s2dg" lijkt. Elk gebruikersaccount zou zijn eigen unieke s alt moeten hebben, en dit zou ervoor zorgen dat elk gebruikersaccount een andere hashwaarde voor hun wachtwoord in de database zou hebben. Zelfs als meerdere accounts het wachtwoord "password1" zouden gebruiken, zouden ze verschillende hashes hebben vanwege de verschillende zoutwaarden. Dit zou een aanvaller verslaan die probeerde hashes vooraf te berekenen voor wachtwoorden. In plaats van hashes te kunnen genereren die van toepassing zijn op elk gebruikersaccount in de hele database in één keer, zouden ze unieke hashes moeten genereren voor elk gebruikersaccount en zijn unieke s alt. Dit zou veel meer rekentijd en geheugen kosten.

Dit is de reden waarom diensten vaak zeggen dat je je geen zorgen hoeft te maken. Een service die de juiste beveiligingsprocedures gebruikt, zou moeten zeggen dat ze gezouten wachtwoordhashes gebruikten.Als ze simpelweg zeggen dat de wachtwoorden "gehasht" zijn, is dat zorgwekkender. LinkedIn heeft bijvoorbeeld hun wachtwoorden gehasht, maar ze hebben ze niet gezouten - dus het was een groot probleem toen LinkedIn in 2012 6,5 miljoen gehashte wachtwoorden verloor.

Slechte wachtwoordpraktijken

Afbeelding

Dit is niet het moeilijkste om te implementeren, maar veel websites slagen er nog steeds in om het op verschillende manieren te verknoeien:

  • Wachtwoorden in platte tekst opslaan: In plaats van zich druk te maken over hashing, kunnen sommige van de ergste overtreders de wachtwoorden gewoon in platte tekst in een database dumpen. Als een dergelijke database wordt gecompromitteerd, zijn uw wachtwoorden uiteraard gecompromitteerd. Het maakte niet uit hoe sterk ze waren.
  • De wachtwoorden hashen zonder ze te s alten: Sommige diensten kunnen de wachtwoorden hashen en daar opgeven, en ervoor kiezen geen s alts te gebruiken. Dergelijke wachtwoorddatabases zouden erg kwetsbaar zijn voor opzoektabellen.Een aanvaller kan de hashes voor veel wachtwoorden genereren en vervolgens controleren of ze in de database aanwezig zijn - ze kunnen dit voor elk account tegelijk doen als er geen s alt is gebruikt.
  • Hergebruik van S alts: Sommige diensten kunnen een s alt gebruiken, maar ze kunnen dezelfde s alt opnieuw gebruiken voor elk wachtwoord van een gebruikersaccount. Dit is zinloos - als dezelfde s alt voor elke gebruiker zou worden gebruikt, zouden twee gebruikers met hetzelfde wachtwoord dezelfde hash hebben.
  • Korte zouten gebruiken: Als zouten van slechts een paar cijfers worden gebruikt, zou het mogelijk zijn om opzoektabellen te genereren die alle mogelijke zouten bevatten. Als bijvoorbeeld een enkel cijfer als een zout zou worden gebruikt, zou de aanvaller gemakkelijk lijsten met hashes kunnen genereren waarin elk mogelijk zout is verwerkt.

Bedrijven vertellen je niet altijd het hele verhaal, dus zelfs als ze zeggen dat een wachtwoord gehasht is (of gehasht en gezouten), gebruiken ze misschien niet de best practices. Wees altijd voorzichtig.

Andere zorgen

Het is waarschijnlijk dat de s alt-waarde ook aanwezig is in de wachtwoorddatabase. Dit is niet zo erg: als voor elke gebruiker een unieke s alt-waarde zou worden gebruikt, zouden de aanvallers enorme hoeveelheden CPU-kracht moeten besteden aan het breken van al die wachtwoorden.

In de praktijk gebruiken zoveel mensen voor de hand liggende wachtwoorden dat het waarschijnlijk gemakkelijk zou zijn om de wachtwoorden van veel gebruikersaccounts te achterhalen. Als een aanvaller bijvoorbeeld uw hash kent en zij uw s alt, kunnen ze eenvoudig controleren of u enkele van de meest voorkomende wachtwoorden gebruikt.

Als een aanvaller het voor je heeft en je wachtwoord wil kraken, kunnen ze dat met brute kracht doen zolang ze de zoutwaarde kennen - wat ze waarschijnlijk ook doen. Met lokale, offline toegang tot wachtwoorddatabases kunnen aanvallers alle brute force-aanvallen gebruiken die ze willen.

Andere persoonlijke gegevens lekken waarschijnlijk ook wanneer een wachtwoorddatabase wordt gestolen: gebruikersnamen, e-mailadressen en meer. In het geval van het Yahoo-lek zijn ook beveiligingsvragen en -antwoorden gelekt, wat het, zoals we allemaal weten, gemakkelijker maakt om toegang tot iemands account te stelen.

Help, wat moet ik doen?

Wat een service ook zegt wanneer zijn wachtwoorddatabase wordt gestolen, het is het beste om aan te nemen dat elke service volledig incompetent is en dienovereenkomstig te handelen.

Gebruik wachtwoorden niet opnieuw op meerdere websites. Gebruik een wachtwoordbeheerder die voor elke website unieke wachtwoorden genereert. Als een aanvaller erachter komt dat uw wachtwoord voor een service "43^tSd%7uho23" is en u dat wachtwoord alleen op die ene specifieke website gebruikt, hebben ze niets nuttigs geleerd. Als je overal hetzelfde wachtwoord gebruikt, kunnen ze toegang krijgen tot je andere accounts. Dit is hoeveel accounts van mensen 'gehackt' worden.

Afbeelding

Als een service gecompromitteerd raakt, moet u het wachtwoord wijzigen dat u daar gebruikt. U moet het wachtwoord ook op andere sites wijzigen als u het daar opnieuw gebruikt, maar u zou dat in de eerste plaats niet moeten doen.

Je zou ook moeten overwegen om twee-factor-authenticatie te gebruiken, die je zal beschermen, zelfs als een aanvaller je wachtwoord te weten komt.

Het belangrijkste is dat je wachtwoorden niet opnieuw gebruikt. Gecompromitteerde wachtwoorddatabases kunnen u geen kwaad doen als u overal een uniek wachtwoord gebruikt - tenzij ze iets anders belangrijks in de database opslaan, zoals uw creditcardnummer.

Populair onderwerp