The other night I was walking a class through an application which has a simple user management / credentials scheme. When you create an account, the password and password confirmation fields had the characters masked out, but when we got to the ‘ya! it worked!’ page it was displayed in the clear for the whole world to so. Instantly people started pointing out ‘a bug! a bug!’. But was it?

A trick question of course. The answer is, maybe.

I’m going to disclaim the description of what I said next with the opinion that passwords should always be masked, hashed and transmitted securely. Always. But the discussion was surrounding requirements and how your idea of what the requirements should be might not line up with the actual requirements.

So, in general, a password might not need to be always masked when

  • You warn users anywhere that the password might be shown in clear text and to use a unique password that is not used anywhere else
  • Your application has a means to ‘request your password’ and the existing one is transmitted in the clear
  • Your login process occurs over a non-secure connection
  • The password is only being displayed to someone who as identified themselves as the owner of the password

A password should be masked when

  • The place where the password is appearing can be viewed by someone other than the user (such as a log file)
  • The common place of usage is a public space (such as a library)
  • Your application is projecting an image of security

All that said, when I am testing anything that looks like a password, this is what I am looking for

  • Passwords masked everywhere
  • Password masks are always the same length regardless of the length of the password
  • Any time the password is transmitted, its is over a secure channel
  • Password is hashed when stored in the database
  • Reset password functionality does not send the existing password. Instead sends a random one which the user is prompted to change once it is used