Hacker News Reader

Comment by samdk | Hacker News Reader

While 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/

View on HN

Jeez, samdk.

It seems like you Ctrl-F'd for bcrypt and didn't read anything else on that page. The part you quoted explains why moving hash checks to the browser is not a practical option. It has nothing to do with storing passwords. Moreover it has nothing to do with actual (complete) password hashes either.

PS I've been dealing extensively with applied cryptography for over 10 years, and I happen to know few things on the subject. Don't assume ignorance by a keyword match.

I don't normally comment on articles unless I've read them in their entirety, and this was no exception. I've re-read that paragraph in context several times, and I don't think it's entirely clear that you only meant it can't be done browser-side. That paragraph reads to me like you're saying bcrypt can't be used at all.

I don't think using bcrypt for this is feasible in any case. From a UI perspective bcrypt hurts you in the first place, because your feedback is going to take at least a few hundred milliseconds, so you lose the instant feedback that makes this potentially.

From the perspective of the person hosting whatever service is using this there are problems too. The first step from your "How It Works" section is this:

    On the server side, it first hashes entered password
    the same way it's done when doing regular authentication.

I'd say this is likely to increase the amount of time you spend hashing by about an order of magnitude. When you're using bcrypt, which takes a lot of computational power, I think that's likely to be significant. Especially because, in this case, you really can't afford to be queuing up requests--if you don't have the computational power to process them immediately, you get even worse at giving instant feedback. And again, that defeats the purpose of having this as a UI feature.

You having 10 years of applied cryptography experience means very little to me. Cryptography is one of those things it's very easy to get wrong even with experience. And getting it wrong has potentially very dangerous consequences.

> The first step from your "How It Works" section is this

Surely you must realize that there's more than one way to sort random strings into 2^N buckets.

If you feel like criticizing, go for the general idea. Nitpicking on the implementation details is (to borrow from a comment below) silly.

I don't understand how that addresses his point.

If you're trying to use maximally secure work factors, bcrypt should take upwards of a second. You'll encourage users to get into the habit of waiting that long before submitting just so they can get the gratification of seeing the design mesh.

If you're using a lower work factor already, it's probably because you need to limit cpu use because your system is popular and is doing lots of authentications. Assuming a minimum password length of 8, you'll be doing an order of magnitude more bcrypt calls for those users who still type in their passwords (and by implementing this, you're encouraging them to keep doing so). How will that work unless you decrease the work factor by a similar amount? If you can afford to be doing more bcrypts, you should be increasing the work factor, not doing stuff like this. Wasn't that his point?

http://news.ycombinator.com/item?id=3689024?

No, I think you're confusing my issues with the ones of the poster to whom that was a reply. My concerns are not so much about security of doing more hashing server side, but rather that you will be burning more cpu to do this cute thing when you could be using that cpu to increase the work factor which users might actually care about. And since modern web auth systems already use ajax to check the password and simply modify the page if the password is wrong, the argument that it's better to see confirmation before submitting rather than submit and wait for confirmation doesn't seem to make sense.

You're waiting for (bcrypt + network latency) in either case. If the standard behavior is unusable (because the auth page reloads if there's an auth error), that's a design problem, to be addressed by not reloading the page on auth errors, not by adding gimmicks IMO.

Furthermore, if you insist on this sort of thing, why not pass back a boolean indicator of whether the full hash matched, and display a checkmark when it's right? You could even automatically log-in the user if it matches. Since you would be doing a full bcrypt each time anyway, in order to do the 8-bit comparison, and you've put limits in place to prevent abuse...

Well, for this part -

it's better to see confirmation before submitting rather than submit and wait for confirmation doesn't seem to make sense.

Personally I feel less comfortable with an outright rejection ('Username/password is wrong' in bold red) than with a subtle hint that something's not quite right with what I typed. Subconsciously. So I think the addition of a real-time validity hint makes it for a smoother and more pleasurable user experience.

Green check if the password is valid, rather than this grid that's meaningless anyway... all it does is leak (hopefully) useless information about the first n (8?) bits of the bcrypt function. There's no correlation between how close the password is to the stored password, and how close the bcrypt hashes are to each other. You really only care about one thing... does it match or not? And if it does, you might as well check if it matches the full hash and not the first 8 bits... since you'd only be sending back a binary indicator to the client's browser.

You still end up lagging because of the time it takes to do the hash check, and if I were typing in a password I would hit enter and not wait for either a neat grid or a checkmark. If the password is wrong when the user has voluntarily submitted the form, that's when you break out the red warning, but it shouldn't take any longer to do that than to display a green checkmark. The difference is one requires the user to press enter first, the other doesn't but requires testing every single intermediate stage the password goes through.

Finally, I'm not thrilled with the idea of a page sending incomplete passwords to a server, which may well be compromised, before I press enter. What if someone types the password for another site by accident, but corrects it before pressing enter? I know some sites already do ajaxy stuff with usernames and passwords, but I don't have to be happy about it.

