There are size approaches to password masking:
- Traditional masking (
type="password"
)
- No masking at all (
type="text"
)
- Optional masking, turned on by default (
type="password/text"
)
- Optional masking, turned off by default (
type="text/password"
)
- Delayed masking ala iPhone, Andriod phones, etc (
type="doityourselfzomgmagicbbq"
)
- No-response/blank masking ala bash and other terminals
We can't really argue with approach 1. It's the standard to which millions of users have grown accustomed. Why break what really isn't broken. Approach 2 is, imho, just plain silly: no one will trust your application.
In my opinion, Approach 3, is the best of both worlds. "Normal" users will probably never know it's there since it appears as a normal password field by default; yet, it gives more sophisticated users the control to switch back and forth between masked and unmasked. This is typically found in applications that require extremely long passwords (like 32+ character WPA keys).
Approach 4 is probably more suitable for low-risk and trivial applications, but I wouldn't use it.
Approach 5 is a neat idea, but difficult to implement well (still behaves like a normal input field, etc) in HTML. It's great for mobile devices and platforms that support it as a native control, but for general use in web applications, it might be more trouble than its worth.
Approach 6 is the norm for command line applications (you type your password but nothing appears on screen). This may be considered as even more secure (since password length cannot be seen), but since users are accustomed to having some sort of response for almost every action they make in a web application, this approach probably wouldn't be accepted well, resulting in much confusion and frustration.