Password previously used ideas?

[Hugh Oxford]

Hi Folks,

This is more for an intellectual exercise. It's not a difficult problem
but it might be interesting to find out different solutions.

So you have users, and they have passwords, stored in SHA1. You have a
policy which forces users to change their passwords every month or so.
So how to prevent them using two passwords and interchanging them? But
they must be able to reuse a password eventually.

I thought a separate db field to which old passwords are appended with a
separator, such as _. If the total instances of _ exceed 6, whenever a
password is appended, the first one is removed. Then all you do is a
substring search to find out if the new password is in this string, and
reject it if it is.

But is there a neater way?

[=?UTF-8?B?SXbDoW4gU8OhbmNoZXogT3J0ZWdh?=]

Hugh Oxford wrote:

So how to prevent them using two passwords and interchanging them? But
they must be able to reuse a password eventually.

I thought a separate db field to which old passwords are appended with a
separator, such as _.

Bad idea, for several reasons. Use a separate table for that. On a side
note, learn about the normal forms of databases.

Cheers,
--
----------------------------------
Iván Sánchez Ortega -ivan-algarroba-sanchezortega-punto-es-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

[Geoff Muldoon]

Hugh Oxford says...

So you have users, and they have passwords, stored in SHA1. You have a
policy which forces users to change their passwords every month or so.
So how to prevent them using two passwords and interchanging them? But
they must be able to reuse a password eventually.

I thought a separate db field to which old passwords are appended with a
separator, such as _. If the total instances of _ exceed 6, whenever a
password is appended, the first one is removed. Then all you do is a
substring search to find out if the new password is in this string, and
reject it if it is.

Is the underscore character invalid in your passwords? If not you're in
trouble.

Use a separate table for used passwords, with columns of user, password
and date. On an insert check for the number of entries for a user and
delete the oldest dated one when the count reaches your threshold. Would
also be a much more efficient check for reuse matches.

Geoff M

[Hugh Oxford]

Geoff Muldoon wrote:

Hugh Oxford says...

Use a separate table for used passwords, with columns of user, password
and date. On an insert check for the number of entries for a user and
delete the oldest dated one when the count reaches your threshold. Would
also be a much more efficient check for reuse matches.

Geoff M

Of course I _could_ do this but I was looking for a way to avoid it. I
don't need to know what the old passwords were, I just need to know that
they aren't reusing them.

Does sha1 encode using underscores? I don't think so.

[=?UTF-8?B?SXbDoW4gU8OhbmNoZXogT3J0ZWdh?=]

Hugh Oxford wrote:

>Use a separate table for used passwords, [...]

Of course I _could_ do this but I was looking for a way to avoid it.

Why?

I don't need to know what the old passwords were, I just need to know
that they aren't reusing them.

Of course you need to know what the old passwords were! How could you tell
if a password was used recently if you didn't keep that information?!

OTOH, if you don't want to keep the *cleartext* passwords in your DB for
security and/or privacy concerns, just hash the used passwords.

--
----------------------------------
Iván Sánchez Ortega -ivan-algarroba-sanchezortega-punto-es-

Your supervisor is thinking about you.

[Rob]

On Oct 28, 11:47*pm, Iván Sánchez Ortega <ivansanchez-...@rroba-
escomposlinux.-.punto.-.orgwrote:

Hugh Oxford wrote:

Use a separate table for used passwords, [...]

Of course I _could_ do this but I was looking for a way to avoid it.

Why?

I don't need to know what the old passwords were, I just need to know
that they aren't reusing them.

Of course you need to know what the old passwords were! How could you tell
if a password was used recently if you didn't keep that information?!

OTOH, if you don't want to keep the *cleartext* passwords in your DB for
security and/or privacy concerns, just hash the used passwords.

--
----------------------------------
Iván Sánchez Ortega -ivan-algarroba-sanchezortega-punto-es-

Your supervisor is thinking about you.

Agree with Ivan, separate table with username, hashed password and
date.

Would make one change though. Rather than deleting the older entries,
I'd simply do a SELECT * FROM 'oldpasswords' WHERE user = x AND
password = y and created_date z.

You can then write a weekly/monthly script the clears out the old
passwords periodically.

Rob.

[C. (http://symcbean.blogspot.com/)]

On 28 Oct, 20:23, Hugh Oxford <[e-mail]:

Hi Folks,

This is more for an intellectual exercise. It's not a difficult problem
but it might be interesting to find out different solutions.

So you have users, and they have passwords, stored in SHA1. You have a
policy which forces users to change their passwords every month or so.
So how to prevent them using two passwords and interchanging them? But
they must be able to reuse a password eventually.

I thought a separate db field to which old passwords are appended with a
separator, such as _. If the total instances of _ exceed 6, whenever a
password is appended, the first one is removed. Then all you do is a
substring search to find out if the new password is in this string, and
reject it if it is.

But is there a neater way?

This has always been one of my pet bug-bears. How does changing
passwords improve security? It makes them harder to remember which
makes users more likely to write them down - or choose something which
is more like a dictionary word. If a password is compromised then
later changed - sure the black hat an no longer get access with the
same credentials - but it doesn't miraculously undo any damage they
have done.

If security is a concern then do 2-factor authentication properly.

C.

[mijn naam]

"Hugh Oxford" <ar*****@fas.comschreef in bericht
news:49**********************@news.zen.co.uk...

Hi Folks,

This is more for an intellectual exercise. It's not a difficult problem
but it might be interesting to find out different solutions.

So you have users, and they have passwords, stored in SHA1. You have a
policy which forces users to change their passwords every month or so.

Great idea. Keep track on how many users happen to choose "Januari"
"Februari" and so on.

You require at least one numeric char? November08, December08, Januari09
....
You require at least one non-alphanumeric? November_08, December_08, ...

So how to prevent them using two passwords and interchanging them?

You educate your users, and you stay away from technical non-solutions which
only increase the chance for bugs.

[Bill H]

On Nov 7, 10:12*pm, "mijn naam" <[e-mail]:

"Hugh Oxford" <[e-mail] in berichtnews:49**********************@news.zen.co.u k...

Hi Folks,

This is more for an intellectual exercise. It's not a difficult problem
but it might be interesting to find out different solutions.

So you have users, and they have passwords, stored in SHA1. You have a
policy which forces users to change their passwords every month or so.

Great idea. Keep track on how many users happen to choose "Januari"
"Februari" and so on.

You require at least one numeric char? *November08, December08, Januari09
...
You require at least one non-alphanumeric? *November_08, December_08, ....

So how to prevent them using two passwords and interchanging them?

You educate your users, and you stay away from technical non-solutions which
only increase the chance for bugs.

I never thought of using the months and years for my password. Great
idea!

Bill H

PS joking... I think :)

[mijn naam]

Great idea. Keep track on how many users happen to choose "Januari"

"Februari" and so on.

You require at least one numeric char? November08, December08, Januari09
...
You require at least one non-alphanumeric? November_08, December_08, ...

So how to prevent them using two passwords and interchanging them?

You educate your users, and you stay away from technical non-solutions
which
only increase the chance for bugs.

I never thought of using the months and years for my password. Great
idea!

Bill H

PS joking... I think :)
--------

I've seen something similar actually happen. They needed a new password
every three months. Can you think of four different periods throughout a
year?