Alex Rivera | Logout

Increasing security of web-based login

Asked 2010-08-27T15:24:58.130
13

Right now my login system is the following:

  1. Password must be at least 8 characters long, and contain at least one upper and lowercase letter, a number and a symbol.
  2. Password can't contain the username as its substring.
  3. Username, salted+hashed (using SHA2) password stored on db.
  4. The nonce (salt) is unique for each user and stored as plaintext along with the username and password.
  5. The whole login process can only be made over TLS

How would you rank the effectiveness of the following measures to increase security?

  1. Increase password length
  2. Force the user to change the password every X period of time, and the new password can't be any of the last Y previous passwords
  3. Increase nonce size from 32 bytes to 64 bytes (removed for uselessness)
  4. Encrypt the salt using AES, with the key available only to the application doing authentication
  5. Rehash the password multiple times
  6. Use a salt that's a combination of a longer, application-wide salt + unique user salt on the db.

I am not very fond of 1 and 2 because it can inconvenience the user though.
4 and 6 of course are only effective when an attacker has compromised the db (eg: via SQL injection) but not the filesystem where the application is in.

security password-protection
Edit
Report

2 Answers

6

The answers may depend somewhat on the nature of the website, its users and attackers. For instance, is it the kind of site where crackers might target specific accounts (perhaps "admin" accounts) or is it one where they'd just want to get as many accounts as possible? How technical are the users and how motivated are they to keep their own account secure? Without knowing the answers, I'll assume they're not technical and not motivated.

Measures that might make a difference

5) Rehash the password multiple times. This can slow down all brute force attacks significantly - hash 1000 times and brute force attacks become 1000 times slower.

4) Encrypt the salt using AES, with the key available only to the application doing authentication How would you make it available only to the application? It has to be stored somewhere and, chances are, if the app is compromised the attacker can get it. There might be some attacks directly against the DB where this makes a difference, so I wouldn't call this useless, but it's probably not worthwhile. If you do make the effort, you might as well encrypt the password itself and any other sensitive data in the DB.

6) Use a salt that's a combination of a longer, application-wide salt + unique user salt on the db. If you're only concerned about the password then yes, this would be a better way of achieving the same result as 4) and, of course, it's very easy to implement.

Ineffective measures

3) Increase nonce size from 32 bytes to 64 bytes. Computing rainbow tables is already completely impractical with any salt, so this would only make a difference if the salt was not known to the attacker. However, if they can get the hashed password they could also get the salt.

Ineffective and annoying measures

1) Increase password length Increasing password length beyond 8 won't make a

answered 2010-08-31T04:02:50.897
3
  1. Increasing password length add a few bits of entropy to the password.
  2. Requiring frequent password changes will generally force the users to use less secure passwords. They will need to figure out what the password is in May, June, July. Some@05x, Some@06x, Some@07x.
  3. Can't say for sure, but I would expect the password length to be more significant in your case.
  4. Slightly more secure. But if someone gains access to your data, they can likely gain access to the key.
  5. Other than increasing CPU costs, you won't gain anything.

There are a number of well tried one-way password encryption algorithms which are quite secure. I would use one of them rather than inventing my own. Your original items 1, 2, and 5 are all good. I would drop 3, and 4.

You could allow pass phrases to ease password length issues.

answered 2010-08-27T15:52:14.790

Your Answer