Remembering X passwords back

[cydewaze]

My office has declared that all web apps need to remember the last 24 passwords used, so I was trying to think of the best way to do this. So far, this is what I'm thinking. Passwords also have to expire every 30 days.

1) Add a column to the database that contains a comma-delimited list of the last 24 passwords in the order used.

2) Add a column that contains the date for when the current password was created.

3) When the current password expires (or actually when the new one is created), delete the first item from the list and add the current one to the end of it.

4) Use listContains() to see if the new password the user is trying to use already exists in the list of old passwords.

Thoughts or advice?

[cfStarlight]

the last 24 passwords used

Though I'm a big fan of good security, that number is a little insane

I'd have to give it some thought, but I'd definitely veto the "a comma-delimited list" approach. It's just not good db design and can introduce subtle problems you don't want .. especially with something as important as passwords.

[cfStarlight]

Maybe someone else has a better idea, but my thought was store a table of previous passwords with a "DateAdded" column. Each time the password is changed, add it to that table with the date it was added.

To confirm a password was not used in the last 24 cycles, check the table for a matching password where the DateAdded >= 30 days x 24. If a match is found, then the password was already used. You could periodically delete records older than 30 days x 24 cycles

[cydewaze]

Though I'm a big fan of good security, that number is a little insane

Our entire web security checklist is insane. Completely insane. Which is why I'm slowly pulling all my CF apps off our server and having them contracted outside the office, where the outside contractor will have to conform to the insane standards.

We have to remember 24 passwords back (even for an app I have that's only online for a 90-day period), we have to forbid duplicate sessions (i.e. two browsers opened to the same app by the same person at the same time), we have to have some sort of feature where an admin can kill a logged-in session for a given user, the list goes on and on. And the list changes about once every two months.

The people who came up with the standards are network people, and don't know a thing about web apps. and that's part of the problem.

[cfStarlight]

The people who came up with the standards are network people, and don't know a thing about web apps. and that's part of the problem.

Sounds like they should be forced to design the web apps for a few months.

I've had to deal with the multi-session issue before, and had to work with configurable options for password strength and reset restrictions. But nothing as insane as 24 cycles. Maybe you should have users contact the network group when they get locked out after 1 wrong password attempt ... because they can't remember all of their 15 passwords (which must be different in each application, as well as different than any password used the last 5 years ) ;-)

[downtroden]

i vote for the second table with last password, expired_date and user_id.

Seems like that's better than the comma delimited list in the long run.

[esearing]

Use a second table of passwords by created date. User may update often because he forgets his password before expire date.

Then query last 24 records for that user and comparing new password to those values.

Food for thought - Do you generate temporary passwords for reset requests? if so, do those need to be stored too?

[cydewaze]

Food for thought - Do you generate temporary passwords for reset requests? if so, do those need to be stored too?

Yes and no.

I generate a random password that gets emailed to the user in the case of a forgotten password, but they don't need to be remembered because they user gets forced to reset it the first time he logs in with it.