7 ms·
Show HN: Password validity hinting
- patrickod 15y agoWhile this looks very interesting I'd love to see what those with extensive knowledge of security think about this.
- drewblaisdell 15y agoFantastic work. This is one of the most unique usability tweaks that I have seen in quite a while. My only wonder would be how to implement this so that it doesn't confuse or intimidate users... but I'm sure there is an answer to that.
- kuroir 15y agoI don't know how I feel about this. To tell you the truth, I already did some small use test with 2 users (medium and advanced). And they both have a bit of trouble understanding what that sign was for. It also didn't help the fact that the outline of the password was distracting: http://dl.getdropbox.com/u/4651065/files/2012/3/Screen%20Shot%202012-03-10%20at%204.28.16%20PM.png http://dl.getdropbox.com/u/4651065/files/2012/3/Screen%20Sho... The idea itself is interesting, though without previous explanation or knowledge it's just hard to guess what it is about.
- latitude 15y agoThanks for the blue outline report. Should be fixed now. The idea is that the purpose of the indicator becomes obvious after some repeated use, and that it is not too intrusive or distracting on its own to be confusing to the new users.
- verelo 15y agoI'm pretty into this idea, im not sure there is enough information here for me to act on it but if i could be assured its safe (enough) and would require minimal impact to our existing hashing scheme, id give it a go. Thanks for sharing.
- rshm 15y agoI am interested on knowing the details on reduction part. Secure hash should not match partially.
- swampthing 15y agoThe thing that really confuses me is the indicator on the right - what do the different states mean? From reading the page, it seems like there are only two states that matter, likely or unlikely. But the way the indicator is constructed seems to suggest that it tells you how close you are to the actual password. If there are really only two states that matter, why not just have some sort of binary indicator?
- wonderercat 15y agoI suspect they are matching bits. Though since this is going through hashing, the number of matching bits has (by design) zero correlation to how close the P/W is. In which case, yeah, I think the binary indicator would be more useful and intuitive.
- blahedo 15y agoIn particular, if you just type "qwertyuiop" or "asdfghjkl" or the like, the password looks at least as good (better, really) than when you type the correct password, right up to the last character. So, not very useful?
- latitude 15y agoGlad you asked :) Indicator has two states - gray and black. Gray is further animated as a visual gimmick, the actual arrangement of it has no meaning. The idea is that the animation gives you visual feedback on typing and the change of color confirms that the password is not definitively wrong. And the assumption is that after some use, the users will get accustomed to seeing black indicator immediately prior to hitting Enter.
- tobias3 15y agoWhich hash function did you use? You cannot use a cryptographic secure hash function to calculate a distance between data. If this were possible you could use a gradient descent like algorithm to find pre images. (I.e. the whole hash changes if you change one bit in the input) And when I tested it, it looked like the symbol was completely random. (As it should be) Edit: It's called the avalanche effect http://en.wikipedia.org/wiki/Avalanche_effect http://en.wikipedia.org/wiki/Avalanche_effect
- latitude 15y ago> Which hash function did you use? There's nothing on the backend, just one hardcoded username and password. All it does is takes an sha1 of statically salted password, adds up all bytes and masks with 0xff. This yields 1-byte hash reductions, which are compared for equality.
- samdk 15y agoWhile this is possibly an interesting UI experiment, this paragraph says everything you need to know about real-world use: Utilizing something like bcrypt as a hash function is not an option, because the number of rounds needs to be reasonably low for it to work in real-time in Javascript. If you're not using a slow hash function like bcrypt, you're doing password hashing wrong. Your users' passwords are vulnerable to brute-force attacks as soon as your database is compromised. (And "my database will never be compromised" is not a valid response.) Before doing anything with your users' passwords, read this: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- wonderercat 15y agoYou could still use bcrypt and do the comparison work server-side. Depending on work factors and whatnot, it's now a backend load balancing issue. But it's probably solvable.
- sk5t 15y agoHmm... 1,000 clients trying to log in from machines with pretty fast CPUs, and you want to shift this highly compute-intensive, uncacheable, froo-froo-feature support load to the 1/5/10 servers on the backend?
- latitude 15y agoThere's no need to derive hinting (reduced) hash from the bcrypt hash of the password. Since all that's needed is even distribution of password space into 2^N classes, it can easily be done by looking at N bits of any password hash. Since N is low, even something like a now-obsolete MD5 would work.
- incandenza 15y agoBut these "classes" have no meaning. The only thing that means anything is whether the entire hash matches or not. Comparing a subset of bits just gives you random results, (aside from the case where the entire original hash matches). If something like this worked, it would provide a method of breaking the hash in a piecemeal fashion, which would mean the hash algorithm never worked properly in the first place. EDIT: reply to below: The only thing it can tell you is that two passwords don't match. It tells you nothing about whether they're similar. (And also doesn't tell you they do match, for which you need the whole hash.)
- rpledge 15y agoWasn't this kind of feedback the cause of the recent WPS flaw? How do you stop this from being used to brute force passwords?
- latitude 15y ago> How do you stop this from being used to brute force passwords? There's the whole section that talks about that.
- incandenza 15y agoThis doesn't make any sense. There is no "reduction" of a cryptographic hash that shows you anything other than "100% match" or "not 100% match". Essentially this is just displaying a random symbol along the side until the password matches completely. EDIT: I'm surprised more people aren't commenting on this. It should be clear that if there were any way to tell if a match were "close", that would totally defeat the purpose of a cryptographic hash. Essentially all this does it check the password (well, with extra meaningless false positives) without you having to press return.
- sk5t 15y agoExactly, it's just testing 8 bits of the hash rather than the whole thing. So there is a considerably greater than zero chance of a false positive on totally unrelated words... it's all quite silly.
- latitude 15y ago> it's all quite silly Which part exactly?
- nowarninglabel 15y agoThe part where you seem to be treating it like a breakthrough of some sort, when it's just a fun little gimmick. Your indicator is beyond useless, I just tried it on a user and they had no idea what that was supposed to indicate. There's similar reports out there. The setup is somewhat complex. The extra computational and network resources are not something to sneeze at. It looks like a fun project, but the idea that many sites would actually use this is quite silly
- latitude 15y ago> you seem to be treating it like a breakthrough of some sort Hahahahaha... seriously, where? What does make it seem that way? This is few hours worth of effort. That damn indicator took the longest to draw. Here, have a look at runner-ups - http://drbl.in/dpbA http://drbl.in/dpbA, http://drbl.in/dpgl http://drbl.in/dpgl
- twelvechairs 15y agoThis is interesting, however the fact that the password indicator gives me a more positive reading for 'qwerty' rather than the correct password minus one letter ('inconsequentia') means to me this is not really 'hinting', just saying yes or no. It is nice to do this on the login page itself (rather than the usual click and 30-seconds to load a 'your username or password is invalid' - where you need to retype both again), however I assume that you probably have unlimited attempts to 'guess' the password, and thus it is probably quite susceptible to abuse.
- sakai 15y agoOn Mac OS X most recent version of Firefox it sometimes shows the shape to the right as entirely darkened and other times not when I type "inconsequential". Any reason for this?
- colonelxc 15y agoNot the author, but from the description, you can only request one check at a time. When you get the results of your current check back, you get a new token. I'm guessing that the server got too busy to serve a request, either the last request, or any previous one, so that you broke the token chain. Another possibility could be a bug with the timing of events, such that it doesn't realize the field has changed. The author seems to be lurking around here, maybe he'll have a better idea.
- latitude 15y agoYep, it's probably the server creaking under the load indeed.
- sk5t 15y agoThe author appears to have given some consideration to security implications (one-use tokens, demanding relatedness, delays, presumably some protection against timing attacks, etc.); my main concerns are: * This approach requires granting access to read the raw password hash to the password-tester application * High resource cost for marginal user utility * These password-check attempts do not count as logon failures, likely defeating intrusion detection measures There are probably more issues but there are top-of-head. FWIW Lotus Notes has always done something similar as you type.
- latitude 15y ago> This approach requires granting access to read the raw password hash to the password-tester application No, it doesn't.
- sk5t 15y agoIt does. What I mean by 'the application' is the backend / web app. To put it another way, a better design allows no application code to read the hash from storage; the application can only ask the storage or security service to compare a supplied value for correctness. Fail enough times in rapid succession and the security service locks the account for a few minutes, preventing any comparisons during that period. Opening the door to testing the hash itself outside of these constraints is the weakness I am suggesting. Also thanks for the downvote.
- latitude 15y agoNo, it does not :) http://news.ycombinator.com/item?id=3689024 http://news.ycombinator.com/item?id=3689024 And I didn't downvote you (not that I even can).
- diocles 15y agoJust for fun, I found a hash collision (hardly surprising on an 8-bit hash): aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Copying/pasting the above password doesn't immediately get you the full square - something to do with the security provisions mentioned later in the article. Deleting a character and re-typing it works, though. Is the complex pattern really necessary for this sort of thing to work? If the password doesn't match, why not just show a big red cross (or other form validation error)? Taking the idea to the next level, why not just auto-submit the form when there's a good likelihood of a match? (Apart from likely breaking user expectations, and the possibility of some unlucky users having a hash collision halfway through their password.)
- latitude 15y ago> If the password doesn't match, why not just show a big red cross.. It wouldn't look as cool :) I was actually considering changing the text color on the password field on a match. Starting with gray and turning it black if there's a match, but it seemed to be too strongly implying that the password was 100% correct. And so I settled on something a bit more ambiguous.
- tjoff 15y agoWith these provisions in place, the password hinting should provide brute-forcing protection comparable to that of regular authentication mechanisms. VERY bold statement and directly false? Since you a) also hints the hash and, indirectly, b) are forced to use a fast hash. If there are 256 classes of hashes it is trivial to detect which class belongs to the user, I don't get the brute-force mitigations that is presented. Since this is done for every character sent you could just precompute 256 different passwords that generate the 256 different classes. And brute-forcing 256 passwords is trivial, especially since the current implementation request a new (reduced) hash for every character.
- latitude 15y agoI don't understand what you don't understand, sorry. Think of it this way - for every new password that you put into the database, run it through some function that spits out N bits. Remember these bits. Then, when you have a password candidate, pass it through the same function and check if the bits are the same. That's all there's to it. The main exploitation risk is that hinting can be used to quickly reject candidate passwords when running a brute-force discovery (so that only remaining positives need to be run through the full authentication process). The provisions listed are to mitigate this risk, i.e. to make hinting unfit for the quick pre-filtering purpose.
- tjoff 15y agoThink of it this way - for every new password that you put into the database, run it through some function that spits out N bits. And since those N bits are based on the password those N bits tell you something about the password. Directly or indirectly you leak information about the password.
- sirclueless 15y agoHis point is that the tradeoff isn't too bad: leak 8 bits, get pretty lights. Now for me, the pretty lights are basically nil because I don't see the improvement over just failing a login attempt, the way every other system in the world works. Also, the average password probably isn't very complicated (my guess is around 30 bits of entropy on average) which means every bit is precious. If you're going to ditch 8 of them, you better be getting some damn good usability improvements, which this thing doesn't give.
- deleted 15y ago[deleted]
- rdl 15y agoCryptographic hashes generally are selected for avalanche; changing one bit in the input should change about half of the output bits. This won't work as described with normal crypto hashes -- there are some hashes which do "nearness", but they have other tradeoffs. I wouldn't do any of this, but if you really want to, it's interesting to think about the tradeoffs. The more sane way to do this is to store some related hashes during original password creation time, or data about the password. The lowest hanging fruit with the least security risk is "is capslock on?" -- Mac OSX indicates this locally in the password dialog box. Next, just knowing the length is probably the most useful thing -- revealing that a 14 character password is 14 characters cuts the search space. This may or may not be acceptable. An attacker exhaustively brute forcing normally starts with "enter" and then moves up to single character, double character, etc. Say it is 4 character numeric only -- knowing it is 10^4 vs. (10^4 + 10^3 + 10^2 + 10^1 + 10^0) only costs you 11%. (obviously in real life you use common password lists, data about the user, etc., but for a 4-digit pin, especially one known to be randomly assigned, this is valid) The next thing would be some kind of "finger alignment check" i.e. warning you immediately if the first character doesn't match -- maybe revealing the first character of the password, stored independently from the rest of it. Assuming it's random, it reduces the effective length of the password by 1 character -- taking an alphanumeric 14 down to an alphanumeric 13, or 62^14 vs. 62^14. Possibly ok.
- peterwwillis 15y agoYour experiment is attempting to produce a complicated method for a server to tell a user that they might not have typoed their password. This is probably not an issue because: 1. There is (to my knowledge) no reason to hide the password field with asterisks unless you have someone looking over your shoulder. If you really want to check for typos, use an 'unhide password field' icon/buttom like Android has. 2. Passwords are dead. I wouldn't even worry about somebody abusing this method because the user's password is probably "password1". Implement a second factor and you don't have to worry as much about a typo for a 20 character password. 3. Password managers never make typos. 4. Humans are fallible, typos happen, make it secure enough to handle typos or we're all doomed.
- mceachen 15y agoThis is certainly pretty, in a das blinkenlights sort of way. I'd guess that most people aren't going to be looking at a little kanji-esque pictogram for guidance. They're going to click the "forgot password?" link after the first fail. Ambient data only works when you have an inkling about what the ambient display is reflecting. More damning, though, is that this is trying to solve a problem by dragging the solution in an incorrect way. If you're typing in your password, you're doing it wrong. Use a password manager. Sell your users on the value, too.
- pbreit 15y agoAn interesting exercise I suppose but solving a completely non-existent problem. The problem is sites departing from the more than adequate password requirement of 6 chars and nothing more. Also, I hate input fields like that where the label disappears immediately (I don't even really like that label positioning in the first place). If you want to improve usability, fix that instead.
- deleted 15y ago[deleted]
- huhtenberg 15y agoYou deleted your comment below, so let me ask the same question here: Why would these hashes need to be in any way related though? Can you explain?
- harshreality 15y agoThere's no benefit to producing a pretty design rather than only a binary indicator.
- deleted 15y ago[deleted]
- latitude 15y agoWhat's amusing is that you are trolling. There is no "password nearness". The entered password is either in the same bucket (identified by an N-bit ID) as the stored password, or it is not. That's it. In former case the hint indicator is black, in latter it's not (though it is animated to a random state).
- deleted 15y ago[deleted]
- latitude 15y agoAuthor's here. Reading the comments I feel like clarifying a couple of things :) --- Clarification 1 --- The goal of "hashing/reduction" step is to sort all possible passwords into M buckets. Then when a hint request comes in, we check if the typed-in password is in the same bucket as the one we have on file. That's it. One way to do this classification is described above. It is not the only way. One can take an MD4 of a string, extract the middle byte and call it a class ID. That would work as well (though it would require computing password "class" upon user registration, when the password is still in a clear). What we want is for related strings such as "password" and "passworf" to be in different classes, and this maps naturally to using cryptographic hashes. --- Clarification 2 --- The indicator pictogram has exactly two states - black and gray. The gray state is animated by randomizing its pattern to provide visual feedback on typing. It does not indicate if the currently typed password is "closer" to or "farther" from the target one. The gray always means just one thing - the password is invalid.
- tantalor 15y agoThank you for clarifying, it makes a lot more sense now. I see how you could use bcrypt for actual authentication and some much faster method for hinting. I think part of the confusion lies in the flow diagram, which maps "stored password hash" to "reduction". In your "class ID" example, what is the difference between the stored password hash and the reduction? What is the purpose of the stored password hash if you always reduce it the same way? Why not just store the reduction? I suppose you might employ a two-phase reduction process (one static and one dynamic), but is this really necessary? What is the advantage?
- taybenlor 15y agoReminds me of ChromaHash, which I think is a fantastic idea. http://mattt.me/2009/11/chroma-hash-revisited http://mattt.me/2009/11/chroma-hash-revisited The neat thing about ChromaHash is that it never compares the user-entered password to the real hash, that is done by the users memory. The unfortunate part is that it doesn't help if you don't use a website frequently.
- Cushman 15y agoThe only realistic utility of this feature is that it could let you "guess" when the user has finished typing their password and check it automatically upon completion without them needing to press return. That would be a neat gimmick, but I don't see it working out. The issues are twofold: 1. The obvious, it reduces an attacker's search space by the guess accuracy, in this case 256 times. To maintain equivalent security you must compensate for this by increasing the work of your hash function 256 times. Depending on your password's entropy (and thus your default work factor) this may or may not be acceptable. For user-supplied passwords secure hashes should take order of 100ms -- 10ms at the least -- and increasing that many orders of magnitude is definitely not acceptable. This, alas, pretty much breaks the idea, but putting it aside: 2. There will be collisions. The odds of a particular collision are 1/256; since an 8-character password contains seven chances for a collision, ballpark one in 36 of your users will have at least one collision during their password. This means that to maintain the seamless experience, you need to check the crypto-hash on the server silently, without indicating checking or failure to the user (anything else would be confusing). This introduces a number of very weird problems which you can definitely not be sure you have accurately addressed. So, not really a good plan for passwords. Still a neat hack, though.
- tantalor 15y agoThe author attempted to solve issue #1 by adding the 1000-msec delay for the first challenge and unrelated-password request throttling. That solves the issue for attackers using the client API (they can't narrow their search space). The author has already acknowledged in the article that, were an attacker to get ahold of the stored password hash, they would have "everything needed to carry out brute-forcing." I agree this is probably a deal breaker and defeats the purpose of using a hash function with a work factor like bcrypt.
- chronomex 15y agoThingiverse has a very similar thing, though they chose three vertical bars that change color.