Jakob Nielsen: Verberg wachtwoorden niet

Enkele weken geleden pleitte usabilityguru Jakob Nielsen om wachtwoorden niet langer te verbergen achter bolletjes.

Zijn belangrijkste argumenten:

  • Gebruikers maken vaak fouten bij wachtwoorden omdat ze afwisselen tussen hoofd- en kleine letters en cijfers en letters.
  • Het gebrek aan visuele feedback verhoogt de kans op fouten. Gebruikers kunnen niet zien of ze een fout hebben ingegeven.
  • Verborgen wachtwoorden zijn niet echt veiliger. Wie wil, kan op het toetsenbord meevolgen wat de gebruiker intikt.
  • In 95% van de gevallen kijkt er niemand mee en zit de gebruiker rustig alleen achter zijn scherm.

Zijn besluit: de minieme winst aan (schijn)veiligheid weegt niet op tegen het verlies aan bezoekers die problemen hebben met registreren en inloggen. Nielsen raadt wel aan om de gebruiker via een aanvinkveld toe te laten zijn wachtwoord toch te verbergen. Bij zeer gevoelige websites (bijvoorbeeld banken) raadt hij aan het aanvinkveld standaard aan te vinken.

Wat denk ik?

Nielsen is niet dom. Hij heeft absoluut gelijk dat de ‘bolletjes’ vaak voor verwarring zorgen. Mensen weten niet of ze zich vergist hebben of waar ze zijn gebleven, en dan beginnen ze maar opnieuw. En dan zuchten ze wel eens. Dat zien we geregeld tijdens user tests.

Ook zijn argumenten dat de ‘bolletjes’ weinig bijdragen tot echte veiligheid kloppen grotendeels. Al wil ik voor die 5% van de gevallen dat iemand meekijkt toch ook het gevoel hebben dat niet iedereen gewoon kan zien wat mijn wachtwoord is.

Maar er is ook zoiets als het subjectieve gevoel van veiligheid. Ik herinner me 2 gebruikerstesten op ontwerpen waarbij het wachtwoordveld niet ‘beveiligd’ was en dus gewoon open en bloot op het scherm kwam te staan. Tijdens die testen kregen we spontaan opmerkingen van 8 op 10 gebruikers en die waren negatief. Uitspraken als “Oei, dat is toch niet normaal” en “Echt veilig is dat niet”.

Daarom ben ik niet echt gewonnen voor het open en bloot tonen van wachtwoorden.

Wat doet Apple?

Als je een wachtwoord ingeeft in de iPhone wordt het laatst ingegeven karakter voor een korte tijd getoond. Op die manier krijgt de gebruiker visuele feedback maar staat het hele wachtwoord nooit volledig zichtbaar op het scherm. (Dit systeem bestaat trouwens al heel lang op toestellen van Nokia die op Symbian draaien.)

Kan dit ook op het web?

Blijkbaar wel. Een zekere Chris Coyier ontwikkelde 2 varianten op het iPhone-systeem voor het web. (Voor de techneuten: op basis van jQuery – meer uitleg over het script en mogelijkheid om de bestanden te downloaden).

Hoe moet het nu verder?

Mijn buikgevoel is gewonnen voor iPhone variant 2 van Coyier, al moet het script blijkbaar nog wat verbeterd worden om echt aan alle standaarden te voldoen (momenteel werkt het bijvoorbeeld niet in IE 7).

Om echt iets te kunnen aanraden, moet het getest worden. Wij zullen alvast aanraden bij klanten om er via A/B testen achter te komen wat het beste is:

  • Het klassieke ‘bolletjes’-systeem
  • De iPhone-variant
  • De Nielsen-oplossing (tonen maar met een checkbox om het wachtwoord te maskeren), liefst 1x maal open en bloot en 1x met het wachtwoord standaard gemaskeerd. Hier alvast enkele voorbeelden van deze aanpak.

