IBM onthult oplossing voor veilig gebruik van wachtwoorden
Deze week onthulde Yahoo inloggen zonder wachtwoord en onlangs sloot de Duitse overheid zich aan bij een internationale alliantie tegen wachtwoorden, maar wachtwoorden zijn wel veilig, we gebruiken ze alleen verkeerd en IBM heeft de oplossing, aldus Anja Lehmann, cryptografe bij 'Big Blue'.
Lehmann doelt bij het verkeerd gebruik niet op de eindgebruiker, maar op de website of partij die het wachtwoord moet controleren. Geen week gaat voorbij zonder dat er een gehackte website in het nieuws komt. Dit is volgens de cryptografe de grootste dreiging voor de veiligheid van wachtwoorden. Veel websites slaan de wachtwoorden van hun gebruikers niet in platte tekst op, maar de server moet toch iets opslaan om te bepalen of het wachtwoord correct is. Vaak gaat het om een hash van het wachtwoord. Als een aanvaller de hash in handen heeft kan hij eindeloos proberen die te 'kraken' en zo het bijbehorende wachtwoord te achterhalen.
Door het kiezen van een veilig wachtwoord wordt het lastiger voor de aanvaller om de hash te kraken en zo het wachtwoord te achterhalen. Volgens Lehmann kunnen moderne wachtwoordkrakers tegenwoordig meer dan 300 miljard wachtwoorden per seconde kraken, waardoor bijvoorbeeld een wachtwoord van 16 karakters ook snel sneuvelt. Nu is dit wel afhankelijk van de hash die wordt gebruikt, maar uit gelekte databases blijkt dat veel mensen korte wachtwoorden van bijvoorbeeld 8 karakters kiezen.
Enkele server
Het probleem met wachtwoorden is dan ook dat als er een enkele server is die bepaalt of het wachtwoord correct is en die server wordt gehackt, het wachtwoord niet meer veilig is, zo stelt Lehmann. De oplossing die ze voorstelt is om de informatie voor het controleren van het wachtwoord over meerdere servers te verdelen. Dit houdt in dat alle servers moeten samenwerken om te bepalen of het wachtwoord correct is of niet. De aanvaller moet nu al deze servers zien te hacken om de wachtwoorden te kunnen achterhalen.
"Dit kan extreem lastig worden gemaakt door de servers op verschillende locaties en met verschillende besturingssystemen te laten draaien, waarbij ze ook nog eens door verschillende systeembeheerders worden gemonitord", aldus Lehmann. Deze week presenteerde ze een nieuw verificatieprotocol (pdf) voor gedistribueerde wachtwoordverificatie, dat volgens haar zeer efficiënt en veilig is en bedrijven eigenlijk geen excuus meer geeft om ooit nog wachtwoorden van gebruikers door een gehackte server te verliezen.
Dan kun je ook nog wachtwoorden na wijzigen random uit een pool van verschillende sterke algoritmes er eentje laten toepassen zodat het algoritme ook constant veranderd.
Dan nog een soort sleutelhanger met een lcd en self destruct chip voor mensen met een slecht geheugen en het grote probleem is opgelost.
Waar het hier om gaat, is dat hashing algoritmes super snel zijn, daar zijn ze ook voor gemaakt. Dat betekent dus ook dat het bruteforcen van wachtwoorden waarbij een SHA-512 hash bekend is, heel erg snel gaat. Één van de belangrijkste dingen in het veilig opslaan is het vergroten van de workfactor, oftwel de hoeveelheid tijd/moeite die een aanvaller moet hebben voor het kraken of bruteforcen van de beveiliging. Hierbij zijn twee dingen best practice: salting en stretching.
Salting is het toevoegen van willekeurige tekens aan het wachtwoord vóór het hashen. Het doel hierbij is niet om die geheim te houden, maar om die voor elk wachtwoord uniek te maken. Het resultaat van een zogeheten per-user salt is dat de aanvaller geen rainbow tables kan gebuiken (vooraf berekende lijsten met hashes op basis van veel gebruikte wachtwoorden of woorden uit een woordenboek bijvoorbeeld) om snel veel wachtwoorden te kraken. Die moeten dan per gebruiker berekend worden omdat de salt de rainbow tabel onbruikbaar maakt. Dit vergroot de workfactor enorm en heeft ook als voordeel dat twee gebruikers met hetzelfde wachtwoord níét dezelfde hash hebben.
Stretching is het langzamer maken van het berekenen van de hash. Je kunt dit doen door een hash algoritme te gebruiken dat langzaam is of door heel veel keer achter elkaar te hashen. Als je bijvoorbeeld de wachtwoorden 100.000 keer achter elkaar hasht en het resultaat daarvan opslaat, is de aanvaller 100.000 keer zo lang bezig om de wachtwoorden te kraken. De kunst is om een balans te vinden in het aantal keer dat je dat doet, zodat het snel genoeg is dat de gebruiker er bij het inloggen niets van merkt, maar tegelijk ook de aanvaller maximaal extra werk bezorgt.
Juist ja, ben ik nou gek of behoor je als cryptografe redelijk te kunnen rekenen?
94^16 mogelijkheden. delen door die, nou vooruit, pak 500 miljard wachtwoorden per seconde... kom ik op 1.4e33 dagen om alle mogelijkheden door te gaan.
Mooie claim. Even zien: 26 kleine letters tot de zestiende (inderdaad, ik laat hoofdletters en cijfers en tekens achterwege) gedeeld door 300 000 000 000 maakt 4600 jaren.
Maar, ik hoor mensen al schreeuwen, wachtwoordzinnen (passphrases)! Alright, een gemiddeld woord is 5 tekens, dus dat is 3.2 woord. Mijn standaard woordenlijst in Linux telt 99171 woorden. Maal 3.2 gedeeld door 3×10^11 (300mld) maakt 9 uur. Dat is te doen, als je inderdaad €50k aan een wachtwoordkraker uitgeeft en zin hebt in een flinke stroomrekening om één wachtwoord te kraken waarvan je aanneemt dat het een wachtwoordzin is met woorden uit een door jou gekozen woordenboek. Mogelijk als je Barak Obama heet, maar anders is het ver gezocht.
http://www.zdnet.com/article/like-passwords-for-chocolate/
Allereerst: Leuk hier zoveel reacties op ons artikel te zien! :-) (Ik ben co-auteur van de bewuste paper en het bijhorende blog-artikel.)
Ter verduidelijking: een langzamere hash-functie is inderdaad beter dan een snelle, maar heeft het nadeel dat eerlijke websites de investeringen van aanvallers moeten "matchen". Dwz, als een website het aanvallers 1000x moeilijker wil maken om paswoorden te kraken, duurt het voor de website ook minstens 1000x langer om paswoorden te controleren. Ik zeg "minstens", want de aanvaller heeft waarschijnlijk betere gespecialiseerde hardware en software om paswoorden te kraken.
Bovendien kan je een nog zo zware hash functie kiezen, maar een 4-cijferige PIN code ga je er nooit mee beveiligd krijgen. Door meerdere servers te gebruiken kan dit wel, mits gepaste maatregelen bij herhaaldelijke foute logins (tijdslot, account blokkeren, CAPTCHAs, twee-factor authenticatie,...).
Kernboodschap is eigenlijk de volgende: Ingewikkelde paswoorden zijn enkel nodig voor het geval van server hacks. Server hacks zijn een server-probleem en horen dus door servers opgelost te worden, niet afgeschoven op de gebruikers.
Klopt, maar menselijke gebruikers kunnen geen random wachtwoorden van 16 karakters onthouden. Om wachtwoorden te kunnen onthouden moeten gebruikers ze zelf kunnen kiezen, zodat ze geheugensteuntjes kunnen inbouwen. Volgens aanbevelingen van NIST (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf) bevatten zelfgekozen 16-karakter paswoorden gemiddeld slechts 30 bits aan entropie, oftewel ruwweg 1 miljard mogelijkheden. (Een beetje kort door de bocht door een uniforme verdeling aan te nemen, maar goed genoeg om grootte-ordes in te schatten.)
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.
