Geen complexe, maar lange wachtwoorden

Geen complexe, maar lange wachtwoorden

Door: Jerry Breek

Dankzij oplossingen als Single Sign-On (SSO) hoef je vandaag de dag minder wachtwoorden te onthouden. Zo start de gemiddelde HelloID Access Management gebruiker zijn werkdag met één keer inloggen, waarna je vanuit het dashboard alle applicaties met één klik kan openen. Ook maken veel mensen gebruik van een wachtwoordmanager (zoals LastPass of Bitwarden).

Toch is ons leven nog verre van ‘wachtwoordloos’. Er zijn nog genoeg situaties waarin toch een wachtwoord wordt gevraagd en ook bij HelloID en een wachtwoordmanager moet je nog wel zelf je centrale wachtwoord onthouden. En dat moet uiteraard wel een zogenaamd sterk wachtwoord zijn.

Veel organisaties hebben hiervoor een eigen wachtwoordbeleid met eisen die aan wachtwoorden worden gesteld en wanneer ze gewijzigd moeten worden. Regelmatig wordt daarbij teruggegrepen op de veelgebruikte regel dat een wachtwoord complex moet zijn met naast gewone letters ook altijd hoofdletters, cijfers en speciale tekens. Ook auditors stellen die eis nog vaak. Dat is eigenlijk heel gek, want veel mensen worstelen met zulke wachtwoorden, terwijl ze tegelijkertijd niet per se veilig zijn en het veel eenvoudiger én aantoonbaar veiliger kan.

In deze blog pellen we die vraag eens in detail af. Wat bedoelen we eigenlijk met een sterk wachtwoord? Hoe bereken je de sterkte van wachtwoorden? En met welke aanpak kun je zowel sterke als gebruiksvriendelijke wachtwoorden aanmaken?

Wat bedoelen we met een sterk wachtwoord?

Met een sterk wachtwoord bedoelen we niet een ‘nooit te kraken’ wachtwoord, als dat al zou bestaan. We bedoelen een wachtwoord waarvan het hacken zo veel tijd en geld kost dat het voor de hacker te weinig rendement oplevert.

Veel hackpogingen beginnen tegenwoordig met een gestolen database met accountgegevens waarin de hacker ‘in alle rust’ offline kan zoeken naar wachtwoorden. Wachtwoorden worden echter niet als platte tekst opgeslagen op een server maar als een zogenaamde hash code of een hash. Hashen is een cryptografische bewerking die maar één richting op werkt; je kunt een wachtwoord omzetten in zo’n hash code, maar je kunt die hash vrijwel nooit herleiden naar het oorspronkelijke wachtwoord.

Voorbeeld: Het wachtwoord ‘boterham’ wordt met behulp van het SHA-256 algoritme omgezet naar: ed3ace8b92fb5e960596df6dd4e2a6a8346344bac25e12735b0448455c93e05e. Deze hash wordt opgeslagen op de server. Als de gebruiker inlogt wordt het ingetypte wachtwoord ook gehasht met het SHA-256 algoritme. Blijken beide hashes identiek, dan is het juiste wachtwoord gebruikt en krijgt de gebruiker toegang.

Dit maakt de opslag van wachtwoorden en het inloggen relatief veilig. Het goede nieuws is namelijk dat op deze manier nergens het originele wachtwoord wordt opgeslagen. Het slechte nieuws is dat hackers wel gewoon wachtwoorden kunnen gaan ‘raden’. Je genereert een wachtwoord, berekent de bijbehorende hash en vergelijkt die met de aangetroffen hashes in de gestolen database. Heb je een match, dan heb je het wachtwoord gevonden. En daar zit de crux, met de huidige rekenkracht van computers kun je met bijvoorbeeld een zogenaamde brute force aanpak miljoenen (of zelfs miljarden) wachtwoordvariaties per seconde uitproberen. Wat betekent dat je zelfs met astronomische aantallen variaties soms toch binnen een afzienbare periode wachtwoorden kunt terugvinden.

