Forum Moderators: open
His idea is - "Stop password masking", it's bad for usability.
I always thought passwords were sent via base-64 encryption even in plain HTTP, so making them open text is just opens all kinds of holes for security breaches at every level. What do you guys think?
I think the idea of a checkbox might be good, but it should require checking to make the password visible, and that checkbox should revert to masked default every time the page is refreshed, the window is closed, or the browser shut down.
I absolutely agree!
My suggestion:- Use <input type="password">
- Supply checkbox (or button/image) to toggle the type of the password field to type="text"
- Use JavaScript to display the checkbox (or button/image)
- Use onkeydown/onkeypress to check if Caps Lock is on and, if so, display noticeA couple benefits from this scenario:
- saved passwords remain hidden by default (although, toggling the input field type would certainly reveal the plain-text password)
- the more "secure" option remains the default
- typos due to Caps Lock being accidentally turned on are reduced
The big challenge is alerting users to Caps Lock being on. Visual cues are less intrusive, but are certainly much less usability/accessibility focused than a glaring
alert()Something like this might work:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Password Unmasking and Caps Lock Check</title>
<style type="text/css">
#capsalert {
color: #c00;
font-size: 80%;
display: none;
}
</style>
</head>
<body>
<form>
<fieldset>
<legend>User Info</legend>
Username:<br>
<input type="text"><br>
Password: <span id="capsalert">CAPS LOCK = on</span><br>
<input type="password" id="pwd">
<script type="text/javascript">
document.write(
'<input type="checkbox" name="masking" onclick="unmask(this.checked)"> ' +
'Show the password as I type'
);
</script>
</fieldset>
</form>
<script type="text/javascript">
function chkCaps(e) {
ev = (e ? e : window.event);
kc = (ev.which ? ev.which : (ev.keyCode ? ev.keyCode : false));
sk = (ev.shiftKey ? ev.shiftKey : (ev.modifiers ? !!(ev.modifiers & 4) : false));
if(
(kc >= 97 && kc <= 122 && sk) ¦¦
(kc >= 65 && kc <= 90 && !sk)
) {
document.getElementById('capsalert').style.display = 'inline';
}
else {
document.getElementById('capsalert').style.display = 'none';
}//end if
}//end function
function unmask(truefalse) {
elem = document.createElement('input');
elem.setAttribute('type', (truefalse == true ? 'text' : 'password'));
elem.setAttribute('value', document.getElementById('pwd').value);
elem.id = 'pwd';
document.getElementById('pwd').replaceNode(elem);
document.getElementById('pwd').onkeypress = function(e) { chkCaps(e); };
}//end function
document.getElementById('pwd').onkeypress = function(e) { chkCaps(e); };
</script>
</body>
</html>
Edit: Remember to replace broken pipes ¦¦ with actual vertical bars.
[edited by: DrDoc at 5:16 pm (utc) on July 7, 2009]
The big challenge is alerting users to Caps Lock being on. Visual cues are less intrusive, but are certainly much less usability/accessibility focused than a glaring alert()
I agree, an alert() or something else that takes focus away from the field would be the worst idea to make things easier for the average user - who just might look at the keyboard to type ... if he does so and notices when looking at the screen again that nothing he typed got registered, he's gonna be disappointed.
As in your example, I think it's ok if it's close to the form where the data is entered. A small Warning-Sign with explanatory text just below the password field will probably do just as well. locked my workstation to see what windows does, and I guess it'd be good to copy the style, so users see something familiar.
Schneier says he was 'probably wrong' on masked passwordsSecurity guru gets a bit carried away by the moment
[theregister.co.uk...]
In general I appreciate Nielsen's penchant for asserting sensibility on the industry.
- What about masking the password as usual for the first 2 attempts.
- If they both fail, pop up a small message that offers the possibility to unmask the field for the next attempts (with a warning about security issues).
- The user can then choose if he is in a safe enough place to unmask his password.
What are your thoughts on that ?
I thought this was not secure, what if someone took my mail, they could activate my card.
The bank informed me that a simple caller ID feature was able to identify my call and so no more questions were asked. If the phone number didn't match I'd have had to give more proof.
Passwords need that same level of extra protection imo, they should work wether plain text or not but a redundant IP check should be performed on subsequent visits (not an easy task with IP renewal on startup via DSL or cache clearing on browser session close etc, I know).
Schneier now backs an approach taken by BlackBerry devices and iPhones, which display each character briefly before masking it.
It sounds like a decent solution too. Both companies have the bucks to do some serious research and testing.
Is this solution easy to implement for everyone else? Maybe some of the code gurus here can say. Or maybe this new trick is proprietary.
The checkbox solution might still make logins a tedious ordeal for users of handheld devices.
Anyway, the Big Boys seem to be a few steps ahead of Nielson on this.
The checkbox solution would not make a big difference on handhelds. The problem with the checkbox is ensuring that people understand what it does, in as few words as possible.
Having each character temporarily show in plain text, and then become masked ... That's virtually impossible to achieve.
why? it should work quite fine with javascript, allthough you might not be able to use the standard masking character windows xp uses ... I don't see any problems with an asterisk. Of course, without javascript, there's no way to do it without the browser manufacturer, but many people have javascript enabled. do you see any other problem?
document.getElementById('pwd').replaceNode(elem); Does not work in FF.
replaceNode is native to MS Browsers.
So The DOM Way would be(me thinks)
oldElem = document.getElementById('pwd');
elem = document.createElement('input');
elem.setAttribute('type', (truefalse == true ? 'text' : 'password'));
elem.setAttribute('value', document.getElementById('pwd').value);
elem.id = 'pwd';
//document.getElementById('pwd').replaceNode(elem);
oldElem.parentNode.replaceChild(elem,oldElem);
I like the Idea a lot.
Blend27
I think the major hurdle with display what the user types in a password field would be the user trust issue. How do you convince a user that unless somewhere is watching over their shoulder it's just as safe. Most web users are probably so used to sites not displaying their password as they enter it, that if they suddenly could see it they might begin to question whether the site in question has been compromised.
It is interesting though how most people aren't considered that credit card fields display the correct numbers. Maybe more and more people check for https these days...
Having each character temporarily show in plain text, and then become masked ... That's virtually impossible to achieve.
