Login system, security

Question

I need to make a log-in system and having basically no previous knowledge of how it's done (with security in mind) I studied it on the internet. The way I would do it now is something like this:

• Server has login information in a database table - username and a password hash per user (encrypted with SHA224 for example).
• When client wants to authenticate, password is encrypted with SHA224 (client-side) and sent with username to the server to verify a match in the database.
• If the user ticked "Remember me" option, an authentication key is generated on the server, inserted into a database along with the IP of the client.
• The authentication key is sent to the client and stored in cookies.
• Now, when the client returns, authentication key from cookies is sent to the server, the server finds it in the database and checks if the IPs match as well. If it does, the user is authenticated and a new authentication key is generated and sent to the user (and stored in cookies) for next visit.

My questions are:

1. How does encrypting password make this any safer? The hash still can be captured on the way from client to server and misused just as well as if it was plaintext. I know that this is an elementary question but I somehow couldn't find an answer to this one.
2. Is this security system secure enough? (or better yet - Did I get it right?)

Answer 1

Some points I want to add:

• the hashing of the password is not done on the client. You cannot do it reliably. The necessary technique for computing the hash (JavaScript in your case) might not be available and you cannot trust the result. If somebody can retrieve the hashes of the passwords in your database he could just login without knowing the actual passwords.

• make sure to use SSL or another secure transport for transmitting the given passwords from the client to the server. SSL is a good idea for everything after all.

• you should not use a single hash algorithm for storing the passwords in the database. Have a look at HMAC. That is far better. Additionally read about salts in cryptography.

Answer 2

Why does hashing a password make the system more secure

Hashing is not equal to encryption. Encrypted data can be decrypted back into plain text. Hashed data cannot be decrypted.
By hashing your user's passwords, nobody can see what passwords are used. So if your data gets stolen, the hashes cannot be decrypted by the hacker. The same goes for the system administrator, he/she cannot 'lookup' a password. This can be an all to common scenario in shared hosting environments.

Storing passwords

The easiest way to get your password storage scheme secure is by using a standard library.

Because security tends to be a lot more complicated and with more invisible screw up possibilities than most programmers could tackle alone, using a standard library is almost always easiest and most secure (if not the only) available option.

The good thing is that you do not need to worry about the details, those details have been programmed by people with experience and reviewed by many folks on the internet.

For more information on password storage schemes, read Jeff`s blog post: You're Probably Storing Passwords Incorrectly

Whatever you do if you go for the 'I'll do it myself, thank you' approach, do not use MD5 anymore. It is a nice hashing algorithm, but broken for security purposes.

Currently, using crypt, with CRYPT_BLOWFISH is the best practice.

^{From my answer to: Help me make my password storage safe}

As for the infamous remember me option.

Create a random token and give it to the user in the form of a cookie. If the user presents a cookie with this token, you give them access. Key is to only accept each token once. So after it is used, replace it with a new random token.

This token is, in essence, just another password. So in order to keep it safe, you do not store the token, but a hash of it. (just as you did with the password)

Your suggestion of binding the cookie to an IP-address will unfortunately not work. Many people have dynamic IP-addresses, some even change from request to request during a single session. (this is for example caused by load-balancing proxies).

Sending passwords to the server

The only method currently usable for sending a password from a web browser to server is by using a SSL-secured connection. Anything else will not be safe, as you cannot guarantee the integrity of the solution on the client side.

Answer 3

• Never ever invent your own crypto mechanisms. Use someone else's. Crypto is beyond tricky, and unless you're Bruce Schneier, you have an extremely slim chance of improving it, while having a huge chance of screwing it royaly.
• Do not encrypt passwords, hash them.
• If you're using hashes, salt them.
• If you don't have to use straight hashes, use HMAC, they're much more resistant to precalculated attacks.
• If you're sending stuff across an unsecure link, add a NONCE to the transmission to prevent replay attacks. This goes for both client->server and server->client.
• If you're using salts and nonces, make sure they have high entropy. 'secret' is not a good one. Make it random, make it long, make it use large character sets. The extra computation cost is minimal, but the security you gain from it is enormous. If you're not sure how, use a random password generator, and then use ent to measure entropy.
• Do NOT use a timestamp as a nonce, unless you have a very specific need and really know what you're doing.
• Use session protection. SSL isn't perfect but it's helluva better than nothing.
• If you're using SSL, make sure to disable weak protocols. SSL session starts with 'offerings' of lists of ciphers both sides can do. If you let clients use a weak one, an attacker will definitely use that.