Preventing password reuse

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Preventing password reuse

Jeff Simmons
A client is setting up a password policy, and would like to prevent users from
reusing a password for a period of time (four changes ninety days apart). Is
there a way to do this, either within the OS or via a program in ports? I've
been looking for quite a while and haven't found anything.

--
Jeff Simmons                                   [hidden email]
Simmons Consulting - Network Engineering, Administration, Security
"You guys, I don't hear any noise. Are you sure you're doing it right?"
        --My Life With The Thrill Kill Kult

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Spruell, Darren-Perot
From: [hidden email]
> A client is setting up a password policy, and would like to
> prevent users from
> reusing a password for a period of time (four changes ninety
> days apart). Is
> there a way to do this, either within the OS or via a program
> in ports? I've
> been looking for quite a while and haven't found anything.

I haven't either, although I haven't looked really hard. I mention
http://www.mindrot.org/passwdqc.html not because I know it can do what
you're looking for but because it can offer a few steps up in password
quality which may also be in your policy.

I notice Linux's pam_cracklib
(http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html) approaches this by
storing password hashes in a history file - meaning you have to basically
have the equivalent of your shadow file (with historically valuable
information) hanging around somewhere else.

Seems to me a better solution would be to take a one-way hash of the new
password hash out to some kind of a database where a comparison could be
made against the last N password hash hashes that were used. Putting the
actual password hash out to storage for comparison seems more risky than
just a one-way hash of the hash (at least a little bit). A trigger on a
password change could easily tell if the new password hashes out to one on
record and records a hash of the hash if not.

DS

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Jeff Simmons
On Monday 03 July 2006 16:19, Spruell, Darren-Perot wrote:
> I mention
> http://www.mindrot.org/passwdqc.html not because I know it can do what
> you're looking for but because it can offer a few steps up in password
> quality which may also be in your policy.

Yes, it does everything I need very nicely except preventing password reuse.

> Seems to me a better solution would be to take a one-way hash of the new
> password hash out to some kind of a database ...

Very much agree. I think we're going to need something like this (similar to
some of the file integrity monitors) soon. I'm doing a lot of preparation for
security audits these days (mainly doctor's offices and credit card
processors right now) and that's something the auditing firms want to see.

Thanks for the assistance.

On Monday 03 July 2006 16:19, Spruell, Darren-Perot wrote:

> From: [hidden email]
>
> > A client is setting up a password policy, and would like to
> > prevent users from
> > reusing a password for a period of time (four changes ninety
> > days apart). Is
> > there a way to do this, either within the OS or via a program
> > in ports? I've
> > been looking for quite a while and haven't found anything.
>
> I haven't either, although I haven't looked really hard. I mention
> http://www.mindrot.org/passwdqc.html not because I know it can do what
> you're looking for but because it can offer a few steps up in password
> quality which may also be in your policy.
>
> I notice Linux's pam_cracklib
> (http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html) approaches this
> by storing password hashes in a history file - meaning you have to
> basically have the equivalent of your shadow file (with historically
> valuable information) hanging around somewhere else.
>
> Seems to me a better solution would be to take a one-way hash of the new
> password hash out to some kind of a database where a comparison could be
> made against the last N password hash hashes that were used. Putting the
> actual password hash out to storage for comparison seems more risky than
> just a one-way hash of the hash (at least a little bit). A trigger on a
> password change could easily tell if the new password hashes out to one on
> record and records a hash of the hash if not.
>
> DS

--
Jeff Simmons                                   [hidden email]
Simmons Consulting - Network Engineering, Administration, Security
"You guys, I don't hear any noise. Are you sure you're doing it right?"
        --My Life With The Thrill Kill Kult

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

STeve Andre'
In reply to this post by Jeff Simmons
On Monday 03 July 2006 17:37, Jeff Simmons wrote:
> A client is setting up a password policy, and would like to prevent users
> from reusing a password for a period of time (four changes ninety days
> apart). Is there a way to do this, either within the OS or via a program in
> ports? I've been looking for quite a while and haven't found anything.

I can't resist pointing out that this is an AWFUL policy.  You will be
remembering peoples passwords, a history of them, which are
very likely to be used on other systems.  Thats really bad.  I wonder
(at least in the USA) what would happen to your company if that
data was ever stolen?