PS: Dit artikel is gebaseerd op een artikel dat ik las op MediaKip, de blog van Michel Kuik.

Artikels die je zeker ook interesseren

GD Star Rating
loading...

Lees 9 reacties op dit artikel | Reageer op dit artikel

Mis het volgende artikel niet!
Abonneer je via onze tweewekelijkse nieuwsbrief of RSS ( abonnees).

Volg de usability blog op Twitter voor meer tips en links.


Opleidingsdag usability en schrijven

Op 1 dag leer je van de makers van deze blog hoe je website beter kan. Een dag vol praktische tips!

  • Teksten optimaliseren voor het web
  • Verbeter de conversie en usability van je website.
  • Inclusief bespreking van je website
  • 9,1/10 is de gemiddelde score van de 356 mensen die deze opleiding volgden
  • Volgende editie: 24 mei 2012, Leuven

Bekijk het programma en schrijf je in


  • http://ict.lithium.be Bart Gysens

    Heel eenvoudig mijns inziens.

    Voorzie gewoon een checkbox of knopje waarmee je als gebruiker je wachtwoord tijdelijk kan ‘scrambelen’ als iemand plots naast je opduikt vanonder de tafel.

    Kan via eenvoudig javascript.

    Andere bedenking: promoot OpenID

    @wadje12

  • Dennis

    Ik vind het onwenselijk als mijn wachtwoord open en bloot in een veld wordt weergegeven. Hetzelfde geldt voor registratiemailtjes waar mijn wachtwoord nog een keer herhaald wordt.

    Ik vind de iPhone variant een prima toevoeging, maar het blijft in mijn opzicht toch niet echt een probleem. Je moet bijna altijd een controleveld invullen en de kans is niet zo groot dat je het twee keer fout doet.

  • http://www.automaton.be Toon

    Een wachtwoordveld in een online formulier is ook specifiek soort invulveld, waardoor de browser weet dat daar een wachtwoord in staat en die data dus ook gepast behandelt. Als je daar een gewoon tekstveld van maakt verhoog je toch het risico dat anderen die dezelfde pc gebruiken dat wachtwoord, zelfs per ongeluk, gewoon kunnen zien.
    Het zou inderdaad beter zijn als je het laatste karakter van een wachtwoord even ziet voor het onzichtbaar wordt, maar dat lijkt me meer een taak voor browserfabrikanten dan voor webbouwers, kwestie van via Javascript-truukjes geen andere veiligheidsproblemen te creëren.

  • Steven

    De laatste letter tonen is zeker een goed alternatief. Op de laatste blackberry’s wordt dit ook gebruikt. Alleen jammer dat het in Internet Explorer 7 niet werkt…

  • Dries Schuddinck

    Ik vind het tonen van het wachtwoord heel ongepast. Als je met een iemand aan een pc zit en je wilt hem iets tonen op website of mail waar je moet op inloggen, dan wil ik niet dat deze persoon ziet wat m’n wachtwoord is. Het is maar aan de gebruiker om z’n wachtwoord goed in te geven.

    Het is inderdaad de bedoeling om het net zo gebruiksvriendelijk mogelijk te maken, maar dat mag echt niet ten koste gaan van de veiligheid! Wanneer iemand je wachtwoord wil stelen door hacking of iets dergelijks is dat al een heel paar ander mouwen, dat is zoals je huis beveiligen tegen inbrekers, je kunt altijd maar blijven beveiligen en versterken, maar als ze willen binnen zijn, dan zijn ze het toch. Maar dat wil niet zeggen dat je geen slot nodig hebt op je deuren, als je begrijpt wat ik wil zeggen.

  • http://usability-vlaanderen.blogspot.com/ Edwin

    Karl,

    Terug uit verlof en al dra op heilige huisjes aan het schoppen, that’s the spirit 

    Ik deel je mening volkomen. Puur vanuit usability standpunt heeft Jakob gelijk, vanuit security standpunt echter niet.

    Je kan een huis met huissleutel als metafoor gebruiken. Vanuit een usability standpunt is een huissleutel zeker een nadeel:

    • Je moet hem bijhebben, anders kan je niet binnen
    • Je kan hem verliezen, wat mogelijk extra kosten betekent
    • Eventuele dieven geraken zonder die sleutel ook wel binnen

    Toch zul je weinig (eigenlijk geen) huizen aantreffen die geen huissleutel bezitten. Het is voor een deel fictieve veiligheid, maar je wil het anderen nu ook weer niet té gemakkelijk gaan maken om je huis te betreden.

    Het verbergen van een wachtwoord is zoals die huissleutel. Het geeft mensen een fictief gevoel van veiligheid, die meestal niet eens vereist is. Maar…

    • …in een open kantoor omgeving kan deze best handig zijn.
    • …je wil niet dat bijvoorbeeld kinderen zomaar het wachtwoord zien van de parental lock op de pc of DVD speler.

    Mijn aanvoelen is dat voor korte wachtwoorden van relatief onbelangrijke zaken het klassieke systeem wel het beste zal zijn. Er is geen gedoe, het schept geen verwarring en het gebrek aan volledige feedback is toch maar van korte duur.

    Voor (verplichtte) lange wachtwoorden, zou de ‘Nielsen’ (die niet van hem is) wellicht het beste zijn. Er is meer nood aan feedback, de kans op een verkeerde invoer is immers groter.

    De iPhone oplossing werkt niet op een computerscherm. Toevallig heb ik zo’n systeem in werking gezien in Frankrijk bij een bekende Japanse bandenfabrikant. Alhoewel niemand klaagde zag ik bij de contextuele taak observaties dat wanneer ze niet alleen waren dat mensen het scherm bedekten met hun hand. Er is immers nog altijd even zichtbaar wat je ingetikt hebt en je moet dan geen Einstein zijn om alsnog het paswoord te achterhalen. Maw. het nut gaat compleet verloren.

    Op de iPhone is dit wel een goed systeem, omdat de context compleet anders is. Je hebt die in je hand en is daardoor altijd gemakkelijk af te schermen van anderen.

    Dit onderwerp was ook ‘hot’ op Slashdot en sommige nerdjes hadden interessante bijkomende bedenkingen. Eentje vertelde dat wanneer je op een Linux systeem een paswoord moet intikken je niets feedback te zien krijgt, geen bolletjes, geen sterretjes, nada. Sommige vonden het gebrek aan totale feedback (en dus usability) nog veiliger en voor sommige omgevingen is veiligheid nu eenmaal wel een issue.

  • http://ict.lithium.be Bart Gysens

    Jullie gedacht over deze geïntegreerde aanpak: http://ego.virthium.be

  • http://www.agconsult.be Karl Gilis

    @ Bart

    Niet slecht. Laatste teken blijft naar mijn gevoel iets te lang staan.

    @ Edwin
    Het is inderdaad waar dat je het scherm van een PDA/GSM/iPhone/whatever beter kunt afschermen dan dat van een PC.

  • http://www.librarian.be Patrick Vanhoucke

    Interessante problematiek, maar ook moeilijk om een beslissing te nemen die gebruiksgemak met veiligheid verenigt.

    Het gewoon tonen van wachtwoorden kan in bepaalde gevallen erg oncomfortabel zijn. Denk inderdaad aan een situatie waar iemand voor een collega, klant… iets moet demonstreren en een wachtwoord moet invullen. Of bij nieuwe medewerkers die in dienst komen en die hun eigen wachtwoord moeten kiezen. Ik denk niet dat zo’n medewerker het zal appreciëren als de collega die hem ‘begeleidt’ zijn nieuw gekozen wachtwoord zomaar op het scherm ziet staan. In de laatste twee gevallen is ook het kort tonen van het laatste teken geen oplossing, want als er iemand naast je voortdurend meekijkt heeft die uiteindelijk toch ook het volledige wachtwoord gezien.