Salt exposure in authentication stages

Question

I have implemented the multistage authentication illustrated below.

brackets ([ and ]) symbolizes a hash

The client has a key and a secret used for authentication. The server has a database table with rows containing a key, salt and a [secret + salt]

       Client                                    Server
         |                                          |
         ----------------- key -------------------->| 
         |                                          | 
         |                                          |
         |<--------- server-nonce -------------------
         |<------------ salt ------------------------
         |                                          |
         |                                          |
         ------------ key ------------------------->|
         ------------ client-nonce ---------------->|
         --[c-nonce + s-nonce + [secret + salt]] -->|
         |                                          |

The server then checks the hash received against its own information.

My concern is that this enables an attacker to get a hold of salt from the server and then produce a rainbow table to hack that account. What are your thoughts on this?

Answer 1

Why do you need the salt to travel back to the client? Purely to protect the user's secret? the c-nonce and s-nonce are both transmitted anyways so it's only the [secret + salt] combination that is hidden.

My feeling is that if it's a one-time salt it shouldn't matter- you only accept a single response with that salt, if it fails generate a new salt and go through the process again. That way a rainbow table attack would not be possible if the salt was intercepted because it would only be valid with the first request so they would need a very lucky guess.

You can also avoid that kind of attack by using techniques like progressive timeouts or limited log-in numbers that have very little effect on users but will certainly cause a problem for any automated tool trying to run hundreds of log-in attempts. This is probably worth implementing anyway if security is important to you.

Answer 2

You're right. If an attacker knows this is how the system works, there is a chance to capture the data and crack. It is not secure.

I don't understand why you're going down this route when there are many other systems (SSL, public key authentication, etc) that don't have these pitfalls.

Answer 3

If the connection is unsecure, and the attacker manages to get his hand on the salt and the password, he can surly hack the account, even without rainbow tables.

the salt alone\password is useless.

the algorithem should be something more like:

client-----pass------>server
client<----noonce----server
                     server--------getSalt---->back-end-service
                     server<-------salt------- back-end-service
                     server-------[pass+salt]->storage