4 ms·

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 brows

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.

samdk 15y ago
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.
- latitude 15y ago
  > 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.
  - deleted 15y ago
    [deleted]
harshreality 15y ago
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?
- latitude 15y ago
  http://news.ycombinator.com/item?id=3689024 http://news.ycombinator.com/item?id=3689024?
  - harshreality 15y ago
    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...
biot 15y ago
Appeal to authority doesn't make for a good argument.
- latitude 15y ago
  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.

samdk 15y ago

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.

latitude 15y ago
> 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.
- deleted 15y ago
  [deleted]

harshreality 15y ago

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?

latitude 15y ago
http://news.ycombinator.com/item?id=3689024 http://news.ycombinator.com/item?id=3689024?
- harshreality 15y ago
  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...

biot 15y ago

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

latitude 15y ago
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.