Development

Security
Wachtwoord invoeren

Wachtwoord verplicht? De 5 gouden regels

Weet je wat het allerergste is aan wachtwoorden? De regels die programmeurs voor wachtwoorden bedenken!

© CCO Public Domain Pixabay
14 maart 2017

Weet je wat het allerergste is aan wachtwoorden? De regels die programmeurs voor wachtwoorden bedenken!

Wachtwoorden zijn een beroerd middel om je op internet te identificeren. Maar vooralsnog is dat de meest gehanteerde methode. Dus maken we het in ieder geval voor gebruikers zo makkelijk mogelijk om goede wachtwoorden te verzinnen, toch? Nee dus!

Die conclusie trekt Jeff Atwood, mede-oprichter van Stack Overflow. Hij schreef zijn bevindingen op in een bijdrage aan een blogpagina waarvan de naam niets aan duidelijkheid te wensen over laat: Coding Horror. En de titel windt er ook geen doekjes om 'Wachtwoordregels zijn gelul'.

De regels die bij het gebruik van wachtwoorden worden opgelegd, zijn vaak onhanteerbaar. Atwood citeert uit een eerdere tweet regels als:

  • moet 8 tot 32 karakters tellen
  • moet ten minste twee van de volgende elementen bevatten:
    - een letter
    - een getal
    - een speciaal karakter uit de lijst # $ % ' ^ , (  ) * + : | = ? @ / ] [ _ ` { } \ ! ; - ~
  • moet verschillen van de 5 eerder gebruikte wachtwoorden
  • mag niet overeenkomen met je gebruikersnaam
  • mag niet meer dan twee keer hetzelfde teken bevatten (dus geen 'baardaap')
  • mag niet meer dan twee opeenvolgende tekens bevatten (dus geen abc, 123 etc. in het wachtwoord)
  • mag niet de naam van de website bevatten
  • mag niet een veelgebruikt wachtwoord zijn

 

Om de zaken nog leuker te maken, kiest iedere website zijn eigen setje uit bovenstaande regels. Er zijn bijvoorbeeld veel websites met een vrij korte bovenlengte aan het wachtwoord, websites die bepaalde bijzondere tekens niet accepteren, vrij algemeen is de spatie verboden in een wachtwoord.

Gevolg: wachtwoorden maken en onthouden is onnodig moeilijk. En mensen die voor een wachtwoordmanager kiezen, lopen daarmee regelmatig tegen problemen op.

Dat kan ander, en dat moet anders. zegt Atwood. En hij formuleert 5 regels die software-ontwikkelaars zouden moeten respecteren.

1. Stop met wachtwoordregels

Wachtwoordregels werken niet, ze straffen je ideale klant - de klant die een wachtwoordgenerator gebruikt, ze frustreren de gemiddelde gebruiker - die vervolgens creatief ezelsbruggetjes verzint waarmee het wachtwoord minder veilig wordt, en de regels zijn vaak incompleet of soms ronduit onzinnig. Geef de gebruiker zo veel mogelijk ruimte, in lengte en in gebruikte tekens.

2. Dwing een minumumlengte af

In weerwil van regel 1 formuleert Atwood 4 regels die wél moeten gelden. De eerste is een minimumlengte. Als men wachtwoorden in Unicode laat invoeren, is 10 tekens een mooi aantal. Dat zorgt automatisch voor enige entropie, en bant bovendien 20 van de 25 meest gebruikte wachtwoorden uit; die zijn goed voor 80 procent van alle wachtwoorden. Als men ook emoji's en Chinese karakters toelaat, kan het wellicht met minder tekens, Hoe minder beperkingen men oplegt, hoe beter het is.

3. Check op veelgebruikte wachtwoorden.

Hackers beginnen altijd met een lijst veelgebruikte wachtwoorden; die kun je om je klant een dienst te bewijzen dus beter verbieden. Hoe groot die lijst moet zijn, hangt een beetje af van de aantrekkelijkheid van je website voor hackers. Gemiddeld heeft 13,2 procent van de websitebezoekers een wachtwoord uit de top 1000, en 30 procent eentje uit de top 10.000.

4. Check op voldoende entropie

Hoe willekeuriger de karakters in een wachtwoord verdeeld zijn, hoe lastiger het te kraken is. Je zou als eis moeten stellen dat een wachtwoord een minimum aantal elementen moet bevatten dat slechts eenmaal voorkomt. Hoe groot at aantal moet zijn? Atwood houdt zich beleefd aanbevolen voor suggesties

5. Weiger wachtwoorden die een hacker makkelijk zal raden

