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

"Onze wachtwoorddatabase is gisteren gestolen. Maar maak je geen zorgen: je wachtwoorden zijn gecodeerd. "Regelmatig zien we dergelijke uitspraken online, inclusief gisteren, van Yahoo. Maar moeten we echt die garanties echt voor ogen houden?

De realiteit is dat wachtwoorddatabase een compromis vormt zijn een punt van zorg, hoe een bedrijf het ook probeert te draaien. Maar er zijn een paar dingen die u kunt doen om uzelf te isoleren, ongeacht hoe slecht de beveiligingspraktijken van een bedrijf zijn.

Hoe wachtwoorden moeten worden opgeslagen

Hier leest u hoe bedrijven wachtwoorden moeten opslaan in een ideale wereld: u maakt een account en geeft een wachtwoord op. In plaats van het wachtwoord zelf op te slaan, genereert de service een "hash" van het wachtwoord. Dit is een unieke vingerafdruk die niet kan worden teruggedraaid. Het wachtwoord "wachtwoord" kan bijvoorbeeld veranderen in iets dat meer lijkt op "4jfh75to4sud7gh93247g ...". Wanneer u uw wachtwoord invoert om u aan te melden, genereert de service een hash en controleert of de hash-waarde overeenkomt met de waarde die in de database is opgeslagen. Op geen enkel punt bewaart de service ooit uw wachtwoord zelf op schijf.

Om uw werkelijke wachtwoord te bepalen, moet een aanvaller met toegang tot de database de hashes vooraf berekenen voor veelvoorkomende wachtwoorden en vervolgens controleren of deze 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 weet bijvoorbeeld de hash voor "wachtwoord 1" en ziet vervolgens of accounts in de database die hash gebruiken. Als dat het geval is, weet de aanvaller dat hun wachtwoord "wachtwoord1" is.

Om dit te voorkomen, dienen diensten hun hashes te "zouten". In plaats van een hash te maken van het wachtwoord zelf, voegen ze een willekeurige reeks toe aan de voorkant of het einde van het wachtwoord voordat het hashing. Met andere woorden, een gebruiker zou het wachtwoord "wachtwoord" invoeren en de service zou het zout en hash een wachtwoord toevoegen dat meer op "wachtwoord35s2dg" lijkt. Elke gebruikersaccount zou zijn eigen unieke zout moeten hebben, en dit zou ervoor zorgen dat elk gebruikersaccount zou een andere hash-waarde voor hun wachtwoord in de database hebben. Zelfs als meerdere accounts het wachtwoord "wachtwoord 1" gebruiken, hebben ze verschillende hashes vanwege de verschillende zoutwaarden. Dit zou een aanvaller verslaan die probeerde hashes te pre-compute voor wachtwoorden. In plaats van hashes te kunnen genereren die in elke database in één keer op alle gebruikersaccounts van toepassing waren, moesten ze unieke hashes genereren voor elke gebruikersaccount en zijn unieke salt. Dit zou veel meer rekentijd en geheugen kosten.

Daarom zeggen diensten vaak dat ze zich geen zorgen moeten maken. Een service die gebruik maakt van de juiste beveiligingsprocedures moet zeggen dat ze gezoete wachtwoord hashes gebruikten. Als ze gewoon zeggen dat de wachtwoorden 'gehasht' zijn, is dat zorgwekkender. LinkedIn hashed hun wachtwoorden, bijvoorbeeld, maar ze hebben ze niet gezouten, dus het was een grote deal toen LinkedIn 6,5 miljoen hash-wachtwoorden verloor in 2012.

Slechte wachtwoordpraktijken

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

• Wachtwoorden opslaan in platte tekst: In plaats van zich druk te maken over hashing, kunnen sommige van de ergste overtreders de wachtwoorden gewoon in gewone tekst in een database dumpen. Als een dergelijke database wordt aangetast, komen uw wachtwoorden duidelijk in gevaar. Het maakt niet uit hoe sterk ze waren.
• Hashing de wachtwoorden zonder ze te zegenen: Sommige services kunnen de wachtwoorden hashen en opgeven en kiezen ervoor om geen zouten te gebruiken. Dergelijke wachtwoorddatabases zouden erg kwetsbaar zijn voor opzoektabellen. Een aanvaller kan de hashes voor veel wachtwoorden genereren en vervolgens controleren of ze al in de database aanwezig waren - ze zouden dit voor elk account in één keer kunnen doen als er geen zout werd gebruikt.
• Zouten hergebruiken: Sommige services gebruiken mogelijk een salt, maar ze kunnen hetzelfde salt hergebruiken voor elk gebruikersaccountwachtwoord. Dit is zinloos - als hetzelfde zout voor elke gebruiker zou worden gebruikt, zouden twee gebruikers met hetzelfde wachtwoord dezelfde hash hebben.
• Korte zouten gebruiken: Als er zouten van slechts enkele cijfers worden gebruikt, is het mogelijk om opzoektabellen te genereren die elk mogelijk zout bevatten. Als een enkel cijfer bijvoorbeeld als zout zou worden gebruikt, zou de aanvaller eenvoudig lijsten met hashes kunnen genereren waarin elk mogelijk zout is verwerkt.

Bedrijven zullen je niet altijd het hele verhaal vertellen, dus zelfs als ze zeggen dat een wachtwoord hashed (hashed and salted) is, gebruiken ze misschien niet de beste werkwijzen. Wees altijd voorzichtig.

Andere zorgen

Waarschijnlijk is de zoutwaarde ook aanwezig in de wachtwoorddatabase. Dit is niet zo slecht - als een unieke zoutwaarde voor elke gebruiker zou worden gebruikt, zouden de aanvallers enorme hoeveelheden CPU-kracht moeten gebruiken om al die wachtwoorden te verbreken.

In de praktijk gebruiken zoveel mensen voor de hand liggende wachtwoorden dat het waarschijnlijk eenvoudig is om de wachtwoorden van veel gebruikersaccounts te bepalen. Als een aanvaller bijvoorbeeld uw hash kent en zij uw zout kennen, 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 het met bruut geweld doen, zolang ze de zoutwaarde weten - wat ze waarschijnlijk 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, zoals we allemaal weten, het gemakkelijker maken om de toegang tot iemands account te stelen.

Hulp, wat moet ik doen?

Wat een service ook zegt als de wachtwoorddatabase wordt gestolen, het is het beste om te veronderstellen dat elke service volledig incompetent is en dienovereenkomstig te handelen.

Ten eerste, hergebruik geen wachtwoorden op meerdere websites. Gebruik een wachtwoordbeheerder die unieke wachtwoorden genereert voor elke website. Als een aanvaller erachter komt dat uw wachtwoord voor een service "43 ^ tSd% 7uho2 # 3" is en u gebruikt dat wachtwoord alleen op die ene specifieke website, hebben ze niets nuttigs geleerd. Als u overal hetzelfde wachtwoord gebruikt, kunnen ze toegang krijgen tot uw andere accounts. Op deze manier worden de accounts van veel mensen 'gehackt'.

Als een service in gevaar komt, moet u het wachtwoord wijzigen dat u daar gebruikt. Je moet ook het wachtwoord op andere sites wijzigen als je het daar opnieuw gebruikt - maar dat zou je in de eerste plaats niet moeten doen.

U moet ook overwegen om tweefactorauthenticatie te gebruiken, die u zelfs beschermt als een aanvaller uw wachtwoord ontdekt.

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

Image Credit: Marc Falardeau op Flickr, Wikimedia Commons