Terugkomend op de eerdere vraag, met sterke wachtwoorden bedoelen we dus feitelijk wachtwoorden waarbij zo’n kraakpoging te veel tijd en geld kost om rendabel te zijn voor de hacker. Hieronder zie je een indicatie van hoeveel tijd een computer nodig heeft om een wachtwoord met de volgende parameters te kraken. Het is echter belangrijk om te benadrukken dat deze tijden indicatief zijn. De werkelijke tijd om een wachtwoord te kraken kan variëren. Dit hangt af van een reeks factoren, zoals het gebruik van woorden en patronen in het wachtwoord, de hashmethode, de kennis die de hacker al heeft over het mogelijke wachtwoord (bijvoorbeeld via social engineering of eerdere datalekken), de hoeveelheid rekenkracht die wordt ingezet en de efficiëntie van de gebruikte kraakmethoden. Er kan dus geen sluitend antwoord gegeven worden op de vraag hoe lang het kraken van een wachtwoord duurt, we kunnen slechts een indicatie proberen te bieden.

Entropie: hoe bepaal je de sterkte van wachtwoorden?

Is er dan ook een concrete maat om de sterkte van wachtwoorden aan te duiden en onderling te vergelijken? Daarvoor gebruiken specialisten de term entropie. De entropie van een wachtwoord is simpelweg het maximale aantal pogingen dat een hacker nodig heeft om een wachtwoord te raden.

Twee voorbeelden:

  • Zou je wachtwoorden gebruiken van slechts 2 letters (dus van ‘aa’ t/m ‘zz’) dan zijn er in totaal 26×26 = 676 mogelijke variaties. Je entropie is in dat geval 676.
  • Gebruik je wachtwoorden van 8 letters (dus alles van ‘aaaaaaaa’ t/m ‘zzzzzzzz’) dan is je wachtwoord entropie al 268 = 2,09 x 1011. Een entropie van 209 miljard dus. En des te groter de entropie, hoe sterker het wachtwoord is en des te meer tijd het kost om te kraken.

Omdat het bij entropie berekeningen dus al snel om enorm grote getallen gaat, geven we de entropie in de praktijk altijd aan als een macht van 2, die we – herkenbaar – bits noemen.

Als we de entropie van de voorbeelden hiervoor op die manier noteren:

  • 676 = 29,4. Dit wachtwoord heeft dus een entropie van 9 bits.
  • 268 = 237,6. Dit wachtwoord heeft dus een entropie van 37 bits.

Een entropie in bits geeft zo een werkbare maat voor de wachtwoord sterkte. Eén bit verhoging (bijvoorbeeld van 37 naar 38 bits) betekent in theorie een extra vermenigvuldiging met 2. En dus een verdubbeling van het aantal wachtwoordvarianten en daarmee ook een verdubbeling van de tijd die een hacker nodig heeft om zo’n wachtwoord te kraken. Echter, deze berekening is ietwat vereenvoudigd. Entropie als exacte wetenschap beschouwen is namelijk niet helemaal juist. Factoren zoals het gebruik van woordenlijsten, patronen en reeds gestolen wachtwoorden kunnen de werkelijke entropie aanzienlijk beïnvloeden.

De daadwerkelijk gewenste entropie voor wachtwoorden hangt af van meerdere overwegingen. Hoe gevoelig zijn de te beveiligen applicaties en data? Welk hash algoritme wordt gebruikt (sommige krachtige algoritmes kosten meer tijd en dat is in dit geval juist gunstig)? En hoeveel tijd en geld kost het om met de huidige stand van de techniek alle varianten door te rekenen? Er zijn dus geen algemeen vastgestelde normen maar voor belangrijke accounts mikt men vandaag de dag vaak op een entropie van 60 tot 80 bits en voor kritische toepassingen zelfs boven de 100.

Calculator sterkte wachtwoord

