Safeguarding User Passwords

[ocon]

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.

[phranque]

that's a really good topic for discussion, ocon!

i'm always reluctant to provide legitimate answers to security questions because it is obvious to me how well you could be profiled if someone aggregated a few sets of your security answers.

as far as the password changes, i would think that on some sites this would be a deterrent to retention.

[edited by: phranque at 5:03 am (utc) on Jan 1, 2014]

[lucy24]

Personal opinion: Do everything in your power to prevent passwords-- including reminders and security questions-- from being intercepted in transit. But the buck has to stop somewhere. If the user chooses to set "OPEN" * as their password, it's their own decision and their own responsibility.


* I actually did this years ago for a screensaver on my home computer. But only so I wouldn't be kicked out of its space-shootup game if I accidentally bumped into the mouse just as I'd passed my previous high score. No security involved.

[ocon]

I like the idea of making my end secure as I can make it, but shift responsibility for password strength and change frequency to the end users on how secure they feel it needs to be. In all honesty, right now, the worst user information that can be stolen from site are user display settings, but I still need to store login information so I need to do my due diligence on safeguarding that.

I never felt comfortable with sites that setup templates for passwords: 8-16 characters, at least 2 uppercase, 2 lowercase, 2 characters from this list (!,@,#,$,%,^). Besides worrying that my password is stored as plain text because they mandate a maximum length for a password, I think templates like these help adversaries generate viable options.

However, I really like the idea of periodically rehashing user passwords automatically with a new salt when logging in, right after their login password has been confirmed. It wouldn't require user interaction, which I agree would deter retention, and provide constantly changing hashes if the database was compromised.