3 ms·

While this is possibly an interesting UI experiment, this paragraph says everything you need to know about real-world use: Utilizing something like bcrypt

by samdk 15y ago

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/ http://codahale.com/how-to-safely-store-a-password/

wonderercat 15y ago
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.
- sk5t 15y ago
  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?
  - latitude 15y ago
    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.
    - incandenza 15y ago
      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.)
      - latitude 15y ago
        > 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.
- deleted 15y ago
  [deleted]
mcao 15y ago
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.
latitude 15y ago
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.
harshreality 15y ago
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.
- moe 15y ago
  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.
- roryokane 15y ago
  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.
tomjen3 15y ago
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.
tantalor 15y ago
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.

by samdk 15y ago

wonderercat 15y ago

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.

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

mcao 15y ago

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.

latitude 15y ago

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.

harshreality 15y ago

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.

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

tomjen3 15y ago

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.

tantalor 15y ago

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.