Increasing security of web-based login

Question

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.

Answer 1

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 practical difference to the brute force time.

2) Force the user to change the password I agree, this will always be worked around. In fact, it may make the site less secure, because people will write down the password somewhere!