+1 for triple hash password protection. Rave?

Question

Hashing

A rather wild idea arose: to implement the security of password transmission over an unencrypted communication channel during authorization and protect the password from opening, having a database and application algorithms. Do not judge strictly, the method was invented in 5 minutes at 4 am (or in the morning) and claims only the title of "light" protection (for forums and other sites that are not demanding on security).

Registration:
The person generates an md5 password (without passing the password itself, which is not necessary), sends it to the server, where another amount is calculated (md5(hash)) === md5(md5(password)) and added to the hash_of_hash field of the table with users. The operation is insecure, as the hash can be intercepted and used for authorization (the password hash, figuratively speaking, became the password itself), so luck or a secure communication channel is required. This move is needed, as mentioned above, only to make it impossible to obtain the original password after the attacker steals the database (it is known that many people use the same password for both Vkontakte and Internet banking, for example).

Authorization:
1. The client (in this case, the browser) requests a random key (for example, 1234) via an open communication channel.
2. Sends md5(md5(md5(password))+1234) = "qwer" generated by JS code
to the server 3. Server queries the database:
(SQL-like pseudocode)
SELECT user FROM users WHERE md5(hash_of_hash+1234) = "qwer"

And authorizes the corresponding user. A random key is unique for each request for that key. Traffic can still be eavesdropped, but it will be much more difficult to “log in” (at least the user will know if the “man in the middle” intercepted his data).

Completely idiotic? Or the method has the right to life (at least the part with authorization, using double vs. triple hashing).

Answer 1

You are most likely trying to reinvent SRP .

Answer 2

hash+salt and no need to invent anything. Well, do not use md5, weaknesses to collisions were found, sha2 is better.

Answer 3

There is no difference what to use as primary information - a password, its hash, its sum with some known string, or any other unambiguous transformation.
The cryptographic stability of the system does not increase or decrease from this.

Answer 4

So this is, if an attacker steals the hash_of_hash base, as you call it, then he can easily log in as any user in the future, right? For example, Eve knows Alice's hash_of_hash. Eva asks for a key. Gets 1234. Calculates md5(hash_of_hash+1234) sends the whole thing to the server. The one calculates md5(hash_of_hash+1234) and Eve inside. It turns out that in the database you will have data using which an attacker can successfully log in. And that's not good. :)

Answer 5

The hash as password will result in a finite number of combinations. 30^32 is not so small, but a password like "C6+~Z4tx==n can sometimes be even more powerful than the hash received from it.
Then, converting all passwords to md5(pass) you make it so that some different md5 passwords match (due to collisions), which is also not good, and doing md5(md5(md5(x))) only increases collisions, just like sin(sin(sin(x))) will only simplify the sin graph. .

Answer 6

Isn't it more efficient to use sha512?
I use it like this, for example: base64_encode(hash('sha512', $password.$salt));
but I'm usually smarter than everything%)

Answer 7

Well, if you think about it, having a random key and having a hash with this key won't do much. This is only if this key will change. In fact, pulling out the password will not work and using the hash will not work either. But just keep in mind that you will have to do this, the user enters a password, it is hashed, then along with the key. that is,
md5(md5(password)+1234) (syntax similar to js)
The whole thing is sent to the server, where we have a hashed password and key (we store it in the session, for example) and we need to do something like
SELECT id FROM users WHERE md5( phw.'.$key.') = '.$phw.' limit1;
then, in general, everything is safe when intercepted.

Answer 8

You can do it differently. Choose one of the cryptoalgorithms in which encryption can be done with a public key, and decryption with a private key. Pass the public key to the browser, accept the encrypted password, and decrypt it on the server side with the private key.
In this case, the interception of the public key will not give anything to the attacker, because. they can only encrypt, but not decrypt.
Interception of the encrypted password will also do nothing, because only the server has the private key.
Well, and store passwords in the database classically: hash + salt.
PS Isn't it easier to enter https on the authorization page?

Answer 9

The real strength gain is the introduction of multi-factor authentication.

Answer 10

Look at how they did it in Stripe - they use asymmetric encryption and transfer credit card data in the form of a token.
There is already a jQuery plugin jCryption that works like this (quote from the site):

1) Client chooses a Password ... (in the example a weak one, you should use a good random number in production eg mousemovement coordinates)
2) Client requests RSA Public key from Server
3) Client encrypts Password with RSA Public key
4) Server decrypts Password and stores it in the session
5) Server Encrypts the Password with AES and sends it back to the Client
6) Client decrypts it with AES with the Password
7) Both have now the same “secret” key which is used for communication

Answer 11

E I had a similar idea, you are not alone :)
Here is what we managed to find in the notes.
Characters:

Alice - Server.
Bob is a client.
Sam is an intruder.

Operating principle:

1. Bob asks Alice for a key and a keyid.
2. Alice generates a random number key and writes the following values ​​to her database:
"key"=key, "keyid"=keyid, "expires"=(current date plus 2 minutes).
3. Alice sends a key and a keyid to Bob (Sam has a key and a keyid).
4. Bob sends Alice the following data:
"login"=login, "encripted_pass"=md5(key||pass||key), "keyid"=keyid (Sam has login, encripted_pass).
5. Alice retrieves the expires corresponding to the keyid from her database. If expires is less than the current date, Alice sends a "Timed out" error to Bob. Otherwise, the following steps are performed.
6. Alice retrieves the pass corresponding to the login and key corresponding to the keyid from her database. Calculates md5(key||pass||key) and compares with encripted_pass. If the calculations matched, authorization passed.
7. Alice, regardless of whether the authorization is successful, sets the expires string corresponding to the keyid value to "false".
Sam has key, keyid, login, encrypted_pass values.
It cannot reuse the encrypted_pass because "expires"="false" in the field corresponding to the keyid in Alice's database.