4 ms·

I know very little about security, but is there something wrong with using a hash in the client side and then using bcrypt on the server so that you never recei

by Fargren 15y ago

I know very little about security, but is there something wrong with using a hash in the client side and then using bcrypt on the server so that you never receive the plain text password?

rgarcia 15y ago
I'm no security expert either, but I'm guessing the real solution is SSL. If you hash passwords in javascript, a middleman could easily just look up the source of your application and decrypt the hashed password coming over the wire.
- nokcha 15y ago
  >If you hash passwords in javascript, a middleman could easily just look up the source of your application and decrypt the hashed password coming over the wire. Hashing ≠ Encryption. Unlike encryption, where an encrypted message is intended to be decrypted by a trusted party, a hashed password is never intended to be 'unhashed'. Rather, the hash of the password supplied by the user is compared against the hash value stored in the database. Given a sufficiently strong password P, it should be computationally infeasible for anyone to compute the value of P from hash(P).
  - dpark 15y ago
    Of course, if you're doing the hashing on the client, there's no need to reverse the hash anyway. An attacker can just replay the hash they sniffed. You can do some additional things to avoid this (like using a nonce as part of the hash), but the best solution is still to just use SSL.
- fleitz 15y ago
  An attacker in that position could also capture the password coming over the wire. Both are of equal security in that situation. SSL is also middleman-able.
Someone 15y ago
If the client sends hash(password) to the server, hash(password), for all intents and purposes, _is_ the password. After all, an attacker does not need to recover the password from the hash, all he has to do is capture the hash and replay it.
- eneveu 15y ago
  This. Also, tptacek made a few interesting comments about client-side cryptography: http://news.ycombinator.com/item?id=1755713 http://news.ycombinator.com/item?id=1755713 http://news.ycombinator.com/item?id=1756394 http://news.ycombinator.com/item?id=1756394 http://news.ycombinator.com/item?id=1001007 http://news.ycombinator.com/item?id=1001007 http://news.ycombinator.com/item?id=1411621 http://news.ycombinator.com/item?id=1411621
- shazow 15y ago
  On the upside, it is an improvement for the use-the-same-password-on-many-services users, assuming the hash is not trivial to reverse like md5. At this point, I'm less worried about somebody getting access to some random startup I signed up for than I am about them using the leaked password to gain access to my other accounts. (I've recently changed my password scheme to using a different one for every service, but this just puts me within a minority.)
- zepolen 15y ago
  I'm no crypto expert but wouldn't using a nonce allow this approach to work?
  - pavpanchekha 15y ago
    How would you check the nonce? All your server gets is a black box hash.
    - IgorPartola 15y ago
      Not a security expert here. Doesn't http://en.wikipedia.org/wiki/Digest_access_authentication http://en.wikipedia.org/wiki/Digest_access_authentication do this? Also the server could store the nonce in a session.
barefoot 15y ago
Hashing passwords on the client indicates that the salt is available to the client. In the event of a database compromise it's guaranteed then that the attacker will have the salt and be able to crack your passwords. If the salt is stored on the server, in a login.php script for example, and there is (just) a database compromise then an attacker will be at a disadvantage because they will need to figure out the salt first before cracking any of the passwords. In fact, this is something being ignored here quite a bit. A number of potential attacks only lead to the database - or part of it - being exposed. If you have a large enough salt stored in your unaffected code base then an attacker is going to have a hard time.
- nlco 15y ago
  Salts are suppose to be considered public. For the most part, they are defenses against rainbow tables and to make an attacker have crack each password individually.
  - zagaberoo 15y ago
    Exactly; Having a secret hash is just another example of futile security through obscurity. You want an attacker to be able to know as many parts of the puzzle as possible and still be thwarted.
  - barefoot 15y ago
    Agreed, but an important part of the article was that even public salted md5 passwords are ineffective.

by Fargren 15y ago

I know very little about security, but is there something wrong with using a hash in the client side and then using bcrypt on the server so that you never receive the plain text password?

rgarcia 15y ago

I'm no security expert either, but I'm guessing the real solution is SSL. If you hash passwords in javascript, a middleman could easily just look up the source of your application and decrypt the hashed password coming over the wire.

nokcha 15y ago
>If you hash passwords in javascript, a middleman could easily just look up the source of your application and decrypt the hashed password coming over the wire. Hashing ≠ Encryption. Unlike encryption, where an encrypted message is intended to be decrypted by a trusted party, a hashed password is never intended to be 'unhashed'. Rather, the hash of the password supplied by the user is compared against the hash value stored in the database. Given a sufficiently strong password P, it should be computationally infeasible for anyone to compute the value of P from hash(P).
- dpark 15y ago
  Of course, if you're doing the hashing on the client, there's no need to reverse the hash anyway. An attacker can just replay the hash they sniffed. You can do some additional things to avoid this (like using a nonce as part of the hash), but the best solution is still to just use SSL.
fleitz 15y ago
An attacker in that position could also capture the password coming over the wire. Both are of equal security in that situation. SSL is also middleman-able.

Someone 15y ago

If the client sends hash(password) to the server, hash(password), for all intents and purposes, _is_ the password. After all, an attacker does not need to recover the password from the hash, all he has to do is capture the hash and replay it.

eneveu 15y ago
This. Also, tptacek made a few interesting comments about client-side cryptography: http://news.ycombinator.com/item?id=1755713 http://news.ycombinator.com/item?id=1755713 http://news.ycombinator.com/item?id=1756394 http://news.ycombinator.com/item?id=1756394 http://news.ycombinator.com/item?id=1001007 http://news.ycombinator.com/item?id=1001007 http://news.ycombinator.com/item?id=1411621 http://news.ycombinator.com/item?id=1411621
shazow 15y ago
On the upside, it is an improvement for the use-the-same-password-on-many-services users, assuming the hash is not trivial to reverse like md5. At this point, I'm less worried about somebody getting access to some random startup I signed up for than I am about them using the leaked password to gain access to my other accounts. (I've recently changed my password scheme to using a different one for every service, but this just puts me within a minority.)
zepolen 15y ago
I'm no crypto expert but wouldn't using a nonce allow this approach to work?
- pavpanchekha 15y ago
  How would you check the nonce? All your server gets is a black box hash.
  - IgorPartola 15y ago
    Not a security expert here. Doesn't http://en.wikipedia.org/wiki/Digest_access_authentication http://en.wikipedia.org/wiki/Digest_access_authentication do this? Also the server could store the nonce in a session.

barefoot 15y ago

Hashing passwords on the client indicates that the salt is available to the client. In the event of a database compromise it's guaranteed then that the attacker will have the salt and be able to crack your passwords. If the salt is stored on the server, in a login.php script for example, and there is (just) a database compromise then an attacker will be at a disadvantage because they will need to figure out the salt first before cracking any of the passwords. In fact, this is something being ignored here quite a bit. A number of potential attacks only lead to the database - or part of it - being exposed. If you have a large enough salt stored in your unaffected code base then an attacker is going to have a hard time.

nlco 15y ago
Salts are suppose to be considered public. For the most part, they are defenses against rainbow tables and to make an attacker have crack each password individually.
- zagaberoo 15y ago
  Exactly; Having a secret hash is just another example of futile security through obscurity. You want an attacker to be able to know as many parts of the puzzle as possible and still be thwarted.
- barefoot 15y ago
  Agreed, but an important part of the article was that even public salted md5 passwords are ineffective.