0

I am not a security expert, just a passionated developer. In The definitive guide to form-based website authentication it's made very explicit that only SSL or strange and complex algorithms are practical for protecting login data from eavesdropping. So in my complete ignorance of computer security I can't see why the following authentication scheme is unsafe:

  1. Upon login button press, through javascript, the client asks the server for a long-enaugh random string
  2. The client hashes both the random message and the password (which has not been transmitted).
  3. The client encrypts (through blowfish or your favorite algo) the random message hash with the password hash.
  4. The client send the resulting blob to the server
  5. The server decrypts the message using the password hash stored in the database (because we keep hashes not password themselves ;)
  6. If the resulting hash matches the original message hash the client is authenticated.

Where is the trap that I'm not seeing? The password is never sent through the net, nor is it's hash. The server only keeps password hash...

Community
  • 1
  • 1
Francesco Boffa
  • 1,402
  • 1
  • 19
  • 35
  • How is this any less "strange and complex" than using TLS, which involves no coding on the client at all? – Pointy Jan 23 '14 at 18:16
  • well, SRP is definitely way more complex :) I'm not saying that I will not use TLS, I just wan't to understand what's wrong with that. – Francesco Boffa Jan 23 '14 at 18:25
  • 1
    Perhaps this question should've been placed at http://security.stackexchange.com/ – user Jan 25 '14 at 20:18

1 Answers1

0

You don't need a password to authenticate through this scheme, only the hash of password. So hash of password is actually a plain password from encryption side of view. So:

  • Salt and hash(pass+salt) may be eavesdropped, pass is one de-hash away
  • Server stores plain passwords

And that's without taking into account that unencrypted connection is always vulnerable to MITM

user
  • 23,260
  • 9
  • 113
  • 101
  • How can the password hash be eavesdropped? It's only used as key to encrypt the random string, which is sent to the server. The password hash never leaves the client pc. – Francesco Boffa Jan 25 '14 at 20:29
  • @AlfaOmega08 consider encrypt(pass,data) as hash(pass,salt) – user Jan 25 '14 at 21:38
  • Oh I see, the "random message" would just be a salt to the hash function. But still, given that the attacker reads the "hash(pass, salt)" or "encrypt(pass, data)" message, he would still need huge computational power to break that to the original pieces, right? – Francesco Boffa Jan 25 '14 at 22:41
  • @AlfaOmega08 For the attacker it would be like as if he got server-stored hash in the traditional scheme. How much of computational power would be needed depends on the hash function and on the strength of a password. – user Jan 26 '14 at 02:28
  • So, in the end, the scheme would be "quite good" if the encryption algorithm for step 3 is very strong, since that would require supercomputers to dechiper. – Francesco Boffa Jan 26 '14 at 08:38
  • @AlfaOmega08 Once eavesdropped, hash will be vulnerable to offline brute-force attack and offline dictionary attack (which will succeed pretty fast if user has weak password, and many users have). Read about [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) and [digest authentication](https://en.wikipedia.org/wiki/Digest_access_authentication), your algo has similar level of security. – user Jan 26 '14 at 12:12
  • Ok I didn't consider the MITM attack. That would be enough to break it. However, would dictionary attacks be effective, even using long, cryptographically secure, random salts? Thanks for your patience :) – Francesco Boffa Jan 26 '14 at 14:30
  • 1
    @AlfaOmega08 Since salt would be sent unencrypted, the only difference is the need to count hash of longer string – user Jan 26 '14 at 14:55