Nice. Note, though, that accurately capturing the colors will let a bad guy brute-force the password one character at a time, which is trivial. Don't use this if you're worried about shoulder-surfers with cameras, or just plain don't use this with important passwords.
(Note that switching to a proper cryptographic hash does not stop the above attack.)
Just reduce the entropy. E.g. use 20 colors instead of 4 sextillion. That still helps the user a lot (a mistyped password has a large chance of having a different color). But it only reduces the number of passwords an attacker must try to 1/20th.
It reduces it from ~64^password_length to ~3^password_length, and that assumes that the password is a random jumble of letters. If it's a long phrase, like "I know the entropy of English words isn't terribly high, but a lot of them make a better password than what people typically choose", the effect is even stronger.
Note, though, that accurately capturing the colors will let a bad guy brute-force the password one character at a time
How so? Since this is generated from the hash, this attack doesn't reveal more than an hash does, and you certainly can't brute-force one char at a a time from an hash.
Assuming I record the colours generated when each character is entered, then I have a hash of just the first character. Cracking that is trivial. Then I can go and crack the second character.
There might be a tiny amount of fuzzyness if I can't exactly match the first character hash, but it would be fairly close. I suspect it would be fairly easy to write a computer program which even did this automatically, from a recorded video.
Why not just use a video camera to watch them type on the keyboard? Plus, mobile devices show the last character typed. You're right, but this could be avoided by (for example) only displaying colors after 4 characters are typed
I think a better solution would be to only show the colour hash after there hasn't been a keypress in a few seconds. This would likely be a pretty good way of making sure you only displayed the hash after they were done typing their password, which would prevent enabling a brute force attack.
You could delay the display of the color pattern until the user has stopped keying for a second or so. That way, the shoulder surfer would not get incremental versions to work from, unless the user types really s l o w l y.
Lotus Notes has been doing this for years with a series of images instead of colours. It's an interesting idea but I think it's more confusing than helpful.
I've seen projects that generate a character or robot from a hash, and that could be interesting here, too. I agree that it's probably more confusing than helpful, though.
Between stupid complexity requirements and "you can't repeat that password", I end up with "password" on one site, "Password1" on another, and "Password1!" on yet another. (Obviously I don't use "password" but a secure passphrase that I only use on less-secure sites.) I don't remember which site has password, but I could potentially remember that site X was Green-Blue-Magenta, and correct accordingly.
I just signed up to a fresh stackoverflow account and got this "passwords must contain lowercase, uppercase and a punctuation mark" BS. It's the only site in the last 2 years+ that I've signed up with that has historic requirement.
I prefer the >12 character simple password to the random digit type and I'd have expected better from a site devoted to technical experts as Stackoverflow is.
I hate requirements like that. My hunch is that they the SE team hasn't put a ton of thought into the account creation process because they also support OpenID. I didn't even realize that you could login to StackOverflow without using OpenID!
Just write complete sentences if you're doing your password remembering, they will easily fit all requirements and are quite easy to remember.
You only have to worry about character limits and no spaces requirements that some sites have (which are a billion times more annoying to me than requiring certain types of characters).
I recommend learning to use a password manager to automate creation of secure passwords and controlled by a single passphrase.
1. A good password manager can run or be made to run on many platforms, including mobiles and flash devices.
2. If you happen to use a single password frequently, then you should not forget it anyway regardless of whether you or a computer made it.
3. With throw-away/automated passwords for every site/usage, you can be more confident in allowing passwords to be saved for convenience in application password databases, e.g. browsers.
4. A good password manager should allow generating passwords based on common patterns which can be customized per site. Therefore, you become almost completely indifferent to the bizarre rules that some sites may require (since you only have to flick a few checkboxes once).
5. Password managers can easily measure and show you the entropy for your password.
A good one to use is Keepass though there are other competitive ones.
When you enter your password in a password field, the characters are obscured, making it harder to tell when you've made a typo.
So, if your password is "Humpty Dumpty sat on a wall" and you accidentally type in "Humpty Dumpty sat on a ball" you would immediately realize your mistake, because the password's color signature would be different than what you're used to seeing.
Of course, my preferred solution to this problem is to allow the user to toggle the password field, so that they can view the unobscured text if they wish.
That would require the user to be quite vigilante when they are entering a password on a website. Getting up to go to the bathroom could mean someone steals their password.
Tested Firefox and Chrome, they both clear the password field but leave the username. I'd be interested to hear if there is a browser that leaves the password field intact.
My comment is in response to the discussion about this:
"Of course, my preferred solution to this problem is to allow the user to toggle the password field, so that they can view the unobscured text if they wish"
I am assuming that if the password field is being toggled, that it is not actually a password field but rather a regular text field with some javascript stuff messing around to hide the text. That would probably function just like a username field. I'm not really a web developer though, so it is possible my analysis isn't correct.
This is cool, but ultimately worthless- even detrimental to security. The only problem this could possibly solve is that user has to wait for a reload before trying their password again.
For an attacker, this becomes a lot easier break into. Let's suppose the attacker managed to get the exact values of the RGB (perhaps screen shared). He could run a dictionary attack or brute force on the algorithm and wait until he gets a match. This alleviates an attacker from two previous requirements.
1. A salt if all they had was a hash.
2. Hitting a server to check if the password is valid (thereby passing any potential lockouts).
I think a better usage would be to show two patterns - one of the password being entered and another for the password on file. Salt the passwords obviously before generating a pattern.
The idea is that I have a dozen of passwords, and some I use only when there are stupid password restrictions in place, e.g. "one uppercase letter, one digit, no special symbols". Since these restrictions are not shown on the Login form, it is frequently hard to remember which password I used with this particular site, so having a hint would help a lot.
The idea is nice but in theory but that would be a _huge_ security risk. You'd be providing anyone you know with your encrypted password, as well as the encryption method.
The server will send down a hash function, a salt and its version of a password hash. Use something like bcrypt or PBKF2, reduce their output by folding or by funneling through something like CRC to mitigate the risk of brute-forcing. Alternatively, keep salt/hash on the server side and make the client ajax the current hash from the server.
Why not do this with hieroglyphs instead of colours? I have deuteranomaly and colours don't work for me. I remember reading %10 of male population has some kind of colour deficiency.
Its name escapes me, there's a website which you enter a url, it goes and fetches the css, changes the colours such that I can't differentiate it from the original but a normal person would. By my wife'a account there are really huge differences between the two. I'll probably not be able to distinguish some colours where the green component makes the difference.
I'm not really clear on how it or color blindness in general works. So I don't know if finding the filter which makes the image unchanged for me (color-blind) is a good way of representing how the world looks to "normal" visioned people.
Thanks, that was it. No, it's not about representing how the world looks to normal visioned people, it's about how we cannot differentiate between some colours, or all colours for the worst case.
I hope your password is not encoded in the javascript.
And if the script tries it via asynchronous requests every time you type a character until you give the right password, think about the network overhead involved. And if you use this solution, how do you distinguish between a sloppy user (that recognizes (s)he hit a wrong key and immediately corrects it) and a bot trying to guess a password?
If I understand correctly, you're talking about confirming whether a password / confirm password box match. The purpose of the three colors is that they are displayed next to the password box every time the user types their password in, providing a visual clue as to whether they've entered their password correctly.