Onze wachtwoordsterktecalculator biedt je de mogelijkheid om een inschatting te maken van de sterkte van je wachtwoord. Deze tool evalueert je wachtwoord niet alleen op basis van lengte, het gebruik van letters en speciale tekens, maar ook op de kwetsbaarheid voor woordenboekaanvallen (dictionary attacks) en brute-force aanvallen. Houd er echter rekening mee dat, zoals eerder vermeld, deze beoordeling niet als exacte wetenschap beschouwd moet worden; de aangegeven sterkte is slechts een ruwe indicatie.

Wachtwoordsterkte meten

Om dan voldoende veilig te zijn moet het gekozen wachtwoord wel echt ‘random’ zijn. In dat geval is er namelijk echt een brute force aanpak nodig om het te vinden en gelden bovenstaande rekensommen. Veel mensen kiezen echter een makkelijk te onthouden wachtwoord zoals ‘wachtwoord123’. Password crackers starten daarom vaak met een zogenaamde dictionary attack waarbij men combinaties en variaties van populaire woorden (vandaar dictionary ofwel woordenboek) uitproberen. Zo’n eenvoudig wachtwoord wordt dus in enkele secondes gevonden. Iets soortgelijks geldt voor wachtwoorden die vaker zijn gebruikt. Als een wachtwoord al eerder is gekraakt – hoe random en ingewikkeld ook – is de hash code bekend bij hackers en geregistreerd in zogenaamde rainbow tabellen. Deze tabellen worden bij een hack als eerste vergeleken met de gestolen hashes en ook hier rollen de al bekende wachtwoorden binnen een paar seconden uit het systeem.

Dus het uitgangspunt is: een wachtwoord van voldoende entropie, niet gebaseerd op (variaties) van bekende woorden en niet eerder gebruikt.

Moeilijke of lange wachtwoorden?

In 2003 publiceerde het National Insitute of Standards and Technology (NIST) de richtlijn ‘Electronic Authentication Guideline (SP 800-63)’. Met daarin het advies dat een sterk wachtwoord minimaal 8 tekens moet bevatten, én complex moet zijn met naast kleine letters ook hoofdletters en minimaal één getal of een speciaal teken. Die nadruk op de complexiteit van dat wachtwoord bleef jarenlang het uitgangspunt. Pas recent is er meer aandacht voor het voordeel van langere wachtwoorden. En sowieso is 8 tekens wat kort met de huidige rekenkracht van computers.

In de dagelijkse praktijk worden we helaas nog vaak gedwongen wachtwoorden te bedenken met kleine letters, hoofdletters, getallen en speciale tekens. Iedereen kent de frustratie dat je een wachtwoord hebt bedacht en er vervolgens rode kruisjes in beeld verschijnen omdat je nog niet aan alle eisen voldoet. Uiteindelijk leidt het tot gedrochten van wachtwoorden als ‘t5RF&*yh’ of creatieve bedenksels in de categorie ‘Pa$$w0rd’. En dat laatste voorbeeld voldoet weliswaar aan de regels maar is vast vaker gebruikt en staat ongetwijfeld ook bij hackers op hun rainbowlijst.

Vervelend is bovendien dat zulke complexe wachtwoorden niet eens zo veel veiliger zijn. Bij de genoemde richtlijn is het uitgangspunt dat een wachtwoord kort mag zijn, zodat het makkelijk is te onthouden. En omdat bij wachtwoorden van maar 8 tekens met enkel kleine letters (a t/m z) de entropie slechts 268 => 37 bits is, eist men dus wel het gebruik van hoofdletters, getallen en speciale tekens[1]. Het effect daarvan is echter beperkt. De entropie is daarmee weliswaar toegenomen tot 948 => 52 bits, maar dat maakt deze wachtwoorden nog steeds niet zo sterk.