--STeve Andre'

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Chet Uber
> On Monday 03 July 2006 17:37, Jeff Simmons wrote:
>> A client is setting up a password policy, and would like to  
>> prevent users
>> from reusing a password for a period of time (four changes ninety  
>> days
>> apart). Is there a way to do this, either within the OS or via a  
>> program in
>> ports? I've been looking for quite a while and haven't found  
>> anything.
>
> I can't resist pointing out that this is an AWFUL policy.  You will be
> remembering peoples passwords, a history of them, which are
> very likely to be used on other systems.  Thats really bad.  I wonder
> (at least in the USA) what would happen to your company if that
> data was ever stolen?

The prevention of password reuse does not involve the storage of any  
passwords. You would properly store the hash. If you used MD5 there  
is an issue about collisions, but SHA1 would not have this problem.  
So the methodology would depend on the login. It is not normal for an  
OS to store the password, although application developers do do this.  
This is the same problem that you have in biometrics. Lots of people  
think you store the fingerprint, when really you only store data  
related to the fingerprint -- i.e. you cannot replay it to create a  
complete print.

CU

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Chris Zakelj
In reply to this post by STeve Andre'
STeve Andre' wrote:

> On Monday 03 July 2006 17:37, Jeff Simmons wrote:
>  
>> A client is setting up a password policy, and would like to prevent users
>> from reusing a password for a period of time (four changes ninety days
>> apart). Is there a way to do this, either within the OS or via a program in
>> ports? I've been looking for quite a while and haven't found anything.
>>    
> I can't resist pointing out that this is an AWFUL policy.  You will be
> remembering peoples passwords, a history of them, which are
> very likely to be used on other systems.  Thats really bad.  I wonder
> (at least in the USA) what would happen to your company if that
> data was ever stolen?
>  

The same thing that happens whenever any other data (like, say, SSNs)
gets stolen.  Absolutely nothing.

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Jeff Simmons
In reply to this post by STeve Andre'
On Monday 03 July 2006 17:51, STeve Andre' wrote:

> On Monday 03 July 2006 17:37, Jeff Simmons wrote:
> > A client is setting up a password policy, and would like to prevent users
> > from reusing a password for a period of time (four changes ninety days
> > apart). Is there a way to do this, either within the OS or via a program
> > in ports? I've been looking for quite a while and haven't found anything.
>
> I can't resist pointing out that this is an AWFUL policy.  You will be
> remembering peoples passwords, a history of them, which are
> very likely to be used on other systems.  Thats really bad.  I wonder
> (at least in the USA) what would happen to your company if that
> data was ever stolen?
>
> --STeve Andre'

As I mentioned in another post, these are requirements imposed by various
security auditing firms. So from the company's (and my) standpoint, we've got
some coverage, since we were required to retain the data.

In general, I agree with most of what I've seen from these firms. I do
question the basic assumptions, since if I have an audit preparation
document, I've already got a pretty good basic blueprint of a certified
firm's security setup and policies. And some of the policies I personally
disagree with. But overall, it's probably a Good Thing (c), it's getting a
lot of firms to improve what up till now have been weak 'security'
arrangements.

An employee of one of these firms claimed that no company that had passed one
of their audits had ever been compromised. This will, of course, change. And
the result will be modifications to the required security policies. After
all, security isn't rocket science, it's chess.

I might also add that all of the auditing firms I've dealt with look with
favor on the deployment of OpenBSD as opposed to some other OSs.

--
Jeff Simmons                                   [hidden email]
Simmons Consulting - Network Engineering, Administration, Security
"You guys, I don't hear any noise. Are you sure you're doing it right?"
        --My Life With The Thrill Kill Kult

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Marcus Watts
In reply to this post by Chris Zakelj
Chris Zakelj <[hidden email]> writes:

