franco@bbn.com (Frank A. Lonigro) (05/04/89)
Does anyone have a lightning fast "crypt" routine or know where I can get one to do password encryption on Unix????? I'm writing a utility to find and weed out easy to guess users passwords to make our systems more secure. Thanks in advance, -franco ################################### ### ######### ##################### # Frank A. Lonigro # ### ######### ##################### # franco@bbn.com # ### ### ### ### # franco%bbn.com@relay.cs.net # ### ### ### ### ### ### ### # ...!harvard!bbn!franco # ### ### ### ### ### ### ### # BBN Inc., Cambridge, Mass. # ### ### ### ### ### ################################### #######################################
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (05/04/89)
In article <39439@bbn.COM> franco@bbn.com (Frank A. Lonigro) writes: >Does anyone have a lightning fast "crypt" routine or know where I can get >one to do password encryption on Unix????? I'm writing a utility to find >and weed out easy to guess users passwords to make our systems more secure. Geez, If I wanted to write this program, I'd rather use a slow encryption method, like the included "crypt(key,salt)" C routine from UNIX. I guess I'd just rather let this program run all night instead of create a potential security hole, especially one to be passwd across the net. --M.
wls@csd4.milw.wisc.edu (Bill Stapleton) (05/05/89)
Frank A. Lonigro writes: >... I'm writing a utility to find >and weed out easy to guess users passwords to make our systems more secure. Mark A. Heilpern writes: >Geez, If I wanted to write this program, I'd rather use a slow encryption >method, like the included "crypt(key,salt)" C routine from UNIX. I guess I'd >just rather let this program run all night instead of create a potential >security hole, especially one to be passwd across the net. Random aside: One way of keeping tabs on passwords is to grab the *old* password whenever the password is changed. That way, you don't need crypt (you have what the user typed), and you don't actually fool with valid passwords, yet you can still see what sorts of passwords are being used, and identify people who tend to use their first names, etc. No, I haven't actually done this, its just an interesting idea I heard at a security talk once upon a time... -- Bill Stapleton wls@csd4.milw.wisc.edu uwvax!uwmcsd1!wls
walter@hpsad.HP.COM (Walter Coole) (05/17/89)
crypt's algorithm was designed to be slow. If there existed a fast crypt, it would be dangerous, as it would allow rapid trial of obvious passwords. It seems that what you're trying to do is to guess other people's passwords, which is what crypt and salt are trying to prevent. Another approach is to examine passwords for obviousness at assign time. I have a program called obvious that examines trial passwords for common trigrams. It detects most words and common names. mail me at walter@hpsadlc.HP.COM for a copy.
mats@oblio.UUCP (Mats Wichmann) (05/18/89)
In article <720009@hpsad.HP.COM>, walter@hpsad.HP.COM (Walter Coole) writes: > crypt's algorithm was designed to be slow. If there existed a fast crypt, it > would be dangerous, as it would allow rapid trial of obvious passwords. For further reading on this issue, refer to _Computing_Systems_ (the Usenix Association Journal), Volume 1, Number 3. Matt Bishop presents a paper entitled _An_Application_of_a_Fast_Data_Encryption_Standard_Implementation_. The paper has also, according to the footnote, been published as TR 87.18 by the Research Institute for Advanced Computer Science. -mats wichmann -acer counterpoint, inc.