Secure login script confusion

[rayman0487]

Hi all, I'm working on rewriting an application that is currently in place. I was thinking today about the login and I don't think that it's very secure, so I was hoping I could get some other's input. I have the basic form for email and password. upon submit, I'm using a JS library that HASH the password then submits the form which then sends various parameters to my API server. Here's the part I'm hung up on. Suppose the following:

Username: user1

Password: pword (hash value = BZ7...H7F)

 

The call the server would be ...?user=user1&password=BZ7...H7F

 

The server will then query the DB for the stored password for user1, so from the DB I get BZ7...H7F they match, user logs in.

 

What is so different than just sending a plain text password. If some one intercepts the hash value, all they have to do is submit it to the server.

 

So, I was thinking, I'll just add a salt on both sides. $Salt='J7G...F4K'; so now, pword hash value = JU8..G9H and that is sent to server. Now the server queries the DB and gets the stored password, say it's a HASH value = L9K..HFI. The server will add the same Salt parameter and now the server has a hashed value of JU8...G9H - success user logs in. However, again, say someone is able to intercept the JU8...G9H value. I'm right back at square one. I thought about generating random Salt values, but then it would have to be sent with the login credentials rending it mute, because then the middle man would just send the password and the salt value.

 

Is there something I'm missing or are logins really this insecure?

[haku]

You need to consider this in two steps. One is from the browser to the server, and the next is from the server to the database. What you want to do is encrypt your password as it is sent to the server, then decrypt it, and hash it before putting it into the database (or comparing with the value in the database). Encryption is two-way (ie - it can be decrypted) while hashing is one way (it cannot be 'unhashed'). By enrypting it when sending it to the server, it (theoretically) won't matter if someone manages to intercept it somewhere between the browser and the server. By hashing it before inserting it into the database (or comparing it to the value in the database), it ensures that it is stored securely.

 

 

[haku]

As a side note, logins are usually done (or at least should be done) through encrypted (https) protocols, meaning you don't have to worry about this encryption yourself between the browser and the server. The method you are speaking of is a solution in the case that the system doesn't have an SSL certificate, however it does rely on the user having javascript enabled (to handle the encryption), so in the case that users do not have it enabled, not only will their password not be encrypted, it will probably fail on the other end since the server will be expecting an encrypted password, and will attempted to decrypt the non-encrypted password.

[rayman0487]

I don't have access to https for testing, I've been planning on migrating to that protocol anyhow, just haven't had the time. I understand what you are saying, but I'm still loss - unless this is the reason for requiring https. So, if I encrypt the password before sending to the server and someone does intercept what prevents them from being able to simply use that encrypted string? It will still be accepted when they submit it to the server.

[haku]

1) This is the reason for using HTTPS. It handles the encryption between the browser and server so that you don't have to.

2) With the method I described, the encrypted string will not be accepted upon submission.

Edited January 10, 2013 by haku

[haku]

By the way, passing these variables in your URL is insecure. The URL is not encrypted, so that means that anyone can see this data. You should be POSTing the data, not GETing it.