Re: Preventing password reuse
On Wed, Jul 05, 2006 at 12:24:34PM +0200, Joachim Schipper wrote: > Consider five lower-case words chosen from 1024 possibilities each, for > instance - this has 50 bits of entropy, roughly equivalent to a > 10-character password based on natural language [1]; a little fuzzing > and use of capitals will make the passwords chosen much more powerful, > but a 10-character password based on natural language really isn't that > shabby for a lower bound on password complexity. Diceware[1] is a list of 6^5 short, easy-to-remember words along with instructions on how to generate passwords with a few dice rolls. Five words from their list gives you a little over 64 bits of entropy. [1] http://world.std.com/~reinhold/diceware.html
Re: Preventing password reuse
On Tue, Jul 04, 2006 at 10:07:53PM -0400, STeve Andre' wrote: > On Tuesday 04 July 2006 08:45, Joachim Schipper wrote: > > On Mon, Jul 03, 2006 at 09:22:59PM -0700, Jeff Simmons wrote: > > > 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.) > > > "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" > > > > This suggests a rather fascist, and thus very effective approach: deny > > the users the right to create their own passwords, but institute some > > scheme that produces strong, but hopefully memorizable passwords. > [snip] > > Oh Gods. If you do that with normal people, they will put those > passwords on PostIts and leave them in "safe" places like monitors. > > MOST people have real real REAL problems remembering all but some > very few passwords. People hate passwords, and even in "secure" > institutions (like military environs) they circumvent them. Forcing a > password on people results in a secure password, but in unsecure > storage methods. > > We computer folks are weird in that we remember many of them. We computer folks are weird in that we can be made to understand that spending five minutes memorizing a password actually makes sense. Also, I do not necessarily advocate dd if=/dev/urandom bs=16 count=1 | b64encode - though that is a good method and produces proper passwords - but have you looked at something like the S/KEY scheme for producing text passwords? A slightly modified version could both create sentences that make some sense (for fairly low values of some), and if you add a little fuzzing somewhere the passwords are fairly strong. Consider five lower-case words chosen from 1024 possibilities each, for instance - this has 50 bits of entropy, roughly equivalent to a 10-character password based on natural language [1]; a little fuzzing and use of capitals will make the passwords chosen much more powerful, but a 10-character password based on natural language really isn't that shabby for a lower bound on password complexity. (Plus, with a secret algorithm/wordlist the above is significantly harder to crack; while assuming secrecy of your algorithm is a no-no in crypto, it's still a nice side benefit, and not completely unjustified if the wordlists are rotated regularly...) Of course, the above will create more complex passwords than people would choose themselves and make it impossible to use mydog1, mydog2, and so on; and yes, some people will be annoyed. However, since the goal was to improve password security (or, rather, getting the auditors to sign off for good password security), *some* increase in the complexity of passwords is inevitable - and communicating this well might lead to more understanding. The main disadvantage would be that it creates noticeably longer passwords; this is the price paid for an easily-remembered but still strong password. This can be offset by sprinkling more randomness (for instance, arbitrarily capitalize each letter with 50% chance - this adds 1 bit of entropy per character), but that makes the password less rememberable. (Note also that long, but memorizable, passwords will induce bitching but are less likely to make people use Post-its.) Joachim [1] Giving a generous 5 bits of entropy for each character; simple natural language has 2 - 4 bits by most counts, but passwords tend to be a little more random.
Re: Preventing password reuse
On Tuesday 04 July 2006 08:45, Joachim Schipper wrote: > On Mon, Jul 03, 2006 at 09:22:59PM -0700, Jeff Simmons wrote: > > 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" > > This suggests a rather fascist, and thus very effective approach: deny > the users the right to create their own passwords, but institute some > scheme that produces strong, but hopefully memorizable passwords. [snip] Oh Gods. If you do that with normal people, they will put those passwords on PostIts and leave them in "safe" places like monitors. MOST people have real real REAL problems remembering all but some very few passwords. People hate passwords, and even in "secure" institutions (like military environs) they circumvent them. Forcing a password on people results in a secure password, but in unsecure storage methods. We computer folks are weird in that we remember many of them. --STeve Andre'
Re: Preventing password reuse
Rod.. Whitworth wrote: ... 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. actually, I've had somewhat different results using ports/security/crack to look at how people entered a system. A PII-450 was able to find an eight-letter dictionary PW (which was a particularly bad choice for a root PW) in a day or two, and at least one other trivial PW as well. So there is potentially some difference in the tools used. Nick.
Re: Preventing password reuse
On Tue, Jul 04, 2006 at 12:04:34AM -0400, Chet Uber 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? > > > >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. While all this complexity theory is really interesting, this is system administration. From a .sig: 'computer science is about lofty goals and algorithmic optimization; sysadminning is about cleaning up the fscking mess that results'. In theory, creating a rainbow table for the Blowfish hash as currently used is not very feasible, and by the times it becomes feasible, adding a couple of rounds is a very good defense. In practice, however, a good list of - say - 10.000 commonly used passwords is very, very likely to yield at least one hit across the complete population of users. I've heard it say that 1000 is likely to be enough. (Anyone who disagrees should first find another reason why we continue to see ssh probes.) All in all, no, storing hashes is not a good idea, *particularly* if the users are wont to choose bad passwords. Joachim
Re: Preventing password reuse
On Mon, Jul 03, 2006 at 09:22:59PM -0700, Jeff Simmons wrote: > 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" This suggests a rather fascist, and thus very effective approach: deny the users the right to create their own passwords, but institute some scheme that produces strong, but hopefully memorizable passwords. Of course, whether or not dd if=/dev/urandom bs=8 count=1 | b64encode - can be considered to produce memorizable passwords is open for debate, but the passwords it produces are quite strong, and can be typed from any reasonably modern box (say, anything that's not an all-caps text terminal - note that /usr/bin/login supports those, and this support is, in fact, documented in the FAQ). In fact, the above is exactly the way I generate at least part of my passwords. It's not necessarily possible to get everyone else to do it this way, though. However, do note that unleashing a fuzzer of some sort on the entered password and comparing the hash of each iteration to a list of previously-used hashes, while computationally intensive, is both moderately secure and reasonably easy to implement. Another thing worth considering is what happens when a user changes the password four times in five minutes. Or, more dangerously, what happens when a user keeps submitting twenty password change requests per second. Joachim
Re: Preventing password reuse
>From man page: The quality of the password can be enforced by specifying an external checking program via the ``passwordcheck'' variable in login.conf(5). Writing a script to store the ten last hashes in a ``per-user'' file is trivial and would ensure the check while using a native command ;)
Re: Preventing password reuse
On 2006/07/04 16:53, Steffen Kluge wrote: > Because the hashes in master.passwd are salted, as you come to realise > yourself further down in your post. Storing the old crypted passwords from master.passwd gives you the following information when someone changes their password: Typed new password (cleartext) Old passwords (salted+enciphered) Salts used to encipher old passwords So you run through the old salts, for each one you hash the new password with the old salt, and see if it matches. passwordcheck (login.conf) currently only feeds the password, not the username, to the checking program; this is no good for this purpose, since it makes it too easy to test other user's passwords, and would be slow on a busy system.
Re: Preventing password reuse
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.
Re: Preventing password reuse
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_.
Re: Preventing password reuse
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
Re: Preventing password reuse
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 [EMAIL PROTECTED] | 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 --
Re: Preventing password reuse
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.
Re: Preventing password reuse
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
Re: Preventing password reuse
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]
Re: Preventing password reuse
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 [EMAIL PROTECTED] 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
Re: Preventing password reuse
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 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.
Re: Preventing password reuse
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 [EMAIL PROTECTED] | 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 --
Re: Preventing password reuse
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
Re: Preventing password reuse
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
Re: Preventing password reuse
On Mon, 3 Jul 2006, Spruell, Darren-Perot wrote: > From: [EMAIL PROTECTED] > > 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
Re: Preventing password reuse
Chris Zakelj <[EMAIL PROTECTED]> writes: > Date: Mon, 03 Jul 2006 21:09:32 -0400 > From: Chris Zakelj <[EMAIL PROTECTED]> > To: "STeve Andre'" <[EMAIL PROTECTED]> > CC: misc@openbsd.org > 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 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
Re: Preventing password reuse
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 [EMAIL PROTECTED] 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
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.
Re: Preventing password reuse
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'
Re: Preventing password reuse
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: [EMAIL PROTECTED] > > > 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 [EMAIL PROTECTED] 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
Re: Preventing password reuse
From: [EMAIL PROTECTED] > 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
Preventing password reuse
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 [EMAIL PROTECTED] 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
