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.
