4

I have a app which transmit the password in clear text. I was planning to use the hash of the password (SHA-512) as the key for encrypting the plain text password. Then send the encrypted text to the server. the password length is minimum 12 chars (including special characters) and max 20 chars.

Is this is bad mechanism ?

user851157
  • 43
  • 3

5 Answers5

6

Is this is bad mechanism ?

Yes. Use SSL/TLS and do not attempt to roll your own cryptograhy scheme.

Community
  • 1
  • what if I use http://en.wikipedia.org/wiki/PBKDF2 and use the hash if the password as the salt ? – user851157 Nov 23 '13 at 05:06
  • @user851157 Unless the connection *itself* is encrypted, it's still a bad idea. Without that encrypted (and, as another function of SSL, authenticated) connection, anyone could just MitM the user and pass the authenticator on to your system as if it were their own. They don't need the cleartext of the password. They just need the cleartext of the packets being passed between the user and your system. Seriously, don't roll your own crypto. Ever. And don't pass authenticators in the clear. Ever. – Iszi Nov 23 '13 at 05:40
6

If your concern is transmitting the password, then yes, absolutely, this is a bad mechanism. Your application is still vulnerable to a form of pass-the-hash attack. Although the password itself won't be available to the attacker, the encrypted password can be intercepted and used, itself, for authentication.

Always go for the standard:

Community
  • 1
Adi
  • 43,808
  • 16
  • 135
  • 167
5

Yes, this is bad. If all the server needs in order to authenticate you is this (never changing) hash, then the has is your password now. This is no better than sending the password in the clear, because all the attacker needs in order to impersonate you is that hash.

Instead, if you want to hash passwords for transmission, the way you do it is through a challenge-reponse system. This way, the same hash is never sent twice. But this is not a good idea, because...

It's more important that the password not be stored on your server. TLS/SSL is sufficient to prevent any sort of man-in-the-middle attack. That part is solved, Just use TLS and don't worry about it. But you do have to worry about your server getting hacked and your password database getting leaked. Publishing other people's password databases is all the rage these days, and you don't want to be one of those caught not hashing their database. There's just no excuse.

So, transmit your passwords plain-text inside an encrypted connection, but store them hashed on the server. If you do anything else, anything else at all, then you're doing it wrong.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • From my understanding, the server can still store hashed passwords, they just can't be salted unless the salt is also sent to the client along with the challenge. – Numeron Mar 29 '15 at 11:21
1

I was planning to use the hash of the password (SHA-512) as the key for encrypting the plain text password. Then send the encrypted text to the server.

I don't care if you're using SHA with 8192 bit key, you're trying to authenticate with something traveling in the clear that someone can just MITM so your answer is no. Anyone who's worked with crypto (as the other good answers here) will tell you not to try rolling your own crypto, unless you really know what you're doing, and even then there are plenty of good API's for that.

stackuser
  • 421
  • 1
  • 3
  • 7
1

With a minor tweak this can be made reasonably secure.

The problem with your original approach is that the hash would be the same every time, so it is vulnerable to a replay attack.

If you adjust the protocol to include a variable challenge this can work:

  1. Server sends a random challenge
  2. Client computes hash = hmac(hash(password), challenge)
  3. Client sends cipher = encrypt(hash, password)
  4. Server computes hash = hmac(hash(password), challenge)
  5. Server computes password = decrypt(hash, cipher)
  6. Server checks hash(password) = stored hash

This arrangement is secure against replay attacks and it also avoids the server storing a password equivalent. It's main vulnerability is that a captured login can be used for an offline brute force attack. Also, if you are implementing this in JavaScript, then the JavaScript code could be intercepted and tampered with.

Now, while this is interesting, I should echo the advice from other answers: do not roll your own crypto

paj28
  • 32,736
  • 8
  • 92
  • 130