0

I have an idea for an algorithm. I don't know if I made any mistakes and need some extra thoughts/peer review on it.

This would work as an (almost)zero knowledge proof for sending passwords that can be easily implemented.

registration:

A user sends his password to the server (one time risk).

The server computes a "secure" hash of said password. This hash has to be very long, lets say 4k characters.

login:

When a user wants to log in, he first computes said hash on his local machine. The server then tells the client to join random letters to a new one time password. The server only sends out letter positions and sends them out at random, so that there are enough permutations to never run out of combinations. There has to be a history of already used letters, so that at least one never exposed letter gets used. Else a MITM could simulate a client.

After joining all letters to a new password, said password gets "securely" hashed and send to the server for verification. the server performs the same tasks the client is doing and checks his version against the clients data.

Even if send one-time passwords are "securely" hashed, the attacker has time. So after about half of the hashed original password is revealed, a counter is increased, and said password is hashed one time on the server side and old hashed password discarded. This counter gets send to the client every time he want's to login, so he increases hashing rounds by the counter to match server data.

This is an idea that came into my head some seconds ago. It seems to be a good approach. But I would like to see your thoughts on this one, where is the flaw? Or is something similar used already?

reggaemuffin
  • 251
  • 2
  • 9
  • So if the initial login step is valid all the rest does what? – zedman9991 Sep 12 '14 at 19:41
  • @zedman I edited my question, my algorithm cares about the login process through an already exchanged secret. The secret is hashed on the server and never send a second time. The initial step is the exchange of said secret. – reggaemuffin Sep 12 '14 at 19:44
  • Are you aware of [Secure Remote Password](http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)? – paj28 Sep 15 '14 at 14:46

1 Answers1

2

This is how I understand it, please correct me if I've misinterpreted something.

Sending Password in the Clear

A one time risk is never worth it when it can be avoided. Using a secure algorithm like bcrypt or PBKDF2 with a salt does not require the password to be sent in the clear. Even if the password is sent under TLS, am I to trust that you're not keeping my password for yourself?

This answer provides a completely secure mechanism for login authentication without sending a password in the clear.

Overhead

There is a lot of overhead that an attacker can see over the wire.

When a user wants to log in, he first computes said hash on his local machine. The server then tells the client to join random letters to a new one time password. The server only sends out letter positions and sends them out at random, so that there are enough permutations to never run out of combinations. There has to be a history of already used letters, so that at least one never exposed letter gets used. Else a MITM could simulate a client.

What exactly is happening here? Are you joining random letters to the hash of the password? You're sending the letters in the clear, so why exactly can't someone be in the middle? I understand that you've exchanged a secret only once, but that secret is stored on both the client and server. Two separate attack vectors. If you're concatenating the letters to the end of the hash, then all I need is the hash and I can login with the server.

If you're creating a whole new password from the letters sent by the server then at what point do you verify that the original password was correct? Otherwise I can connect to the server myself, and the server happily supplies me with a new password.

Even if send one-time passwords are "securely" hashed, the attacker has time.

I'm not really sure what you're referring to.

This counter gets send to the client every time he want's to login, so he increases hashing rounds by the counter to match server data.

Again you're providing some other characteristic over the wire, if an attacker can see it then it's reproducible. I don't think this adds anything to security, as any secure hashing algorithm will run through enough iterations on its own.

Unnecessarily Long Password Requirement

There's no reason for a 4000 character password. For a secure algorithm this will put a performance hit on your server. I securing hashing algorithm iterates 20,000 times over the entire password. A 16 character string is the minimum needed for a secure password. 4000 characters is overkill.

Done Before (kind of)

It seems like the random characters provided by the server are acting as a random salt. However, since they're restricted to letters they're not going to be nearly as effective.

Check out Salted Password Hashing - Doing it Right

Community
  • 1
RoraΖ
  • 12,317
  • 4
  • 51
  • 83