The Problem with Passwords

by Lyle Mullican

46 Reader Comments

Back to the Article
  1. @olaim, the only problem I have with using a separate text field is that because it needs its own unique name and ID, it won’t inherit ID-based CSS or JavaScript, so it’s less transparent in that way.

    Several comments, though, seem to think that revealing the password in plain text somehow creates a security problem. The fact is that it’s stored that way in the DOM anyway. JavaScript can read it, and it’s transmitted as text in the HTTP request (which will hopefully be encrypted using SSL/TLS). I maintain that the only threat model masking protects against is physical observation. Dots in a form are not encryption.

    As far as autocomplete goes, it can be disabled by code as well (beyond the scope of my demonstration). A public/shared computer shouldn’t have it turned on anyway, as we’re likely to type all sorts of sensitive data into non-password text fields (credit card numbers for example).

    Copy & paste the code below to embed this comment.
  2. I agree making passwords clear text or will help security or people remember passwords, the options mentioned do help people remember.

    A great example is Media Temple’s account pages.  There are multiple passwords I manage for my account such as FTP, email, and my over all system password.  If I forget a password I would have to reset it.  BUT Media Temple gives me the option to show my password in clear text, keeping me from reseting it.

    Great article!

    Copy & paste the code below to embed this comment.
  3. Virgin Credit card use a novel method of seperation; forcing the user to enter a username, then on the second page asking for a password. Not bulletproof but it would slow down any script used in bruteforce hacking.

    Out of the examples provided I prefer #1 as I can see that people at home using their PC’s would care more about being able to log in correctly then someone in the household seeing their password. It’s an odd UX challenge when you consider that password hashing has been present in software since the 70s and people are very much used to it, so I cant see a huge advantage to modifying the default password hashing behaviour.

    Copy & paste the code below to embed this comment.
  4. I agree that the ‘iPhone’ method is a good idea and could improve user experience when logging into a site.  My only problem here is that Apple didn’t invent this.  It has been around on mobile devices for years before the iPhone even existed (Windows Mobile, to give one example).

    Copy & paste the code below to embed this comment.
  5. Echoing the comments raised above, the irony is that ALA fails dismally in password management. For some reason the username and password I used to use stopped working and I now have a new username and password that I can’t remember. So I have had to request a new password, which I won’t be able to remember, and I can’t see any way to change it to one that I will remember. So every time I want to comment on an article I will have to go through the same wretched process.

    Password restrictions are far too complex. Many sites require people to register, even though there is no good reason for doing so. Many sites that need passwords have particular requirements, in terms of length of password and type of characters – some can only include letters and numbers, some must use capital and lower case, some must include non-alphanumeric symbols – all of which means that users have to use multiple different passwords, which significantly increases the chance of them failing to remember the right password, or choosing a password that is blatantly guessable.

    As for Nielsen’s suggestion of putting passwords in plain-text – no, no and no! I did email Nielsen the day after he wrote that article to point out a number of usability flaws in his plan, but of course there has been no response or follow-up, as his articles are the gospel truth from the one true guru and are not susceptible to suggestions or improvements by mortal plebs like the rest of us (sorry, rant over)…

    Firstly – security concerns. Passwords have been masked since time immemorial because it prevents other people standing nearby from reading them. Allowing them in plain text would be criminally negligent in terms of exposing accounts to hacking. You might as well just write a list of all your passwords on a piece of paper and stick it to your monitor. I can see the argument for allowing plain text on a device like an iPhone that can’t easily be seen by other people, but on a normal monitor, it is totally unacceptable.

    Secondly – usability. When I am logging into a website, I know that what I see in plain text is my username, and when I see a string of asterisks or blobs then I’m typing my password. That is a valuable visual cue, and can help prevent instances like the one where a previous contributor typed their password into a chat box. People are used to the way logins work now, and changing it would raise a number of problems while offering minimal benefits.

    Copy & paste the code below to embed this comment.
  6. <div>Those are good scripts, but there’s a little bug in the second alternative script.
    In the part that says:var input = inputs;
    It should say:var input = password_inputs;
    The original will break when there are input elements other than password.
    </div>

    Copy & paste the code below to embed this comment.
  7. Ups! (it appears that HTML doesn’t render as source code as said in the comments form)var foo; //The “<pre>” tags shouldn’t appear

    Copy & paste the code below to embed this comment.
  8. I like the idea with the checkbox behind it but it will make your form realy wide.

    BTW in example2 if you type fast you will not see your last char. (or at least in chrome.)

    Copy & paste the code below to embed this comment.
  9. I can’t wait until all sites implement “show password” checkbox, so I’ve made “Show Password on Focus”:http://github.com/NV/show-password-on-focus.js (“Chrome extension”:https://chrome.google.com/extensions/detail/ogjaejebjmifpkiaafdnnpkkjnmopmhn and “user script”:http://userscripts.org/scripts/show/68664 ).

    Copy & paste the code below to embed this comment.
  10. Am I the only one – who cant remember brazillions of userids and passwords?

    Guy kawasaki blogged last year – about web sites expecting one to remmeber all sorts of permutations and combinations: oh this doesnt take – here its user name !!

    and well, there is another annoying thing aside from hacks and what else..:

    its verify and then the captcha

    and while i am at it:

    can someone break the news to lemondrop – verifying every comment – via a click to email = bad karma on the net

    cheers, regards and regrets

    olga-nesher-lednichenko

    Copy & paste the code below to embed this comment.
  11. I have test it and work very well, and its a very nice idea.

    The only think I like to notice is that you can check if the password is allready there by the browser, and if it is do not show the button, because then its easy for some tried person to see it in a second.

    So add this line if(input.value == “”) to not show anything if the password exist there from the browser.

    if(input.type ‘password’) {
      if(input.value “”)
      {

    Copy & paste the code below to embed this comment.
  12. @Aristos: To disable the `Show password’-button if the browser pre-fills it for you, is a good idea. But it still means that a person sitting next to you could see the password you have just typed into that field, if he is quick (and a not so good friend).

    What I proposed in my former post will prevent this from happening:

    1. When the user checks the `Show password’ box, a new, empty text field is created, and the original password field is hidden behind the new field.

    Then no one will ever see what anyone (else) has written in the password field.

    Copy & paste the code below to embed this comment.
  13. The idea of having clear text passwords may be alright if I’m working on my home pc but if that was the web standard then User accounts would be getting hacked left,right and centre. 
    The idea to toggle between the two is okay but involves more code and maybe over complicates the login process however admittedly I have used the feature on my router before.

    Personally I think a less secure easy to remember password is better than having only a clear text password input field, but I would personally always recommend using strong passwords and having them hidden from view.

    Copy & paste the code below to embed this comment.
  14. Any time you use JavaScript to access and store passwords, you are demonstrating what any advertiser can do on your site.  Truly, the only reason why the user name/password combination is in prevalent use today is because it is easy to implement.  Other options that are arguably more secure such as PKI (caveats with that as well) and biometrics are notoriously difficult to do on the web.

    I like the concept of OpenID, which provides some creative ways around the whole user name/password concept.  For example, the people at “My OpenID” (myopenid.com) provide an option to generate a key that is specific to your browser.  As long as your browser has that key and you have the password to that key you can get into any website that supports the OpenID protocol.  Of course, this presents problems with internet cafes.

    The real solution is to find something other than arcane passwords to protect access to the site, that still gives both the web site and the user a high confidence level.  A real solution will also address site spoofing (phishing attempts) which is a real problem.

    Any solution that allows access to what I typed through JavaScript demonstrates just how easy it is to steal credentials.  To all web designers: do not allow advertising on any page that takes in passwords.  It is too easy to accidentally include malicious ads, and even in HTML 5 there is no appropriate sand-boxing of content that originates from other servers.

    Copy & paste the code below to embed this comment.
  15. There are obvious usability issues with not being able to see the password you are typing.  There are also times where it would be more practical to just see a password in an admin panel rather than have to reset it.  There’s no rational reason why a person signing into their “A List Apart” account from their own office shouldn’t be able to see the password as they are typing it. 

    Regardless of this, making this information visible might draw complaints from users because it is different from their expectations.  There are also many times when the highest level of security is critical.

    Having a “View your password as you type” link is a no-brainer for non-senisitive logins.  It allows the user to judge whether they feel secure in their environment.  Additionally, a popup layer could provide additional instructions “Use this if you are in a private location.”

    Taking responsibility for this, improves the success of the site.  So why leave it to the browser or os.  Most users will not know how to use these features anyway.

    Copy & paste the code below to embed this comment.
  16. function togglePassword(elementId, showText) {
      var newPasswordField = $(elementId).clone(true);
      $(newPasswordField).attr(‘type’ , showText ? ‘text’ : ‘password’);
      $(elementId).replaceWith(newPasswordField);
    }

    Copy & paste the code below to embed this comment.