> Date: Mon, 03 Jul 2006 21:09:32 -0400
> From: Chris Zakelj <[hidden email]>
> To: "STeve Andre'" <[hidden email]>
> CC: [hidden email]
> Subject: Re: Preventing password reuse
>
> STeve Andre' wrote:
> > On Monday 03 July 2006 17:37, Jeff Simmons wrote:
> >  
> >> A client is setting up a password policy, and would like to prevent users
> >> from reusing a password for a period of time (four changes ninety days
> >> apart). Is there a way to do this, either within the OS or via a program in
> >> ports? I've been looking for quite a while and haven't found anything.
> >>    
> > I can't resist pointing out that this is an AWFUL policy.  You will be
> > remembering peoples passwords, a history of them, which are
> > very likely to be used on other systems.  Thats really bad.  I wonder
> > (at least in the USA) what would happen to your company if that
> > data was ever stolen?
> >  
>
> The same thing that happens whenever any other data (like, say, SSNs)
> gets stolen.  Absolutely nothing.
>
>

Check out any good newspaper morgue before you believe that.  There are
too many counter-examples to your claim.  The person who made this
initial request claims to be working for medical doctors & credit card
processors.  There are specific horrible examples of the possible
consequences of either.  Of course, most of these are consequences to
the person stealing the data, or the person whose data was lost -- but
if too many data professionals start asserting it's not their
responsibility at all, our politicians who art in <whatever> will
certainly create laws that say otherwise.  HIPA for instance.
Or think of the poor guy who lost a laptop at the VA recently.

In any case, you don't need to store passwords.  You can store a
history of one-way hashes instead, get (nearly) the same benefit, and
without nearly the security exposure.

I think the more interesting security argument is that if you make
people change passwords too often, they're much more likely to adopt
other less secure policies in compensation, ones you can't control
nearly so easily.  For instance, they're much more likely to write them
down.  Or they may force you to adopt a less strigent password reset
policy.  Or they may just invent an obvious way to permute their password.

                                -Marcus Watts

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Damien Miller
In reply to this post by Spruell, Darren-Perot
On Mon, 3 Jul 2006, Spruell, Darren-Perot wrote:

> From: [hidden email]
> > A client is setting up a password policy, and would like to
> > prevent users from
> > reusing a password for a period of time (four changes ninety
> > days apart). Is
> > there a way to do this, either within the OS or via a program
> > in ports? I've
> > been looking for quite a while and haven't found anything.
>
> I haven't either, although I haven't looked really hard. I mention
> http://www.mindrot.org/passwdqc.html not because I know it can do what
> you're looking for but because it can offer a few steps up in password
> quality which may also be in your policy.

passwdqc doesn't keep a reuse history, but this is one of the things
that I'd like to implement.

> (http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html) approaches
> this by storing password hashes in a history file - meaning you
> have to basically have the equivalent of your shadow file (with
> historically valuable information) hanging around somewhere else.

This is the reason why I haven't implemented it in passwdqc yet :)
This naive solution isn't very secure...

-d

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

L. V. Lammert
In reply to this post by STeve Andre'
On Mon, 3 Jul 2006, STeve Andre' wrote:

> On Monday 03 July 2006 17:37, Jeff Simmons wrote:
>
> I can't resist pointing out that this is an AWFUL policy.  You will be
> remembering peoples passwords, a history of them, which are
> very likely to be used on other systems.  Thats really bad.  I wonder
> (at least in the USA) what would happen to your company if that
> data was ever stolen?
>
> --STeve Andre'
>
Ahhh, .. that's what hash's are for; easily recreatable given duplicate
input strings, but creating the input string FROM the hash is just about
impossible [lacking near infinate resources].

Storing hashes in a DB is just fine - that's how passwords are encrypted
in any case. Comparing the current to any others in the past 90 days
would work swinningly for a secure audit train.

        Lee

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Chet Uber
>> I can't resist pointing out that this is an AWFUL policy.  You  
>> will be
>> remembering peoples passwords, a history of them, which are
>> very likely to be used on other systems.  Thats really bad.  I wonder
>> (at least in the USA) what would happen to your company if that
>> data was ever stolen?
>>
>> --STeve Andre'
>>
> Ahhh, .. that's what hash's are for; easily recreatable given  
> duplicate
> input strings, but creating the input string FROM the hash is just  
> about
> impossible [lacking near infinate resources].

Not to bicker, but the resources needed to use a database of all  
possible passwords even with alphanumerics and salted is very finite  
-- albeit large. If we are talking about login() that is. Our company  
maintains one for 8 characters and while requiring a large database  
still makes cracking passwords of finding collisions a trivial chore  
for 8 character passwords. We are currently working on one that will  
handle 13 character strings and hope to have it running by the end of  
the year.