Het verlengen van wachtwoorden blijkt daarentegen een veel groter effect te hebben. Met enkel gebruik van kleine letters realiseer je met een wachtwoord van 16 willekeurige tekens in principe al een entropie van 75 bits. En met 22 tekens kom je zelfs al boven de 100 bits uit! En omdat we niet geforceerd zulke lastige speciale tekens hoeven te gebruiken, zijn er volop mogelijkheden om zogenaamde wachtwoordzinnen (in het Engels: passphrase) te bedenken die eenvoudig te onthouden zijn en tegelijkertijd enorm veilig. In zo’n wachtwoordzin zijn bovendien wél eenvoudig cijfers en tekens te verwerken om het nog veiliger te maken. De zin ‘Watdom:53x10isgeen531’ is makkelijker te onthouden dan ‘t5RF&*yh’ en veel sterker.

[1] Dus 26 kleine letters, 26 hoofletters, 10 cijfers en 32 speciale tekens = 94

Hoe sterk zijn wachtwoordzinnen?

Bij zulke wachtwoordzinnen hoort wel een disclaimer. Stel dat we voortaan onze gebruikers vragen een wachtwoordzin van – bijvoorbeeld – minimaal 5 woorden te kiezen. Zo’n wachtwoordzin bevat dan ongeveer 25 letters[2]. Als je de entropie op de gangbare manier zou uitrekenen, is die zelfs met alleen kleine letters 2625 => 117 bits en dus extreem sterk.

Die berekening gaat echter over ‘de maximale sterkte’ omdat je uitgaat van het onbeperkt combineren van letters. De rekensom bij wachtwoordzinnen gaat echter anders. Daar is de entropie gelijk aan het aantal verschillende zinnen dat je kunt maken. Laten we er even van uitgaan dat we in Nederland een ‘gezamenlijke woordenschat’ hebben van één miljoen woorden[3]. Dan kun je in theorie (1.000.000)5 verschillende 5-woordzinnen maken. De entropie is dan (1.000.000)5 => 99 bits. Nog steeds enorm sterk, maar wel duidelijk minder dan bij een volledig random string van 25 tekens.

Bovendien maken mensen normaliter kloppende en betekenisvolle zinnen. Dus niet iets als ‘Ik loopt boom toe gemiddeld’. Ook worden niet alle woorden even vaak gebruikt. Met alle taalkundige regels en statistische kennis over woord- en zinsgebruik kun je veel slimmere crack algoritmes toepassen dan met een platte brute force aanpak. Je begint met het checken van meer gangbare zinsconstructies en van daaruit ga je gaandeweg door naar de minder kansrijke zinnen. En er is natuurlijk ‘laaghangend fruit’: Je kunt met dictionary attacks snel alle varianten van eenvoudige zinnetjes als ‘ik ben Piet uit Amsterdam’ vast razendsnel scannen.

Tenslotte vinden veel mensen het moeilijk om zelf iets te bedenken. Ze grijpen terug op filmzinnen (may the force be with you), liedteksten (hier aan de kust de zeeuwse kust) en andere teksten uit ons collectieve geheugen. Hou er dus rekening mee dat hackers eindeloze lijsten met films, songs, spreekwoorden, citaten en reclameslogans verzamelen om hun rainbow tabellen te vullen. We lopen dus het risico dat zulke wachtwoordzinnen in no time zijn te kraken.

Zijn wachtwoordzinnen dus niet veilig? Toch wel, de meeste experts beschouwen wachtwoordzinnen als een veel veiliger oplossing dan korte maar complexe wachtwoorden. Zolang we gebruikers maar waarschuwen dat lengte alléén niet voldoende is; een lange wachtwoordzin geeft je de ruimte om voldoende eigen en unieke elementen aan die zin toe te voegen, zoals een getal, een hoofdletter of een bijzondere woord- of zinsconstructie. Als je dat verstandig doet is een wachtwoordzin altijd veiliger én prettiger dan een complex wachtwoord.

We zien dat die nieuwe benadering gaandeweg breder wordt omarmd. In de BIO (Baseline Informatiebeveiliging Overheid) is inmiddels de volgende concrete eis opgenomen:

Als er geen gebruik wordt gemaakt van two-factor authenticatie, is de wachtwoordlengte minimaal 8 posities en complex van samenstelling. Vanaf een wachtwoordlengte van 20 posities vervalt de complexiteitseis.

[2] Onderzoek toont aan dat de gemiddelde woordlengte in veel teksten tussen de 5 en 6 woorden ligt. We rekenen even met 5 letters.

[3] Volgens onderzoek kent de gemiddelde persoon 42.000 woorden, maar tegelijkertijd komt de woordenlijst Nederlandse taal al richting de miljoen woorden en er zijn wetenschappers die tot miljoenen varianten komen inclusief alle werkwoordvormen etc. Mensen kennen ook andere talen en als we ook nog eigennamen, plaatsnamen, merknamen, productnamen, dialect, vaktermen, getallen etc. gebruiken lijkt een miljoen niet overdreven

Of gebruik een passphrase generator

Wil je 100% zeker weten dat gebruikte wachtwoordzinnen voldoende sterk zijn? Wil je hoe dan ook voorkomen dat mensen een te simpele filmtitel kiezen? Of wil je in het kader van je compliancy exact berekenen hoe sterk jouw wachtwoordzinnen zijn? Dan is een zogenaamde passphrase generator een oplossing, een wachtwoordzin generator.

Tools4ever biedt zo’n passphrase generator op de website. Je kunt daarin instellen hoeveel woorden een zin moet bevatten en bij iedere klik krijg je een nieuwe suggestie zoals:

fijn-abuis-hakken-belet-loods

Het idee is simpel en effectief. De generator werkt met een standaard woordenlijst waaruit men random woorden kiest. De zin zelf heeft geen betekenis maar met relatief korte woorden is zo’n zin toch makkelijker te onthouden dat een korter maar ingewikkeld wachtwoord. En omdat we weten hoe lang de woordenlijst is, kunnen we ook de entropie exact berekenen.

Wachtwoord generator

Met onze wachtwoordgenerator genereer je eenvoudig een sterke, lange en willekeurige wachtwoordzin.

Genereer een wachtwoordzin

Net als Tools4ever werken veel passphrase generators met een lijst van 7.776 woorden. Met wachtwoordzinnen van 5 woorden is de entropie (7.776)5 => 64 bit. Daarmee is het 12 bits sterker dan een complex wachtwoord van 8 tekens en duurt het al 12 keer zo lang om zo’n zin te kraken. Met een extra woord erbij, verhoog je de entropie tot 77 bits enzovoorts. Iedere vorm van bias en beïnvloeding ontbreekt en we hebben dus een wachtwoordzin met een gegarandeerde sterkte.

Waarom 7.776 woorden? Veel passphrase generators zijn gebaseerd op een concept dat diceware heet. Dice van dobbelstenen. Als je niet blind wilt vertrouwen op een online random generator, kun je ook gewoon echte echte dobbelstenen gebruiken en in een lijst het bijbehorende woord opzoeken. Met vijf dobbelstenen heb je 65 = 7.776 woorden. Er zijn tal van zulke diceware lijsten gemaakt – de een prettiger in gebruik dan de ander – en ook Nederlandse varianten. Voor het genereren van wachtwoordzinnen vertrouwt ons systeem ook een Nederlandse diceware woordenlijst.

Er is nog een nuttige maatregel om je wachtwoorden beter te beveiligen. We waarschuwden al voor het gebruik van rainbow tabellen door hackers. Dat zijn tabellen met hash codes van populaire en eerder gestolen wachtwoorden. Bij een nieuwe hack worden de aangetroffen hashes razendsnel door zulke rainbow tabellen gehaald en bij iedere match kan men direct het bijbehorende account openen.