Sommige wachtwoorden die wellicht aan alle eisen voldoen,zijn toch een slecht idee. Denk aan een wachtwoord dat gelijk is aan gebruikersnaam, e-mailadres, url, app-naam ... Een volledige lijst is lastig op te stellen. Software-ontwikkelaars zouden moeten proberen te denken als een gebruiker - dan komen ze een heel eind bij het opstellen van een lijstje afraders.

 

Lees meer over
Zie ook Development op AG Connect Intelligence
8
Reacties
Mark 19 maart 2017 14:43

Meneer Atwood wil een probleem oplossen met de oorzaak: Hij pleit voor vervanging van hinderlijke regels door zijn eigen regels. De hinderlijke regels zijn echter specifiek; die van hem vaag. Vaagheid die leidt tot dezelfde hinderlijke regels...

2. Dwing een minimum lengte af
Lengtebeperkingen waren toch zo vervelend? En een onbeperkte maximumlengte is niet haalbaar; eis dan liever een ruim maximum. Valt bovendien onder regel 3, 4 en 5.

3. Check op veelgebruikte wachtwoorden
Dit is toch gewoon de laatste bullet? En welke lijst is dat precies? Als iedereen een andere lijst hanteert, zijn we even ver van huis. En zonder die lijst expliciet te maken, dwing je programmeurs dit te vertalen in precies de regels die zo lastig zijn, zie bullets 2 en verder.

4. Check op voldoende entropie
Wat is "voldoende entropie" precies? Atwood houdt zich beleefd aanbevolen voor suggesties, maar die staan al tussen zijn bullets -(bijna) geen herhaling, wel speciale tekens (bullets 2,5,6). Kortom: vage specificaties, leidend tot precies die lastige regels die hij wil afschaffen.

5. Weiger wachtwoorden die een hacker makkelijk zal raden
Dit is een open deur en 'makkelijk' de allervaagste van Atwoods regels; reden voor de hinderlijke regels onder bullet 3,4 en 7. En helemaal een gotspe: 'Software-ontwikkelaars zouden moeten proberen te denken als een gebruiker - dan komen ze een heel eind bij het opstellen van een lijstje afraders.' Met andere woorden: hoe maak ik een zo hinderlijk mogelijke regel.

Kortom: ik denk dat hinderlijke regels ontstaan door vage specificaties zoals die van Atwood. Ontwikkelaars zouden vage specificaties juist niet moeten respecteren.

Gegeven de huidige onvermijdelijkheid van wachtwoorden zou het bijvoorbeeld constructiever en interessanter geweest zijn om te pleiten voor een publieke standaard voor wachtwoordsterkte(n). Systemen zouden deze openlijk kunnen gaan hanteren in plaats van hun lokale regels. Daarmee voorkom je slecht, ondoorzichtig en incompatibel wachtwoordbeleid.

Norman 18 maart 2017 14:20

Ik vraag me af of er niet andere manieren zijn te bedenken dan wachtwoorden, als het er toch om gaat dat je het de klant makkelijk wilt maken terwijl je het veilig houdt.
Zo'n lijstje van Atwood is natuurlijk een leuk begin, maar creatief is het niet.
Wat nu als we gaan werken met dubbele wachtwoorden, dus niet een gebruikersnaam en een wachtwoord, maar een toegangsnaam en een wachtwoord. In zekere zin een heel lang wachtwoord, maar in twee delen op gesplitst. Die toegangsnaam is dan bedoeld om de wachtwoord controle bereikbaar te maken. Dan zou je als site zelfs iemand een unieke code als toegangsnaam kunnen sturen, waarna men het wachtwoord aanmaakt.
Of:
Je zou ook het invoerscherm voor het wachtwoord kunnen aanvullen met een captcha code. Levert meteen het vreemde effect op dat je als hacker niet meer geautomatiseerd wachtwoorden kunt invoeren en brute force eigenlijk alleen nog lukt met veel mankracht.
Of:
Je moet drie wachtwoorden aanmaken, die je willekeurig nummert en de website vraagt je steeds willekeurig om twee van die wachtwoorden in te voeren.
Of:
Je laat de gebruiker kiezen uit een reeks wachtwoorden, zorgt er weer voor dat je voorkomt dat gebruikers makkelijke wachtwoorden gaan gebruiken. Vervolgens biedt je steeds een nieuwe reeks wachtwoorden aan bij iedere inlog, waar het gekozen wachtwoord tussen staat. En als je dan ook nog eens het account in geblokkeerd gooit na twee keer verkeerd kiezen of zelfs één keer, met een mail naar het aanmeld e-mail adres, met een code om een nieuw wachtwoord te kiezen.
Of:
Een gebruiker aanbieden om een bepaald wachtwoord patroon te kiezen, dat kan ook alfanumeriek i.p.v. grafisch, dus bijvoorbeeld: klinker, hoofdletter klinker, medeklinker, getal, leesteken, getal, klinker, hoofdletter klinker. Dan heb je misschien maar zes tekens waarmee je werkt, maar als je dat combineert met minimaal 10 tekens, heb je al een matrix van 60 tekens.
Of:
Je combineert een aantal methodes.