Just don't want people to think that they are safe as is not an NP-
complete problem. It is an NP-hard problem however.


CU



Chet Uber
President and Principal Scientist
SecurityPosture, Inc.
3718 N 113th Plaza, Omaha, NE 68164
vox +1 (402) 505-9684 | fax +1 (402) 932-2130 | cell (402) 813-3211
[hidden email]  |  www.securityposture.com
--------------------------------------------------------
'It is vain to do with more what can be done with fewer'
--------------------------------------------------------
-- This communication is confidential to the parties it was intended  
to serve --

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Rod.. Whitworth
In reply to this post by L. V. Lammert
On Mon, 3 Jul 2006 22:25:53 -0500 (CDT), L. V. Lammert wrote:

>On Mon, 3 Jul 2006, STeve Andre' wrote:
>
>> On Monday 03 July 2006 17:37, Jeff Simmons wrote:
>>
>> I can't resist pointing out that this is an AWFUL policy.  You will be
>> remembering peoples passwords, a history of them, which are
>> very likely to be used on other systems.  Thats really bad.  I wonder
>> (at least in the USA) what would happen to your company if that
>> data was ever stolen?
>>
>> --STeve Andre'
>>
>Ahhh, .. that's what hash's are for; easily recreatable given duplicate
>input strings, but creating the input string FROM the hash is just about
>impossible [lacking near infinate resources].
>
>Storing hashes in a DB is just fine - that's how passwords are encrypted
>in any case. Comparing the current to any others in the past 90 days
>would work swinningly for a secure audit train.
>
> Lee
>
>

So, you are suggesting using something other than the hash stored  in
OpenBSD's master.passwd then?

If not try this:
Add a user, nothing special.
Record the hash from master.passwd
Log in as the test user.
Change "your" password.
Change it back.
Compare the hashes.
Different eh?

So you need to change to a less secure password hash method.
Will that affect the security audit?
Test with well known cracker tools and weep. I have (as root) fed a
slice of master.passwd to John the Ripper with a few nologin users
added using dictionary words of 7 or 8 chars as passwords and after 10
days it had not cracked one of them. I bet it takes less time on lesser
hashes to get some results.
From the land "down under": Australia.
Do we look <umop apisdn> from up over?

Do NOT CC me - I am subscribed to the list.
Replies to the sender address will fail except from the list-server.

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Jeff Simmons
In reply to this post by L. V. Lammert
Well, just to play the devil's advocate here ...

One of the main functions of any password hygiene program 'should' be to
prevent users from changing 'mypassword1' to 'mypassword2' and then
'mypassword3', etc.  (Yes, we can force complex passwords, but the idea is
the same.)

It's fairly simple to compare 'newpassword' to 'existingpassword' and prevent
this sort of behavior (I THINK that's what the -s option to passwdqc is for,
but the man page is kind of ambiguous and I haven't had time to dive into the
source yet - pam_passwdqc does it) but then the user can just do
'mypassword1', 'mydogsname1', 'mypassword2', mydogsname2', etc. and totally
invalidate your carefully designed security policy.

And hashes aren't gonna help.

Don't get me wrong, I'm not knocking the idea completely. My assignment here
is that I've been told that in order to get my client certified I have to
avoid reuse of a password over a cycle of 4 90 day forced changes. My JOB is
to assure that doing this doesn't open my client up to a whole new string of
vulnerabilities. Mr. Rock, meet Mr. Hard Place.

"In conclusion the main thing we did wrong ... was to worry about criminals
being clever;  we should rather have worried about our customers ... being
stupid."          Ross Anderson, "Security Engineering"

On Monday 03 July 2006 20:25, L. V. Lammert wrote:

> On Mon, 3 Jul 2006, STeve Andre' wrote:
> > On Monday 03 July 2006 17:37, Jeff Simmons wrote:
> >
> > I can't resist pointing out that this is an AWFUL policy.  You will be
> > remembering peoples passwords, a history of them, which are
> > very likely to be used on other systems.  Thats really bad.  I wonder
> > (at least in the USA) what would happen to your company if that
> > data was ever stolen?
> >
> > --STeve Andre'
>
> Ahhh, .. that's what hash's are for; easily recreatable given duplicate
> input strings, but creating the input string FROM the hash is just about
> impossible [lacking near infinate resources].
>
> Storing hashes in a DB is just fine - that's how passwords are encrypted
> in any case. Comparing the current to any others in the past 90 days
> would work swinningly for a secure audit train.
>
> Lee

