“Onze wachtwoorddatabase is gisteren gestolen. Maar maak je geen zorgen: je wachtwoorden zijn versleuteld. " We zien regelmatig uitspraken zoals deze online, inclusief gisteren, van Yahoo . Maar moeten we deze verzekeringen echt op het eerste gezicht aanvaarden?
De realiteit is dat de wachtwoorddatabase in gevaar komt 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, hoe slecht de beveiligingspraktijken van een bedrijf ook zijn.
Hoe wachtwoorden moeten worden opgeslagen
Hier is hoe bedrijven wachtwoorden in een ideale wereld moeten opslaan: u maakt een account aan 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 in te loggen, genereert de service er een hash van en controleert of de hash-waarde overeenkomt met de waarde die is opgeslagen in de database. Op geen enkel moment slaat de service uw wachtwoord zelf op schijf op.
Om uw daadwerkelijke wachtwoord te bepalen, moet een aanvaller met toegang tot de database de hashes voor veelgebruikte wachtwoorden vooraf berekenen 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 vervolgens worden vergeleken met de database. Een aanvaller kent bijvoorbeeld de hash voor "wachtwoord1" en kijkt vervolgens of accounts in de database die hash gebruiken. Als dat het geval is, weet de aanvaller dat zijn wachtwoord “wachtwoord1” is.
Om dit te voorkomen, moeten services hun hashes "salt" maken. In plaats van een hash te maken van het wachtwoord zelf, voegen ze een willekeurige string toe aan de voorkant of het einde van het wachtwoord voordat ze het hashen. Met andere woorden, een gebruiker voert het wachtwoord 'wachtwoord' in en de service voegt de salt en hash een wachtwoord toe dat meer op 'wachtwoord35s2dg' lijkt. Elk gebruikersaccount zou zijn eigen unieke salt moeten hebben, en dit zou ervoor zorgen dat elk gebruikersaccount een andere hash-waarde zou hebben voor hun wachtwoord in de database. Zelfs als meerdere accounts het wachtwoord 'wachtwoord1' hebben gebruikt, zouden ze verschillende hashes hebben vanwege de verschillende salt-waarden. Dit zou een aanvaller verslaan die probeerde hashes voor wachtwoorden vooraf te berekenen. In plaats van hashes te kunnen genereren die in één keer op elk gebruikersaccount in de hele database van toepassing zijn, zouden ze unieke hashes moeten genereren voor elk gebruikersaccount en zijn unieke salt. Dit zou veel meer rekentijd en geheugen vergen.
Daarom zeggen diensten vaak geen zorgen te maken. Een service die de juiste beveiligingsprocedures gebruikt, zou moeten zeggen dat ze gezouten wachtwoord-hashes gebruikten. Als ze gewoon zeggen dat de wachtwoorden 'gehasht' zijn, is dat zorgwekkender. LinkedIn heeft hun wachtwoorden bijvoorbeeld 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
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 lastig te vallen met 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 duidelijk gecompromitteerd. Het maakt niet uit hoe sterk ze waren.
- Hashing de wachtwoorden zonder ze te zouten : Sommige services hashen de wachtwoorden en geven het daar op, en kiezen ervoor om geen salts te gebruiken. Dergelijke wachtwoorddatabases zouden erg kwetsbaar zijn voor opzoektabellen. Een aanvaller zou de hashes voor veel wachtwoorden kunnen genereren en vervolgens kunnen controleren of ze in de database stonden - ze zouden dit voor elk account tegelijk kunnen doen als er geen salt werd gebruikt.
- Zouten hergebruiken : Sommige services gebruiken mogelijk een salt, maar ze kunnen hetzelfde salt gebruiken voor elk gebruikersaccountwachtwoord. Dit heeft geen zin - als voor elke gebruiker hetzelfde salt zou worden gebruikt, zouden twee gebruikers met hetzelfde wachtwoord dezelfde hash hebben.
- Met behulp van korte zouten : Als er zouten van slechts een paar cijfers worden gebruikt, zou het mogelijk zijn om opzoektabellen te genereren die alle mogelijke zout bevatten. Als bijvoorbeeld een enkel cijfer als zout werd gebruikt, zou de aanvaller gemakkelijk lijsten met hashes kunnen genereren die alle mogelijke salt bevatten.
Bedrijven vertellen je niet altijd het hele verhaal, dus zelfs als ze zeggen dat een wachtwoord is gehasht (of gehasht en gezouten), gebruiken ze mogelijk niet de best practices. Wees altijd voorzichtig.
Andere zorgen
De salt-waarde is waarschijnlijk ook aanwezig in de wachtwoorddatabase. Dit is niet zo erg: als er voor elke gebruiker een unieke salt-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 is om de wachtwoorden van veel gebruikersaccounts te achterhalen. Als een aanvaller bijvoorbeeld uw hash kent en hij of zij uw salt kent, kan hij gemakkelijk controleren of u enkele van de meest voorkomende wachtwoorden gebruikt.
VERWANT: Hoe aanvallers online accounts "hacken" en hoe u uzelf kunt beschermen
Als een aanvaller het voor je heeft en je wachtwoord wil kraken, kan hij dat met brute kracht doen, zolang hij de zoutwaarde kent - wat hij waarschijnlijk ook doet. Met lokale, offline toegang tot wachtwoorddatabases kunnen aanvallers alle bruut gebruiken aanvallen forceren zij 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 - die, zoals we allemaal weten, het gemakkelijker maken 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 ten eerste wachtwoorden niet opnieuw op meerdere websites. Gebruik een wachtwoordbeheerder die voor elke website unieke wachtwoorden genereert . Als een aanvaller ontdekt dat uw wachtwoord voor een service '43 ^ tSd% 7uho2 # 3' is en u dat wachtwoord alleen op die ene specifieke website gebruikt, hebben ze niets nuttigs geleerd. Als u overal hetzelfde wachtwoord gebruikt, kunnen ze toegang krijgen tot uw andere accounts. Dit is hoeveel accounts van mensen worden 'gehackt'.
Als een service toch gecompromitteerd raakt, moet u het wachtwoord dat u daar gebruikt, wijzigen. U moet het wachtwoord ook op andere sites wijzigen als u het daar opnieuw gebruikt, maar dat zou u in de eerste plaats niet moeten doen.
U moet ook overwegen met behulp van tweefactorauthenticatie , die u zelfs zal beschermen als een aanvaller uw wachtwoord ontdekt.
VERWANT: Waarom u een wachtwoordbeheerder moet gebruiken en hoe u aan de slag kunt gaan
Het belangrijkste is om wachtwoorden niet opnieuw te gebruiken. 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.
Afbeelding tegoed: Marc Falardeau on Flickr , Wikimedia Commons
