joined:Sept 30, 2009
I try to use all the best practices for safeguarding passwords on my site such as password hashing (using Blowfish, a moderately high cost parameter, and long, randomly generated salts), SSL/TLS connections, not using security question to reset a password, and incorrect password timeouts.
There are two areas that I am purposely weak on:
1 - Other than NULL passwords, I don't check the password strength when users create them.
2 - I do not require users to periodically change their passwords.
I think some of the websites I have to use have made me hate requiring ridiculously complex passwords that get changed often.
One of the reasons I don't check password strength is due to my hashing technique, and incorrect password timeouts, I don't see why 'password' would be any less safe than 'sv65Jx$r' from things like rainbow tables or dictionary attacks.
As far as periodically requiring password changes, I just view them as more trouble than they are worth. However, I'm thinking of setting up a (monthly/weekly) schedule where logging in users have their just confirmed passwords rehashed with a freshly generated salt and updated in the database. To me it would seem the user gets the benefits of getting to keep the same password but also the benefits of a frequently changed password, such as a new salt if my database is compromised. (Of course, users would always be able to actually change their password whenever they want.)
I guess my biggest weak spot is if a user has a compromised password on their end (someone familiar with them correctly guesses their password, or things like keylogging) and then this unauthorized person is just monitoring what the person is doing on the site. Requiring the user to actually change their password would help reduce this (but not fully stop it due to things like keylogging).
I'd love to read other's thoughts on this. Thanks.