> you might as well check if it matches the full hash

It is possible to look at the sun in a telescope, but only twice in a lifetime :) What you say is possible, but I don't know how to coalesce the need for near real-time response and the resistance to the brute-force attacks. That's unless you are referring to once a second validation, in which case the brute-force is still an issue.

> if I were typing in a password I would hit enter and not wait for either a neat grid or a checkmark

I don't know about you, but I get a feeling that I mistyped a password now and then and sometimes I am actually right. So my options here are to wipe it clean and retype or to somehow check if the password is more or less OK. This is what hinting is for. Also, as I said on the description page, the second use is to quickly cycle through a list of (disposable) passwords to see which one I used on a site.

> Finally, I'm not thrilled with the idea of a page sending incomplete passwords to a server

I hear you, valid point. And don't get me started on a page sending incomplete search queries to the server.

Assuming a site that originally allows 5 login attempts and locks for 15 minutes after that, under normal conditions that's an average of 180 seconds per attempt.

Assume your site allows N 8-bit partial preimage hash checks before a 15 minute lockout. (I would suggest, with 8 char minimum passwords, that you only count passwords that are 8-16 or 8-24 characters long. Otherwise a cat might try to test a several hundred char long password and the user will be locked out. DoS by feline.)

Under your system, seconds per crack attempt is (900/N + 900/5 * N/256). The first term is the number of pseudo-successful attempts with the fast 8-bit check, and the second term is checking those 1/256 passwords using the slow 5-checks-per-15-minute full auth check.

If you allow 40 8-bit checks before a lockout (N=40), you get 50.625 seconds per check.

Allowing full checks at a faster rate of 40 per 15 minutes, the second term disappears and you get to check at 22.5 seconds/check.

Obviously these decrease security, but if you're concerned about one check per 22.5 seconds, or even 1 check per 10 seconds, why would you want to decrease the effective check rate at all, from the nominal 3 minutes per check that's closer to standard? I don't think that going from 50 seconds to 22 seconds is "looking at the sun in a telescope" :)

The 256 hash buckets are going to create collisions. Given 8 char minimums, 7 incomplete passwords will be checked per user. That's at least one collision for an incomplete password per 37 users (7 * 37 > 256).

At least 1 out of 256 users will have the most common mistype of their password also collide with the real hash to 8 bits. Their only option is to change their password.

An attempt to reduce collisions would further decrease the time per cracking attempt, and since rock bottom is 22.5 seconds/request in that example, I don't think that's so horrible a price for a boost in usability, if you're going to implement this sort of password correctness hinting at all.

Appeal to authority doesn't make for a good argument.

It's not meant to be an argument, it's meant to establish the context. Especially considering how way off the mark the original comment was.

I'm pretty sure the "stored password hash" in the article's flow diagram need not be the same as the one which is used for authentication.

For example, the stored password hash might be `substr(md5_hex($password), 0, 5)`. More than enough information to tell if you're wrong, but not enough information to tell if you're right.

You can still use bcrypt for authentication if you like.

I think in that particular section he is referring to the possibility of allowing to client to validate the hash, which would be bad because it opens up the possibility of brute forcing. I don't think he means you shouldn't use bcrypt on the server side.

Furthermore, if someone is using a password manager like they probably should be for most sites (since average people are not going to remember more than a few passwords, and password reuse is bad), there is no benefit to this system.

Indeed. People should rather review and make sure their registration and login forms work seamlessly with password managers, at least the popular ones (lastpass, 1password, etc).

All too often I run into a form that is either not auto-filled or where some javascript magic fails when it's autofilled (e.g. the page claims "password too short" until I fake some keystrokes manually).

Hint: If your login procedure is annoying then I'll come back less often (or not at all) for that reason alone.

True, but I think most average people do not use password managers. As far as I remember, IE, Firefox, and Chrome all ask to save passwords using a toolbar that slides in at the top or bottom of the page. All average users I have seen when that toolbar appears have ignored it. (I don't know how people react to Safari's modal dialog box, though.)

Probably they consider the toolbar "one of those computer things" and avoid it because they're worried they wouldn't understand it. And if they read it, they might be worried about whether they're really understanding the feature correctly and just ignore it in the end to be safe.

You 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.

Hmm... 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?

There'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.

But 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.)

> But these "classes" have no meaning.

What do you mean? They work for my purpose, which is being able to tell "password" and "passwrod" apart. There will be false positives, of course, but an (educated) assumption is that they are not going to be frequent for lexically related inputs.

Get of your high horse. Yes theoretically you should use bcrypt. Just as you should exercise and eat healthy. In reality very few people do that.

And for those who don't, this is a real possibility. That said I don't think this would be impossible to use with bcrypt and a reasonable load-factor. JS on a virtual machine is pretty fast these days.

Reply on news.ycombinator.com