"SHA-1 met salt onvoldoende voor wachtwoorden"
Het gebruik van het SHA-1 hashingalgoritme met een salt is niet voldoende voor het beschermen van wachtwoorden, zoals de recente hack van beveiligingsbedrijf HBGary en rootkit.com heeft laten zien. Rootkit.com werd gehackt omdat het de website is van de eigenaar van HBGary. Een werknemer van dit bedrijf wilde informatie over kernleden van Anonymous aan de FBI verkopen, waarop de anonieme internetbeweging terugsloeg.
Veel websites gebruiken MD5, SHA1 of SHA-256 om wachtwoorden van gebruikers te hashen. "Verlichte ontwikkelaars 'salten' zelfs het wachtwoord. De afgelopen jaren waren er verhitte discussies over het genereren van salt-waarden en hoe lang ze zouden moeten zijn", zegt Jarno Niemelä van het Finse F-Secure. Volgens hem vergeten veel mensen het feit dat MD en SHA hashes ontwikkeld zijn voor rekenkracht, en de kwaliteit van de salt-waarden niet veel uitmaakt als een aanvaller volledige controle over de server heeft, zoals met rootkit.com gebeurde. "Als een aanvaller root-toegang heeft, hebben ze je wachtwoorden, salt en de code die je gebruikt om de wachtwoorden te verifiëren."
Niemelä benadrukt dat elk security-ontwerp gebaseerd moet zijn op een scenario waarbij de aanvaller volledige toegang tot alles op de server heeft. Het salten van wachtwoorden moet vooral vooraf berekende aanvallen via rainbow tables voorkomen. "En lang werd aangenomen dat zolang vooraf berekende aanvallen waren te voorkomen, de wachtwoorden relatief veilig waren, zelfs als de aanvaller de salt-waarden samen met het wachtwoord in handen kreeg."
Videokaart
Een aanvaller kan via moderne videokaarten echter miljarden brute-force pogingen per seconden uitvoeren. Met een enkele ATI HD 5970 videokaart kan een aanvaller in 33 dagen alle wachtwoorden dekken die gelijkstaan aan een rainbow table (2^52.5 hashes). Daarbij zal een aanvaller over meerdere kaarten beschikken en wordt de tijd dus steeds korter.
De sterkte van de wachtwoorden is dan ook het enige dat de accounts kan beschermen. Helaas kiezen de meeste mensen een zwak wachtwoord. "Door woordenboek en brute-force-aanvallen te combineren, zal het niet lang duren om een groot aantal wachtwoorden te kraken, zelfs op een grote site met veel accounts."
Oplossing
Niemelä vergelijkt wachtwoorden met een kluis, waarbij niet de lengte van de code die nodig is om de kluis open te breken belangrijk is, maar hoe lang elke poging duurt. "Dit onderstreept dat SHA-1 of een andere plat hashingalgoritme voor veilige wachtwoord-authenticatie ongeschikt is." In plaats van SHA-1 zouden websites dan ook oplossingen zoals PBKDF2, Bcrypt of PBMAC moeten kiezen.
Grtz
Met alleen hoofd- kleine letters en cijfers heb je 2log(26+26+10)=5,9 bits per teken. En kom je op een lengte van 9 tekens.
Als je wachtwoord makkelijk 'te onthouden' is moet je veel langere teken reeksen hebben om hier enige bescherming tegen te bereiken.
9 tekens. Er zijn 26 kleine letters, 26 hoofdletters en 10 cijfers. Geeft in totaal 62 mogelijke karakters per wachtwoord teken. Wat we dan uit moeten rekenen is
62^x = 2^52.5
Dat is een standaard logaritme som die x = 8.8 als resultaat geeft. Afronden geeft 9 tekens. Ga er maar vanuit dat 97% van de gebruikers een wachtwoord kiest dat minder lang is.
Verder is het ook in opmars om het wachtwoord (ala HMAC) tig-duizend keer te hashen, waarbij er elke keer een deel van de hash als salt voor de volgende hash gebruikt wordt (bijvoorbeeld).
Voor een enkelvoudige berekening (verifiëren wachtwoord) stelt dit niets voor (zelf hanteer ik momenteel standaard 10.000x, maar even gemakkelijk kan dit 100.000 of nog vaker) en is de vertraging voor de gebruiker onmerkbaar.
Voor een aanvaller is dat een heel ander verhaal, de efficiëntie van zijn aanval neemt (in mijn geval) met 10.000x af en het zal dus 10.000 * 33 = 330.000 dagen = 904 jaar (met huidige snelheid hardware) duren voordat een wachtwoord van 7 of 8 karakters gebruteforced is of er rainbowtables aangemaakt zijn voor een wachtwoord. En uiteraard is de salt per wachtwoord verschillend, dus is het effectief zinloos om te doen.
Dus als je 62 leestekens toevoegt aan je set van 62 cijfers/letters, dan krijg je er een enkele bit bij. Dus 6,9 bit entropie per teken in plaats van 5,9 bit per teken. Niet erg indrukwekkend dus.
Plus het gelazer dat je krijgt als mensen opeens een andere toetsenbordindeling gaan gebruiken (zonder dit te weten). Of mensen die dit al deden toen ze voor het eerst hun wachtwoord aanmaakten (moeilijk te achterhalen).
Nee, die ben ik niet vergeten mee te tellen. De vraag van de eerste anonieme poster richtte zich op het gebruik van letters en cijfers. En dat zijn er maar 62. Als leestekens mee worden genomen, dan kom je op een toetsenbord zoals ik voor me heb liggen uit op 32 extra tekens. Geen idee hoe bepaalde applicaties omgaan met "Alt-xxx" tekens, maar veel rainbow tables hebben letters en tekens zoals ï, €, ê en ë niet in hun alfabet zitten. Daarom zeg ik: het wachtwoord "ä" is veiliger dan een random wachtwoord van 8 karakters :o).
Voorwaarde: het resultaat en paramters zoals salt van die one-way functie moet beschikbaar zijn.
In unix hadden we een publieke db met die elementen, tot men de "shadow" db hebben ingevoerd om dit tegen te gaan.
Dat is en blijft tegenmaatregel 1: bescherm die informatie en al zeker heel de db.
Dit is een mooi voorbeeld van bescherming van cryptografisch "publieke" data: cryptografisch reken je er niet op dat die gegevens niet gekend zijn, maar als de informatie beschermd is, is dat nog beter.
Een ander voorbeeld: publiek-privé sleutels. Cryptografisch wordt er niet op gerekend dat de publieke niet gekend is. Wanneer Jan naar Piet een sleutel stuurt beschermd met de publieke sleutel van Piet is het lastiger om die sleutel te vinden als ik zelfs de "publieke" sleutel niet ken. Je bemoeilijkt brute force. Pluspunten voor SSH en PGP.
Het advies om beter te doen vind ik maar zozo.
Bij zwakke paswoorden een sterke hash gebruiken? Maakt niet zoveel uit.
Tijdsvertraging inbouwen? In een grotere organizatie gaat de authentication server kreunen.
Encrypite ipv hash? Zou ik nog over denken.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
