De usability van wachtwoorden
Beveiligingsexperts, systeembeheerders en programmeurs zijn verantwoordelijk voor een goede beveiliging van de websites, software en systemen die zij beheren. Gaat het mis, en worden systemen gehacked of komen gegevens op straat te liggen, dan worden zij snel als schuldige aangewezen. Geen wonder dat ze soms ver gaan om te zorgen dat de boel goed dichtgetimmerd is. Helaas gaat een deel daarbij te ver, waardoor de usability zo ver wordt ingeperkt, dat het ten koste gaan van klanttevredenheid en de verkoop. Wat mag je als marketeer of website eigenaar wel en niet laten gebeuren?
Welke risico’s zijn er voor marketeers?
Uiteraard is het schadelijk voor een bedrijf als blijkt dat klantgegevens op straat komen te liggen door een slechte beveiliging van de website. Maar te ingewikkelde en beperkende beveiligingseisen maken het lastig voor je bezoekers om een aankoop te doen. Als jouw website allerlei ingewikkelde eisen stelt aan de inloggegevens en de concurrent niet, dan is er een grote kans dat je klanten misloopt.
De basis van een goed wachtwoord
Een goed wachtwoord is makkelijk te onthouden, maar tegelijk moeilijk te raden. Een lastige combinatie en vaak een dunne scheidslijn. Is het wachtwoord te simpel, dan is het te makkelijk te raden voor kwaadwillenden. Is het te moeilijk, dan kunnen mensen het niet onthouden en gaan ze het dus opschrijven.
Slechte eisen aan wachtwoorden
Niet doen: Overijverige eisen stellen
“Uw wachtwoord moet ten minste 5 letters bevatten, waarvan minimaal 1 hoofdletter en 1 kleine letter. Ook moet het ten minste 1 cijfer, een vreemd teken en een accent aigu bevatten. En maximaal 8 letters, 3 cijfers en 3 rare tekens.”
Dit voorbeeld is lichtelijk overdreven, maar eisen van deze strekking kom je wel tegen op websites. Gebruikers moeten een wachtwoord makkelijk kunnen onthouden. Lukt dat niet, dan schrijven ze het op, en heb je dus een beveiligingsprobleem. Maak dit soort eisen dus niet té ingewikkeld, want dan dwing je mensen om wachtwoorden te bedenken die ze niet kunnen onthouden.
Niet doen: Overijverige beperkingen opleggen
Bij de beperkingen geldt eigenlijk het zelfde als bij de eisen. Bij Adobe.com mag je wachtwoord bijvoorbeeld maximaal 12 karakters hebben. Waarom die beperking? Als ik nou toevallig een wachtwoord wil gebruiken dat ik makkelijk associeer met Adobe, wat letters en cijfers bevat en toevallig uit 13 karakters bestaat? Is een wachtwoord van 13 karakters minder veilig dan een wachtwoord van 12?
Niet doen: Wachtwoord verplicht maandelijks wijzigen
Veel beveiligers dwingen af dat gebruikers hun wachtwoord periodiek moeten wijzigen. Dat zou veiliger zijn, want als een schurk je wachtwoord dan te pakken heeft, kan hij na een maand niet meer in je account.
Uiteraard is dat volslagen onzin. Want in een maand kan iemand makkelijk je hele account leeghalen, sterker, dat kan in enkele minuten. Dus je wachtwoord periodiek verplicht wijzigen helpt niet tegen het inbreken op je account. Het is mosterd na de maaltijd.
Ik denk zelfs dat het verplicht maken van periodiek wijzigen van wachtwoorden juist een beveiligingsprobleem creëert. Want mensen geen nou eenmaal niet elke maand een nieuw wachtwoord onthouden. Dus schrijven ze het op een post-it aan hun monitor om het te kunnen onthouden. Of ze gaan doornummeren, in november: ‘desysteembeheerderiseenlul-11’ december: ‘desysteembeheerderiseenlul-12’. Kraakt iemand dat wachtwoord, dan kan die er alsnog altijd in.
Niet doen: Automatisch gegenereerde wachtwoorden
Bij sommige websites of applicaties mag je als gebruiker niet zelf je wachtwoord bedenken. Het wachtwoord wordt dan voor de gebruiker gegenereerd door het systeem. Dat levert per definitie een beveiligingsprobleem op, want een wachtwoord dat je niet zelf bedacht hebt onthoudt je natuurlijk ook niet makkelijk. En dus schrijven mensen het op.
Niet doen: Wachtwoord reset
Uiteraard moet je altijd een knopje ‘wachtwoord vergeten?’ bieden op je website. Maar wat doe je achter dat knopje? Sommige websites kiezen ervoor om op basis van je e-mailadres of gebruikersnaam een nieuw wachtwoord te sturen naar de e-mailadres. Dom natuurlijk, want dan zit je met het zelfde probleem als hierboven. Beter is het om de gebruiken zijn/ haar oude wachtwoord te mailen en direct de optie te geven om het te wijzigen.
Niet doen: De gebruikersnaam genereren
Deze kom ik gelukkig zelden tegen. Maar bij MegaJobs doen ze echt alles om hun bezoekers zo veel mogelijk te irriteren. Je mag daar niet zelf je gebruikersnaam bedenken, dat doet het systeem voor je. Mijn gebruikersnaam is SR124618S. Handig te onthouden. Als je vervolgens een baan vindt (zoals ik) en je dus wilt uitschrijven voor hun vacaturenieuwsbrief kan dat niet via één klik op de uitschrijflink, maar moet je eerst inloggen om ergens in je profiel in te stellen dat je geen mailtjes meer wilt.
Over het eenvoudig uitschrijven voor nieuwsbrieven zou ik zo nog een heel artikel kunnen schrijven, maar ik hou het kort: Als dit meer dan 1 klik en 2 seconden denken kost, drukken mensen op “report spam”. Dan zijn ze ook van je nieuwsbrief af, maar als genoeg mensen dat doen, komt je domein wel op een zwarte lijst in spamfilters te staan.
Hoe moet het dan wel?
Usability is heel makkelijk: Uiteindelijk moet je gewoon afkijken hoe de succesvolle spelers het doen. En kijken waar ‘gewone’ gebruikers de mist in gaan. Enkele tips hoe het wel moet:
Wel doen: Afkijken
Kijk welke regels Google, Facebook, Amazon, Wehkamp en Booking hebben rond de inlog op hun websites. Deze bedrijven hebben daar over nagedacht. Doe gewoon hetzelfde als hen en je zit goed. Over het algemeen zul je zien dat deze sites helemaal niet zulke strenge eisen stellen.
Daarnaast gaat het bij usability ook om gewenning. Als alle grote sites het winkelmandje rechtsboven zetten dan maakt het niets uit dat je designer hem links wil. Dit soort conventies kun je maar beter opvolgen, anders kost dat gewoon een percentage van je omzet. Hetzelfde geldt met wachtwoorden. Gewoon niet eigenwijs doen, maar lekker afkijken dus.
Wel doen: Meten en meekijken
In de meeste webanalytics pakketten kun je funnels / trechters instellen en doormeten. Zie je hoge uitvalpercentages bij de inlog? Of bezoekers die lange tijd op die pagina doorbrengen of er meerdere keren vlak na elkaar terugkomen? Dan is het wellicht een idee om eens te kijken of inloggen te moeilijk is. De leukste manier om dat te doen is door familie of vrienden die niet dagelijks met websites werken achter een computer te zetten. Geef ze de opdracht om een account te maken en kijk wat er gebeurt.
Wel doen: User feedback
Geef de regels die je hebt duidelijk weer op de plek waar de gebruiker ze nodig heeft. Gaat het toch mis? Zorg dan voor een duidelijke en klantvriendelijke foutmelding waarin niet alleen staat wat er mis is, maar vooral hoe het wél moet. Dus niet ergens onderaan de pagina in rode hoofdletters “error 315: password not accepted”, maar netjes op de plek waar het misgaat “gebruik een wachtwoord met … ”
Wachtwoord-horrorverhalen?
Bovenstaande voorbeelden komen allemaal uit eigen ervaring en frustratie. Ik ben geen beveiligingsexpert, maar ben wel een heavy-internet gebruiker met wat basis usability kennis die zich ergert aan wachtwoordterreur op sommige websites. En ik ben vast niet de enige. Toch?
Marketeer voor betekenisvolle bedrijven.
Dit lijkt me persoonlijk nu juist geen goed voorbeeld van wachtwoord usability aangezien dit betekend dat de wachtwoorden zodanig zijn opgeslagen dat ze (vrij) eenvoudig weer terug te halen, iets wat een hacker zeker interessant zal vinden.
Onderzoek heeft uitgewezen dat automatisch gegenereerde, ‘moeilijke’ wachtwoorden niet veiliger zijn dan zelf-verzonnen, ‘makkelijkere’ wachtwoorden. Waarom? Dit heeft met security awareness te maken: gebruikers gaan zo’n moeilijk wachtwoord als geheugensteuntje opschrijven. Op geeltjes die aan hun monitor geplakt worden, in onbeveiligde excel sheet of opgeschreven in hun bureaulade. Daardoor wordt het ‘veilige’ wachwoord ineens veel onveiliger en weegt dit bijna niet op tegen het ‘makkelijke’ wacthwoord welke in ieder geval nergens wordt opgeschreven.
Leuke post Remi! Een frustratie die ongetwijfeld velen zullen herkennen. Ik ben het echter niet helemaal met je eens dat afkijken van grote websites altijd een goede methode is. Jakob Nielsen schreef hier ooit over:
“Although successful websites typically have high usability, average sites can hurt their business by copying design elements that don’t work well in other contexts.”
Je weet nooit wat de grotere website op dat moment aan het testen zijn, zij zijn namelijk de pioniers die hun eigen usability stelregels vaststellen. Deze zullen later door velen gekopieerd worden zodra de “mainstream” hier aan toe is. Kortom: bekijk meerdere best practices in je eigen branche (context), neem de stelregels (conventies) in acht en test indien mogelijk je eigen oplossing met users of door middel van a/b testing.
Als een bestaand wachtwoord terug gemaild kan worden, betekent dit over het algemeen dat die niet geëncrypteerd is opgeslagen in de database. Dat is bij voorbaat al een beveiligingsrisico. Normaal gesproken worden wachtwoorden versleuteld opgeslagen en kunnen niet weer gedecrypteerd worden. Inloggen gebeurt door het opgegeven wachtwoord ook te versleutelen en deze vervolgens te vergelijken met het versleutelde wachtwoord in de database. Als je het wachtwoord bent vergeten, moet je volgens dit systeem dus altijd een nieuwe aanmaken. Dat is ook wel zo veilig.
Overigens zijn er denk ik heel veel mensen die aangeven dat het wachtwoord opgeslagen mag worden via de ‘onthoud mij’ of in de browser. Qua usability natuurlijk perfect, maar voor de beveiliging toch zeker ook een risico.
Ik mis twee dingen in dit artikel:
1. Een relatie met het belang van de website/applicatie
Als mijn wachtwoord op Marketingfacts wordt gehackt, is dat vervelend. Als het wachtwoord van mijn Gmail wordt gehackt, is dat zeer ernstig. Als echter mijn Digid-wachtwoord wordt achterhaald, kan dat rampzalig zijn.
Nou stelt Digid zeer zware eisen aan het wachtwoord (lengte, gebruik hoofdletters, cijfers, vreemde tekens etc). Gezien het belang kan Digid dat echter beter verantwoorden dan wanneer Marketingfacts het zou doen.
2. Inloggen via je Hyves, Twitter, Facebook,. Google account
Veel internetters hebben een account op een social media netwerk. Als je dat account kunt gebruiken om je te identificeren (zie bv http://www.mtv.nl ), maakt dat de aanmelding vaak laagdrempeliger en zul je als site/app bovendien nog maar weinig te maken krijgen met verlies van (deelnemende) bezoekers omdat ze hun wachtwoord kwijt of vergeten zijn. Nadeel is dat je een apart registratiesysteem nodig hebt voor mensen die bv geen Facebook hebben, en dat je misschien gegevens zou willen weten die je niet (zomaar) via een dergelijke API-koppeling krijgt.
De laatste opmerking van David van Dam is overigens idd relevant. Zo zit in de opties van Google Chrome een knop “show saved passwords” waarmee elk opgeslagen wachtwoord doodsimpel zichtbaar gemaakt kan worden, hoe complex dat wachtwoord ook is. Bovendien zie je meteen *alle* sites waarvan een wachtwoord is opgeslagen. Een kind kan de was doen.
De ’truuk’ die ik gebruik is de volgende;
Ik heb een ‘strongpassword’ combinatie van tekens die ik kan onthouden en altijd gebruik.
vervolgens voeg ik iets site specifieks aan het wachtwoord toe dat ik altijd op dezelfde ‘strong’ manier doe.
en via een kleine vaste berekening die ik loslaat op het aantal tekens van de domeinnaam voeg ik daar nog een cijfer aan toe.
klinkt ingewikkeld, is erg makkelijk want opbouw altijd zelfde.
En zo heb ik voor iedere belangrijke login een unieke, moeilijk te kraken wachtwoord
(
off topic.. wat ook vervelend is is dat verificatiecodes te snel verlopen. ik heb nu al een paar keer hier op marketingfacts dat ik na ‘plaats reactie’ op de pagina ‘u heeft verkeerde code ingevoerd’ terecht kom.
betekent refresh pagina, opnieuw invoeren details en reactie.
)
@ Pepijn,
Daar zit wel wat in, misschien is het opschrijven van wachtwoorden niet altijd zo erg. Zolang het in je eigen huis is natuurlijk. Op werk is dat toch weer een beetje anders.
@ Menno,
Handig! 😉
Leuk artikel!
Daarnaast vind ik het altijd erg prettig om mijn emailadres als username te gebruiken.. Zodat je niet op iedere site een andere naam hoeft te verzinnen..
Nog een fout voorbeeld:
Hi heeft sinds de nieuwe site veranderd dat je niet meer op je “mijn Hi” kunt inloggen met je 06-nummer en een wachtwoord. Nee, nu heb ik een prachtige username van 4 letters, een teken en 5 getallen!
“Hi houdt het simpel” zeggen ze dan..
Ik heb in de afgelopen tien jaar een handjevol standaardwachtwoorden voor mezelfd ontwikkeld uit een combinatie van letters, cijfers en gekke tekens. Lekker strong en gelukkig is er altijd wel eentje die door de regels van een specifieke site heenkomt. Ik weet van sommige accounts niet direct m’n wachtwoord, maar kan dan gewoon een paar uitproberen.
Vandaag uit voorzorg vast Digid aangevraagd en die maken het inderdaad wel heel bont:
* Bevat minimaal 1 kleine letter [a-z]
* Bevat minimaal 1 hoofdletter [A-Z]
* Bevat minimaal 1 cijfer [0-9]
* Bevat minimaal 1 leesteken: [-!$%&’./:?@[]^_`{|}~]
* Bevat niet de gebruikersnaam
Niet de gebruikersnaam en combi van letters, getallen en tekens vind ik zo langzamerhand superlogisch. Die hoofdletter haat ik, net zoals ik het haat wanneer mijn username ergens CecileBol ipv cecilebol blijkt te zijn en de inlog case-sensitive is. Maar dat leesteken spant de kroon, want dit lijken alle mogelijke leestekens, maar dat zijn ze niet! Heb je een leuk leesteken uitgezocht, staat ie weer niet in het rijtje. Grrrrrrr!
Ik vind het bijzonder storend dat je suggereerd om mensen hun oude wachtwoord toe te mailen. Dit suggereert namelijk dat dit wachtwoord op het backend systeem is opgeslagen in een leesbare (of na decryptie leesbare) manier. het kan geencrypt in een db staan maar de private key van die encryptie staat waarschijnlijk op dezelfde machine en is waarschijnlijk voor de webserver toegankelijk.
Vooral omdat mensen vaak wachtwoorden hergebruiken is het bijzonder belangrijk om dit op het systeem niet inzichtelijk te hebben. (boze werknemer of hacker kan er dan niets mee). 1-weg encryptie dus.
dit is al argument genoeg maar daar komt nog bij: het toemailen via een onveilig medium (email) maakt het nog aannemelijker om dit wachtwoord te kunnen sniffen. Bij een mailaccount van een ISP hebben de helpdesk medewerkers hier toegang toe bijvoorbeeld. Zo ook kan een virus/backdoor op een pc eenvoudigweg de mailbox scannen naar “password” en deze verzamelen.
erg slecht advies
Gerelateerde artikelen
Marketingfacts. Elke dag vers. Mis niks!
Marketingfacts. Elke dag vers. Mis niks!