0

Ok, so here's the deal: (This is a hypothetical scenario)

Say for some reason I had a server (e.g. a legacy one) that can not use encryption in transmitting passwords over the net

I will still want to store my passwords in the database safely, e.g. as a dedicated password hash like bcrypt. That of course means I can't hash them on the client side and compare the two hashes server side.

Now here's the idea: If I stored a bcrypt hash of e.g. a SHA-256 hash of the cleartext password in the database, I could then compute the SHA-256 hash of the cleartext password over the net and still compare that to the bcrypt hash of the SHA-256 hash on the server side.

The big questions are:

  1. Is this safe, or is it opening me up to some sort of attack I'm not thinking off right now?
  2. Would this approach actually gain me anything, or would I just be chasing my own tail?
2
  • ... a server that can not use encryption in transmitting ... Are you suggesting this server cannot use SSL/TLS? If so, anything the client sends to authenticate can be intercepted by the attacker and re-purposed to impersonate you, including the SHA-256 hash of the password. It would be as if the SHA-256 hash of the password is the real password as far as the server knows. Commented Mar 24, 2021 at 20:47
  • So you are saying, SSL or not, as soon as anyone can spy on the conversation, I'm gaining nothing. I'm protecting the actual clear text password, but not my application. I'd have to include some variable element to solve that, which shoots down the whole idea of comparing hashes. Commented Mar 25, 2021 at 6:53

1 Answer 1

0

The problem here is, if you want to compare hashes as I described, you must by definition use a deterministic hashing function, which means there can not be a variable element like there is in a proper password hash like BCrypt. Every time you authenticated, the hash you send would have to be the same.

That means that approach will protect the user's clear text password to a degreee if the communication is observed, and it protects the user in case the password database is lifted, but it does not solve the problem of transit security.

An unencrypted connection means your communication can potentially be observed. Since you would be sending the same hash value over the net with every login, anyone who managed to intercept one communication would still be able to impersonate you, and gain access to the system in question.

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.