Er is gelukkig een eenvoudige manier om dit te voorkomen en dat heet salten. Hierbij wordt bij het aanmaken van een wachtwoord – en ook bij iedere inlogpoging – automatisch een prefix of suffix toegevoegd vóórdat het wachtwoord wordt gehasht. Ditnoemen we de ‘salt’ (letterlijk ’zout’). Een wachtwoord inclusief salt levert een andere hash op dan datzelfde wachtwoord zonder salt, ofwel:

Hash (wachtwoordABC) ≠ Hash (wachtwoordABC + salt)

Dit maakt rainbow tabellen volledig onbruikbaar. Natuurlijk kan een zwak wachtwoord nog wel via dictionary of brute force attacks worden gevonden, maar de snelste route via rainbow tabellen is in ieder geval grotendeels afgesloten.

Salten is een automatisch proces dat in de server wordt ingesteld en als gebruiker zie je er niets van. De salt kan zelfs per gebruiker en per wachtwoord verschillen. Als dan iemands wachtwoord is ontvreemd en andere medewerkers gebruiken hetzelfde wachtwoord (niet de bedoeling, maar toch..), worden deze accounts niet direct geraakt.

Lange ww

Vergeet ook Multifactor Authenticatie niet

Terecht overigens wordt in de BIO ook Multi Factor Authenticatie (MFA) genoemd. Met lange wachtwoorden maak je je toegangsbeveiliging natuurlijk veiliger, maar het activeren van MFA is minstens zo belangrijk. Met MFA combineer je iets dat je als gebruiker weet (je wachtwoord) met iets dat je bezit (zoals een smartphone of hardware token) of dat je bent (denk aan een vingerafdruk of irisscan). Aan een gekraakt wachtwoord heeft een hacker dan nog niets, want de gebruiker moet een inlogpoging bevestigen via diens smartphone of token.

Ook hier zijn overigens aandachtspunten. MFA is een steeds vaker gebruikt hulpmiddel maar daarmee dreigt ook het risico van ‘MFA fatigue’. Iemand ontvangt dan zo vaak MFA verzoeken – niet alleen bij inloggen maar soms ook tijdens sessies – dat men ze bijna gedachteloos goedkeurt. Ook uit ergernis als de verzoeken steeds worden herhaald; bij een recente Uber hack bleef de aanvaller inloggen, net zo lang totdat de betreffende medewerker één van de MFA verzoeken goedkeurde.

Dat risico heb je zeker bij MFA verzoeken waarbij je alleen maar hoeft te klikken om te bevestigen. Bij zo’n Push MFA is er sowieso het risico dat je ze onbewust goedkeurt. Zorg dus dat het aantal MFA verzoeken beperkt blijft – en het dus opvalt als je er plotseling veel ontvangt – en gebruik bij voorkeur ook een MFA oplossing waarin de gebruiker bijvoorbeeld ook een korte (vaak nummerieke) code moet invoeren of selecteren.

authenticator app

Nog even wat tips samengevat

  • Gebruik Single Sign-On (SSO) en/of een passwordmanager zodat je slechts één ‘master password’ moet onthouden.
  • Kies in je wachtwoordbeleid waar mogelijk voor langere wachtwoorden in plaats van korte, complexe wachtwoorden. Dat is veiliger en gebruiksvriendelijker.
  • Gebruik bij voorkeur wachtwoordzinnen (pass phrases). Let daarbij wel op dat je voldoende ‘creatief’ bent.
  • Gebruik geen variaties van bestaande woorden als wachtwoord, of te simpele en vaak gebruikte zinnetje als wachtwoordzin.
  • Desgewenst kun je een passphrase generator gebruiken. Daarmee weet je zeker dat de wachtzin voldoende sterk is.
  • Gebruik een wachtwoord nooit meerdere keren. En check of jouw systemen het gebruik van ‘salt’ ondersteunen en geactiveerd is.
  • Maak je toegangsbeveiliging extra sterk met MFA maar voorkom ‘MFA fatigue’ en wees voorzichtig met Push MFA.