Uiteindelijk gaat het bij wachtwoorden toch om het verhogen van de prijs van het kraken of dat nu in de vorm is van een dure expert of in de vorm van veel tijd. Net zoals bij het beveiligen van een huis, het doel van een dure alarminstallatie is de inbreker de wens in te geven een makkelijker doelwit te kiezen, niet het onmogelijk te maken binnen te komen, want dan kun je als bewoner ook niet meer naar binnen.

Menno 17 maart 2017 12:04

Prima actie! Je wilt graag een beter paswoord, maar je wordt gedwongen iets te kiezen van maximaal 8 tekens. Dat moet minimaal worden. Helemaal mee eens. Nog beter is minimaal two factor authentication via je mobiel. Dan heb je extra zekerheid. Gelijkertijd wil ik ook de veel gebruikte Nederlandse adresvelden aangeven als onnodig, zoals verplicht 4 cijfers en 2 letters voor postcode. Of straat, huisnummer en iets anders elk in een apart veld. Vaak kun je je dan niet meer registreren vanuit het buitenland.

Ronald 15 maart 2017 15:39

Mooi dat aan die wachtwoord-onzin aandacht wordt besteed. De meeste wachtwoordregels verslechteren de veiligheid eerder, inderdaad. Dat gevecht voer ik nog wel eens met de "checklist security" mensen, maar helaas zijn ze zelf ook vaak gedwongen dit te doen door regelgeving, opgesteld door nitwits.

De beste methode om wachtwoorden veilig te houden zonder al te veel frustratie bij de gebruikers las ik ooit op Slashdot: de sysadmin draait gewoon permanent een up-to-date password cracker op het systeem, en als die een password weet te kraken wordt dat geblokkeerd. Dat leert mensen heel snel om goede wachtwoorden te kiezen, zit password managers niet in de weg (integendeel) en heeft als bijkomend voordeel dat brute force aanvallen met een flinke achterstand beginnen.

Pieter 15 maart 2017 12:37

Stop met paswoorden. Ik heb een aantal sites waar ik maar 1x per jaar moet zijn en dan gebruik ik gewoon de "paswoord vergeten"-link. Als nieuw paswoord rammel ik wat op mijn klavier en hupsakee... Andere doe ik met two-way authenticatie.

GEWOONMAN 14 maart 2017 13:51

Je ziet wel eens dat je een wachtwoord moet herhalen wanneer die nieuw moet worden opgegeven. Geldt dat ook voor reacties?

Hackerman 14 maart 2017 12:24

Het probleem met het bepalen van de kwaliteit van een wachtwoord is dat je daarvoor eigenlijk de tools moet gebruiken die een aanvaller gebruikt. In de praktijk worden er doorgaans wat eenvoudige controles gebruikt die dan een veilig wachtwoord op zouden leveren. Veel password guessing/hacking engines zijn veel geavanceerder waardoor een gevoel van schijnveiligheid wordt gegeven.

Daarnaast is het een misverstand dat een groter aantal karakters per definitie een grotere entropie garandeert. Dat is alleen het geval als er geen gebruik gemaakt mag worden van bestaande woorden.

Grote voordeel is dan weer dat een password normaal gesproken niet te brute forten is, tenzij een site wordt gehackt en de hashes uitlekken. Dat maakt dat je in de praktijk weinig te vrezen hebt als je wachtwoorden niet op meerdere sites gebruikt.

Hackerman 14 maart 2017 12:24

Het probleem met het bepalen van de kwaliteit van een wachtwoord is dat je daarvoor eigenlijk de tools moet gebruiken die een aanvaller gebruikt. In de praktijk worden er doorgaans wat eenvoudige controles gebruikt die dan een veilig wachtwoord op zouden leveren. Veel password guessing/hacking engines zijn veel geavanceerder waardoor een gevoel van schijnveiligheid wordt gegeven.

Daarnaast is het een misverstand dat een groter aantal karakters per definitie een grotere entropie garandeert. Dat is alleen het geval als er geen gebruik gemaakt mag worden van bestaande woorden.

Grote voordeel is dan weer dat een password normaal gesproken niet te brute forten is, tenzij een site wordt gehackt en de hashes uitlekken. Dat maakt dat je in de praktijk weinig te vrezen hebt als je wachtwoorden niet op meerdere sites gebruikt.

Reactie toevoegen