--
Jeff Simmons                                   [hidden email]
Simmons Consulting - Network Engineering, Administration, Security
"You guys, I don't hear any noise. Are you sure you're doing it right?"
        --My Life With The Thrill Kill Kult

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Paul de Weerd
In reply to this post by Rod.. Whitworth
On Tue, Jul 04, 2006 at 02:15:09PM +1000, Rod.. Whitworth wrote:
| >Ahhh, .. that's what hash's are for; easily recreatable given duplicate
| >input strings, but creating the input string FROM the hash is just about
| >impossible [lacking near infinate resources].
| >
| >Storing hashes in a DB is just fine - that's how passwords are encrypted
| >in any case. Comparing the current to any others in the past 90 days
| >would work swinningly for a secure audit train.
| >
| > Lee
| >
| >
|
| So, you are suggesting using something other than the hash stored  in
| OpenBSD's master.passwd then?

Why exactly would we need another hash ?

| If not try this:
| Add a user, nothing special.
| Record the hash from master.passwd
| Log in as the test user.
| Change "your" password.
| Change it back.
| Compare the hashes.
| Different eh?

How come these are different ? What happened ? It's still the same
password, right ? How can one string hash to two different outputs ?

It can not. From http://en.wikipedia.org/wiki/Hash_function : "A
fundamental property of all hash functions is that if two hashes
(according to the same function) are different, then the two inputs
are different in some way. This property is a consequence of hash
functions being deterministic."

| So you need to change to a less secure password hash method.

Why ?

