3 ms·

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 encoura

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

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