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 uitspraken zoals deze online, inclusief gisteren, van Yahoo. Maar moeten we echt die garanties echt voor ogen houden?

De realiteit is dat wachtwoorddatabase-compromissen met een zorg van zijn, ongeacht hoe een bedrijf het kan proberen 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

Zo moeten bedrijven wachtwoorden 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 zou bijvoorbeeld de hash voor "wachtwoord 1" kennen en vervolgens zien of sommige accounts in de database die hash gebruiken. Als dat zo 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 gebruikersaccountzou een andere hash-waarde hebben voor hun wachtwoord in de database. Zelfs als meerdere accounts het wachtwoord "wachtwoord 1" gebruiken, hebben ze verschillende hashes vanwege de verschillende zoutwaarden. Dit zou een aanvaller verslaan die hashes probeert te berekenen 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 met de juiste beveiligingsprocedures zou moeten 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 in 2012 verloor.

Bad Password Practices

Dit is niet het moeilijkste om te implementeren, maar veel websiteskan het op verschillende manieren nog steeds verprutsen:

• Wachtwoorden opslaan in platte tekst : in plaats van hashing met hashing, kunnen sommige van de ergste daders de wachtwoorden gewoon in gewone tekst in een database dumpen. Als een dergelijke database in gevaar wordt gebracht, zijn uw wachtwoorden duidelijk aangetast. Het maakt niet uit hoe sterk ze waren.
• Hashing van de wachtwoorden zonder ze te zouten : Sommige services hashen de wachtwoorden en geven daar op, omdat ze ervoor kiezen 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 in de database aanwezig waren - ze zouden dit voor elk account tegelijk kunnen doen als er geen zout werd gebruikt.
• Zouten hergebruiken : Sommige services gebruiken mogelijk een zout, maar ze kunnen hetzelfde zout 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 zoutzouten gebruiken : als 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 u niet altijd het hele verhaal vertellen, dus zelfs als ze zeggen dat een wachtwoord hashed( hashed and salted) is, gebruiken ze mogelijk niet de best practices. Houd altijd een zekere voorzichtigheid aan de kant.

Andere zorgen

Waarschijnlijk is de zoutwaarde ook aanwezig in de wachtwoorddatabase. Dit is niet zo erg - 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 zo veel 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 brute kracht 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 dienst "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. Dit is het aantal gehackte accounts van mensen.

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