levy@ttrdc.UUCP (Daniel R. Levy) (02/17/88)
In article <18083@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > Actually at BRL, it remembers all past passwords that everyone used and > won't ever let you reuse them (or use the "passwd" program to set too > accounts to the same password). How is this implemented without saving passwords somewhere in the clear? Also -- if "passwd" unexpectedly refuses to let a user set a proposed password he has chosen, it would be a tipoff that he has stumbled over somebody else's current password. -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
mikel@codas.att.com (Mikel Manitius) (02/18/88)
In article <2178@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > > Also -- if "passwd" unexpectedly refuses to let a user set a proposed password > he has chosen, it would be a tipoff that he has stumbled over somebody else's > current password. This is why my original posting said that the old password table should be indexed per user, so if the password is refused, then it can only mean that THAT particular user used THAT particular password before. This will also reduce the validation time, resulting in less calls to crypt(3). -- Mikel Manitius mikel@codas.att.com
tjfs@otter.hple.hp.com (Tim Steele) (02/18/88)
You don't need to save them in clear; the usual encrypted version will do. However, you're right about the tipoff. Tim ------------------------------------------------------------------ |tjfs@otter.hple.hp.com | Tim Steele (G4IAC), | |tjfs%otter@hplabs.HP.COM | Hewlett-Packard Laboratories,| |tjfs@lb.hp.co.uk | Filton Road, Stoke Gifford, | |tjfs%hplb.csnet@csnet-relay.arpa | Bristol, Avon, BS12 6QZ, UK | |...!mcvax!ukc!hplb!tjfs | +44-272-799910 ext 24019 | ------------------------------------------------------------------
ark@alice.UUCP (02/18/88)
In article <2178@ttrdc.UUCP>, levy@ttrdc.UUCP writes: > In article <18083@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > > Actually at BRL, it remembers all past passwords that everyone used and > > won't ever let you reuse them (or use the "passwd" program to set too > > accounts to the same password). > > How is this implemented without saving passwords somewhere in the clear? > Also -- if "passwd" unexpectedly refuses to let a user set a proposed password > he has chosen, it would be a tipoff that he has stumbled over somebody else's > current password. Easy solutions to both problems: 1. Run the passwords through the sort of irreversible hash function used with /etc/passwd before storing them. When a user selects a new password, hash it and look up the hashed password in the database. 2. Seed the database with every easy password you can think of, such as everything in an unabridged dictionary, a bunch of people's names, etc. If the database starts with half a million entries, you haven't learned much when the system tells you you've picked a bad password.
rjd@occrsh.ATT.COM (02/18/88)
>> Actually at BRL, it remembers all past passwords that everyone used and >> won't ever let you reuse them (or use the "passwd" program to set too >> accounts to the same password). > >How is this implemented without saving passwords somewhere in the clear? >Also -- if "passwd" unexpectedly refuses to let a user set a proposed password >he has chosen, it would be a tipoff that he has stumbled over somebody else's >current password. >|------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, Why does everyone assume that you HAVE to save it in the clear? YOU DON'T!! As I said before: "... Since the "seed" [should be "salt"] used for the permutation algorithm is the first two characters of the encrypted password, all you need to do is encrypt your new password using the seed of each of the old ones, and then compare the encryption to the encrypted password whose seed you are using." As proof, I offer this: The login() command uses the following lines to get the password: ---------------------------- password = getpass(prmt); p1 = crypt(password, pswd); if(strcmp(p1, pswd)) .... ---------------------------- where: password is the clear text password typed in by the potential user. prmt is the prompt. pswd is the encrypted password in the password file. p1 is the encryption of the password inputted by the potential user. To quote from the manual: ---------------------------- crypt(3C) char *crypt(key, salt) ....is the password encryption function.... Key is a user's typed password. Salt is a two-character string chosen from the set[a-zA-Z0-9./]; this string is used to perturb the hashing algorithm in one of 4096 different ways; after which the password is used as the key to encrypt repeatedly a constant string. The returned value points to the encrypted password. THE FIRST TWO CHARACTERS ARE THE SALT ITSELF. ---------------------------- Capitals mine.... So, JUST SAVE THE encrypted passwords!!! Then, when a new one is entered, encrypt it using each saved encrypted password's salt and compare it to the password whose salt you are using! Yeah, sure, its going to take a while to do, but who said security was convenient? I don't know about saving ALL past passwords, though; maybe just the last four or five.... Randy
mikep@ism780c.UUCP (Michael A. Petonic) (02/19/88)
In article <2178@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <18083@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: >> Actually at BRL, it remembers all past passwords that everyone used and >> won't ever let you reuse them (or use the "passwd" program to set too >> accounts to the same password). > >How is this implemented without saving passwords somewhere in the clear? >Also -- if "passwd" unexpectedly refuses to let a user set a proposed password >he has chosen, it would be a tipoff that he has stumbled over somebody else's >current password. For the first part, an easy method would be: for each item in old password list (in encrypted form) get salt from old password encrypt new proposed password with salt from old password if they are the same, notify user that he can't use it. I don't think BRL's method would tip off whether the password is a current password of some other user's. It would, however, tell you what has been used before, since it stores all used passwords from everybody since the dawn of time. -MikeP
ron@topaz.rutgers.edu (Ron Natalie) (02/20/88)
Remembering old passwords doesn't involve storing the passwords in the clear anymore than remembering the current one does. Jeez. -Ron
chapman@eris (Brent Chapman) (02/20/88)
In article <18174@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >Remembering old passwords doesn't involve storing the passwords in the >clear anymore than remembering the current one does. > >Jeez. Ya, but you'd need to check the current password with _all_ the salts used in the past passwords. Assume you have 50 users who change their passwords monthly. After a year, you've got (potentially) 600 different salts to encrypt the new password with and compare to the old passwords. Now, if I remember the results of the tests I ran several months ago correctly, my unloaded Sun 3/280 (not exactly a wimpy machine) can encrypt about 20 passwords a second. That's 30 seconds to check 600 salts. Assume that, on average, if a password is being "reused", it will be discovered half-way through the check. The user _still_ has to wait 15 seconds to be told "sorry, try another password". And _that's_ assuming you have a relatively fast, unloaded machine; I'd hate to think what it would take on a VAX 11/750 with an average daytime load of 2.0, for instance. The more users you have, and the more they change their passwords, the longer the delay gets. What you end up providing is a strong incentive for users to _not_ change their passwords, because it's such a pain in the ass. Effective security needs to be as "transparent" and easy to Joe User as possible, otherwise Joe User will do something to make his life easier, but that has the side effect of blowing your so-called "security" all to hell. -Brent -- Brent Chapman Capital Market Technology, Inc. Senior Programmer/Analyst 1995 University Ave., Suite 390 {lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704 capmkt!brent@{lll-tis.arpa,cogsci.berkeley.edu} Phone: 415/540-6400
jfh@killer.UUCP (John Haugh) (02/21/88)
One thing I learned about cryptanalysis, any information you provide to a potential villian is too much. The security of letting people know you use DES is that DES is supposed to be hard to break. However, providing a tip-off that someone _may_ be using a certain password provides with it the information that potential villian should try that password on all current users, and if someone _is_ using that password, then the security of the system has been compromised. So, regardless of how difficult DES is to break, telling the bad guys that you wouldn't let two people use the same password, either now or ever is a Bad Thing. Think about it. - John. -- John F. Haugh II SNAIL: HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "You can't threaten us, we're Dallas, TX. 75243 the Oil Company!" (214) 231-0993 Ext 260
mikel@codas.att.com (Mikel Manitius) (02/21/88)
[ ... discussions about remembering previously used passwords ... ] It's easy enough to make passwords less than trivial. Select a part of your password to be typed in with the SHIFT or CTL key down... -- Mikel Manitius mikel@codas.att.com