How does the system know you've entered the correct password when you
log in ? It applies $magic_function to the text it receives ('the
password') and maybe some other data. Then it compares the output of
this $magic_function to whatever is stored in the password database.
If it matches, hey, you're authenticated and you may log in.

Now we repeat the above procedure using $magic_function on the "new"
password and compare the output with a list of old hashes. What is
different ? Why would this stop working ?

Think about it.

| Will that affect the security audit?
| Test with well known cracker tools and weep. I have (as root) fed a
| slice of master.passwd to John the Ripper with a few nologin users
| added using dictionary words of 7 or 8 chars as passwords and after 10
| days it had not cracked one of them. I bet it takes less time on lesser
| hashes to get some results.

Your password is not hashed as-is. A salt is added (for extra flavour)
before hashing. This salt it also stored in the database along with
the hash. Enter your password, the system takes the hash from the
database, computes the hash of the concatenation of said salt with
the password you entered. Then the system compares the hash with what
it found in the database.

Google 'password salt'

Cheers,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/

[demime 1.01d removed an attachment of type application/pgp-signature]

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Damien Miller
In reply to this post by Chet Uber
On Tue, 4 Jul 2006, Chet Uber wrote:

> Not to bicker, but the resources needed to use a database of all possible
> passwords even with alphanumerics and salted is very finite -- albeit large.

OpenBSD blowfish hashes have 16 bytes of salt, so a database of these
will not be feasible for a while.

-d

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Matthew R. Dempsky
In reply to this post by Chet Uber
On Tue, Jul 04, 2006 at 12:04:11AM -0400, Chet Uber wrote:
> Not to bicker, but the resources needed to use a database of all  
> possible passwords even with alphanumerics and salted is very finite  
> -- albeit large.

OpenBSD's blowfish passwords have 128-bits of salt.  A table of all 8
character (lower-case only) alphanumeric passwords would require 2^128 *
(26+10)^8 ~= 9.6*10^50 entries.  Being ``very finite'' is irrelevant at
this order of magnitude.

> Just don't want people to think that they are safe as is not an NP-
> complete problem. It is an NP-hard problem however.

You are aware NP-complete problems are, by definition, reducible to
NP-hard problems, right?  In other words, NP-hard problems are
``harder'' than NP-complete ones.

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Chet Uber
In reply to this post by Damien Miller
>> Not to bicker, but the resources needed to use a database of all  
>> possible
>> passwords even with alphanumerics and salted is very finite --  
>> albeit large.
>
> OpenBSD blowfish hashes have 16 bytes of salt, so a database of these
> will not be feasible for a while.

I agree that for all but those with the most powerful computing  
environments this is not something they are going to accomplish

My point really was to clarify that infinite and finite should be  
used appropriately, and that intractable and uncomputable also are  
not the same. Sometimes these conversations get long and the words NP-
complete, suffering the halting problem and an infinite search space  
should be used carefully. It makes our communications between  
ourselves that much more effective and accurate.

You are right on that the feasibility of all but the most well funded  
adversaries can accomplish this, but it is not NP-complete,  
uncomputable, or subject to the halting problem. It is just very very  
difficult. I like the world feasible, the only improvement I would  
say is to state feasible for who. For any major corporation it is  
feasible, for drug cartels it is feasible, for foreign governments,  
the NSA, and few others it is feasible, but expensive. For any normal  
person, small company, hacker, cracker, activist, hoodlum, or  
deranged person it is not feasible or likely.

I know that we are not going to attempt this in the next 3-5 years.  
We study hash collisions, but your problem above is above our  
financial capacity or need. We mainly deal with the issues related to  
login() and the use of MD5.

If your adversary is the NSA I would not rest assured that it can't  
already happen.


CU



Chet Uber
President and Principal Scientist
SecurityPosture, Inc.
3718 N 113th Plaza, Omaha, NE 68164
vox +1 (402) 505-9684 | fax +1 (402) 932-2130 | cell (402) 813-3211
[hidden email]  |  www.securityposture.com
--------------------------------------------------------
'It is vain to do with more what can be done with fewer'
--------------------------------------------------------
-- This communication is confidential to the parties it was intended  
to serve --

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Chet Uber
In reply to this post by Matthew R. Dempsky
>> Not to bicker, but the resources needed to use a database of all
>> possible passwords even with alphanumerics and salted is very finite
>> -- albeit large.
>
> OpenBSD's blowfish passwords have 128-bits of salt.  A table of all 8
> character (lower-case only) alphanumeric passwords would require  
> 2^128 *
> (26+10)^8 ~= 9.6*10^50 entries.  Being ``very finite'' is  
> irrelevant at
> this order of magnitude.

The term used earlier was nearly infinite, I used very finite because  
it is bounded -- which infinities are not. There are as you know  
multiple infinite sets that have no common members.

>> Just don't want people to think that they are safe as is not an NP-
>> complete problem. It is an NP-hard problem however.
>
> You are aware NP-complete problems are, by definition, reducible to
> NP-hard problems, right?  In other words, NP-hard problems are
> ``harder'' than NP-complete ones.

I should have properly stated that it is not an NP-complete problem  
but an NP one. NP-complete problems are the most difficult complexity  
problems.

CU

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Matthew R. Dempsky
On Tue, Jul 04, 2006 at 02:29:56AM -0400, Chet Uber wrote:
> NP-complete problems are the most difficult complexity problems.

No, NP-complete problems are the most difficult problems _in NP_.

Reply | Threaded
Open this post in threaded view
|

Re: Preventing password reuse

Steffen Kluge
In reply to this post by Paul de Weerd
On Tue, 2006-07-04 at 07:15 +0200, Paul de Weerd wrote:
> | So, you are suggesting using something other than the hash stored  in
> | OpenBSD's master.passwd then?
>
> Why exactly would we need another hash ?

Because the hashes in master.passwd are salted, as you come to realise
yourself further down in your post.

> | If not try this:
> | Add a user, nothing special.
> | Record the hash from master.passwd
> | Log in as the test user.
> | Change "your" password.
> | Change it back.
> | Compare the hashes.
> | Different eh?
>
> How come these are different ? What happened ? It's still the same
> password, right ? How can one string hash to two different outputs ?

Because the hashes in master.passwd are salted, as you come to realise
yourself further down in your post.

> | So you need to change to a less secure password hash method.
>
> Why ?

Because the hashes in master.passwd are salted, as you come to realise
yourself further down in your post.

> Your password is not hashed as-is. A salt is added (for extra flavour)
> before hashing.

Quite.

Cheers
Steffen.

12