Help understanding basic user authentication with salts and hashing

Question

I for some reason am not understanding how to execute a secure authentication between client and server for a user. I've read many resources, and I understand how to use the hashing and salting tools, but not getting the final picture.

The user logs in from a mobile application which sends a request to a server. Here is my understanding:

1. The goal is to send the user's password to the server for authentication, but it is not to be sent cleartext. Generate a unique random salt for every login. Now, send the following two items to the server:

   • hash(salt + password)
   • salt

2. On the server side, ...ok this is where I'm totally confused. What the heck do I do here? How should the password in the database be stored - hash(password)? And the salt is stored separately? How do I verify the password? Who should be generating the salt - the server or the client? It's a messy nightmare!

Update

After reading the answers, it makes more sense now. I will be using SSL, but I just wanted to know how it would work without it. Now the question is, where do session ids tie in to this?

A. Say when a user logs in and is authenticated, the server creates a new random session id and this session id is saved in the table for that user and is sent back to the client and saved there. For every subsequent request the user makes, instead of sending a password over every time, I send the session id and make sure it matches the session id in the user's account. Do I need to do any hashing or encryption on this, or is it just as basic as sending over the cleartext session id and checking if it matches?

B. And this is another very common sense question to you guys, but say I have a POST url that does some things, and requires certain fields such as userId = self.request.get('userId'). This value is assigned by my client when sending the request. The question is, can an attacker generate their own request to that URL and fill in their own values for userId in that request, and have the request go through? I'm not really sure how that works..

Answer 1

In your title you are talking about basic authentication, I assume you are talking about HTTP basic authentication, which is when the browser prompts you for a password, encode and sends over the wire. However, you do not really control the mechanisms and encryptions with that method. It's also generally not used because its less secure and you can't add things like SALTs, one time pins, captchas, etc.

Likely, you want to implement form based authentication using an HTML form which sends the form data with POST. You should secure the submission of this form using SSL/TLS with a certificate for general public usage. This helps to limit the ability for man in the middle (MiTM) attacks where an attacker can eavesdrop and capture the username and passwords. You can do encryption on the client side using JavaScript, but you still need the initial password stored up front. I have seen this implementation on only a few pen tests, but its not very common to do it with JavaScript like that.

Now, in regards to salting and hashing, and everything like that. This is more to do with the storage of the credentials in the database. Typically, you receive the password without encryption through the SSL-secured form submission. You don't want to store the actual password in your database, so you hash it and you salt it using your hash algorithm (e.g., bcrypt). The salt+hash make it so you can store the password without it being directly stored. Hashes are one way so unless you use a technique called rainbow tables, you would have to brute force every possibility until you ran through the algorithm and got the same result. Using a salt make it more difficult to use rainbow tables because the rainbow table must take into account the salt and cannot just be the "standard" rainbow table.

You can have a per user salt or one you use universally, a per-user salt would be more secure. In your user table in your database you would store the following

1. the username
2. the hash(salt+password)
3. the salt for this user

Now, when a user comes to log in again they submit their username and password in the form. You then want to see if they are in the table so you then:

1. Look up the supplied username in your database and return the hash and the salt
2. Take the provided username and rerun the hashing function using the salt obtained in 1 to do somehting like hash(salt+password submit on form)
3. If the hash generated in 2, matches the on retrieved from the database in 1 then you know they provided the correct password

The whole point is to not store the actual password and to make it computational expensive to figure out what this random set of characters maps back to (i.e., difficult to determine the real password).

Some further reading

• An implementation using JavaScript on the front end
• A decent tutorial I probably could have googled first before writing all of the above.

Update OP Asks about not sending through SSL:

You need to accomplish to separate things here: (1) secure data in transit and (2) secure data at rest. What we talked about with hashes accomplishes securing at rest. To secure it in transit, you need to ensure the data going over the network is encrypted somehow. It sounds like you don't want to obtain or cannot obtain a SSL certificate. This is generally the most common way. Otherwise you could implement a much more complex programatic way, where you have your own private and public keys. You more or less encrypt the data before its sent with your private key using a JavaScript implementation of PGP or similar. This is not recommend because you can easily mess it up and it requires JavaScript, which your users may not have enabled. You still use the salting as described above, you just encrypt at the client with your public key and then decrypt on the server end with your private key, then continue as if it was transfered with SSL.

Algorithm (caveat - requires JavaScript or other client side language enbaled)

1. Create a log in form, do not set a submit action in the form - we don't want the information sent through normal means because its confidential and we are not using SSL
2. Create a JavaScript handler which is used to submit the form, as part of the processing, encrypt the password field with your private key, then submit it using HTTP post.
3. Once received on the server, decrypt with public key
4. You have now transfered the actual password over the network with encryption
5. Change you private-public key pair frequently to reduce compromise or reversing.
6. Continue with securing at rest as detailed above.

Update 2 OP continues question to know more about securing session variables:

It's always best to put all submission over SSL to protect eavesdropping. Even if you hash all of your cookie data, if I can intercept and I just need to send you back the hash, well, I already have it if I can be MiTM. You should use multiple factors to limit session hijacking and CSRF attacks. Rather than going into deep detail here, you may want to check out the OWASP Top 10 and read through the various security concerns and how to mitigate. OWASP is one of the top resources for learning how to secure web apps.

The second question you are asking is if your server side app is doing logic basic on a user id being passed can this be faked? Yes, use session management to determine the current user, don't let the client tell you who they are after authentication.

This article, also related to the questions you ask and may be useful for you.

Answer 2

Authentication over plain HTTP (not HTTPS) is rarely appropriate. Indeed, what is authentication ? It is a guarantee that some commands really come from who they claim to. A server granting access is a server which will accept GET and POST commands and respond to them, e.g. by sending confidential documents back. If you worry about a evil eavesdropper, who spies on the sent password, then you should worry about the very same evil eavesdropper, who can spy over the server response, i.e. directly looking at the confidential documents themselves. "'Vast the password, I'll commandeer the data itself", says the pirate.

Therefore, for most practical security models, you need an actual protection system for the data itself. There is a widely used protocol for that, and it is called SSL (HTTPS when used to wrap around HTTP). SSL not only protects the transferred data, it also authenticates the server: through validation of the server certificate, the client is sure that it talks to the right server. In that situation, the client can send the password "as is" through the SSL tunnel: since it is transferred under the Aegis of SSL, the password is not at risk.

If you do not use SSL, then your authentication efforts will come to naught in practical attack scenarios.

You would still want to use hashing and salting, but on the server, not on the client. This is a mitigation measure, to lower the risk that a serious breach becomes catastrophic (see this blog post for a detailed discussion). Since it is only for storage, server-side, the client needs not be aware of how it is done, and the communication protocol is not impacted.

Edit: to clarify: you need to do hashes or whatnots on the client only to protect against bad people doing bad things on the link, e.g. spying on what is sent or modifying that which is sent. By using HTTP and not HTTPS, you are already assuming that this does not happen (or, if you do not assume, you are in for a cruel disillusion at some point). Therefore, there is no need to hash anything on the client.