We adviseren je vanuit Tools4ever uiteraard graag over je wachtwoordbeleid en het effectief toepassen van hulpmiddelen als Single Sign-On en MFA.

Bij hashing wordt informatie omgezet naar een zogenaamde hash: een string van een beperkt aantal tekens (64 bij het veelgebruikte SHA-256 algoritme) die je zelden of nooit kunt terugrekenen naar de oorspronkelijke inputwaarde. Identieke inputgegevens leveren daarbij altijd eenzelfde hash op en daarmee vormt zo’n hash een uniek controlegetal om gegevens veilig en eenvoudig te kunnen controleren. Zo vormt een hash een veilig verificatiemiddel voor wachtwoorden. Je hoeft immers de werkelijke wachtwoorden niet op te slaan op een webserver; voor inloggen volstaat een lijst met hashes. Hashes kun je ook gebruiken om de integriteit van gegevens te bewaken. Wil je bijvoorbeeld controleren of een bestand niet ongemerkt is bewerkt? Dan kun je eenvoudigweg de hash berekenen en die vergelijken met de hash van het oorspronkelijke bestand. Ook bij bitcoins en andere cryptovaluta wordt hashing gebruikt om de integriteit van transacties te bewaken.

Hashing gebruiken we in ons geval dus als een slim en veilig verificatiemiddel bij het inloggen. Maar je wilt wachtwoordinformatie ook veilig kunnen opslaan en versturen. Zelfs al zijn hashes niet rechtstreeks te herleiden naar wachtwoorden, toch wil je een database met hashes niet zomaar voor iedereen openzetten. En als gebruikers wachtwoorden bewaren in een wachtwoordmanager moet die natuurlijk extreem goed beveiligd worden. Daarvoor wordt encryptie gebruikt. Encryptie is het versleutelen van digitale gegevens met een encryptiealgoritme (zoals AES-256). De versleutelde gegevens kun je alleen met een specifieke sleutel weer ontcijferen en leesbaar maken. Waar hashing in één richting werkt, is encryptie dus een twee-richting bewerking: je kunt gegevens versleutelen en onleesbaar maken, maar je kunt die ‘cijfertekst’ ook weer ontcijferen en leesbaar maken.

Een term die je ook nogal eens hoort in relatie tot wachtwoordbeveiliging, is ‘salten’. Salten is op zichzelf geen cryptografische bewerking, maar een hulpmiddel om het gebruik van hashing veiliger te maken. Hashing is in principe veilig maar toch kun je een hash herleiden naar het oorspronkelijke wachtwoord met behulp van brute force methodes of rainbowtables. Door wachtwoorden te salten kunnen we hashing echter nog wat veiliger maken. Hierbij voegt men voorafgaand aan het hashen eerst een soort prefix – de salt – toe aan een wachtwoord. Daardoor verandert de hash volledig, kun je Rainbow lijsten niet zomaar meer gebruiken en wordt de brute force aanpak nog veel moeilijker.

Jerry Breek

Geschreven door:
Jerry Breek

Ontmoet Jerry, een veelzijdige Implementatieconsultant bij Tools4ever. Met een solide achtergrond bij NetSourcing waar hij inzichten verwierf in het werken met Microsoft-producten en gespecialiseerd raakte in zorgsystemen zoals Nedap, evenals in onderwijssystemen zoals Magister en Somtoday. Deze waardevolle kennis zet hij nu al 5 jaar  in voor de klanten van Tools4ever.

Anderen bekeken ook

Drie tips om veilig om te gaan met uw data en applicaties

Drie tips om veilig om te gaan met uw data en applicaties

09 maart 2020

Het belang van beveiligingsnormen voor data en apps

Het belang van beveiligingsnormen voor data en apps

09 maart 2020

Het spoor van je digitale voetdruk

Het spoor van je digitale voetdruk

07 november 2022

De drie belangrijkste voordelen van Identity Access Management

De drie belangrijkste voordelen van Identity Access Management

09 maart 2020