Show HN: Using a color pattern to let a user 'recognise' their password (github.com)
This is just a concept I made that allows a user to discern whether they have typed a password correctly before submitting. The user never sees their password, but should be able to recognise it's pattern.
Thoughts?
64 comments
[ 1.8 ms ] story [ 138 ms ] threadhttp://www.easyautosales.com/register
(Note that switching to a proper cryptographic hash does not stop the above attack.)
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.
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.
http://colorfilter.wickline.org/
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.
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"
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.
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.
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).
Dumb examples:
The cat in the hat.
The cow goes moo.
My favorite number is 3.
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.
Chrome extension: https://chrome.google.com/webstore/detail/lkoelcpcjjehbjcchc...
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?
http://lab.arc90.com/2009/07/09/hashmask-another-more-secure...
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 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.
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).