From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 9-JAN-1993 12:07:18.11 To: info-vax@kl.sri.com CC: Subj: Re: PASSWORDS & SCHEMES >JLW@PSULIAS.PSU.EDU ("J.Lance Wilkinson, 865-1818", 814) writes: >> Since, as Dan mentioned, we have a way to add new items to the >> DEC-supplied dictionary, I've wanted to do was to adapt a working >> dictionary-based password policy program (like Ted Neiland's, for >> example), to, instead of validating the plaintext password against >> a dictionary, record the plaintext passwords which got this far (thus >> they are *accepted* by VMS's other filters) in a file. Weekly, we'd >> analyze the file of recorded plaintext passwords (saved *without* the >> username, of course) to see if there were any words cropping up more >> often. These words would then need to be added to the dictionary >> because they're getting too popular as passwords. > >This is an incredibly bad idea. It's somewhat irrelevent if you keep the >username or not. If you have 20 users change the password in a week, you >can guess easily, or find out exactly has each one (by looking at the password >change date in the UAF). I agree, but the basic idea is not without merit. >Plus, this is a hacker's dream. Why use dictionaries when you have a file >of x known good passwords on the system? Think again on this one, and don >your asbestos suit... Yep - this scheme would be a great attack path. However, done in a way that protects against abuse, its very interesting! Consider Dr. (Professor) Net News - Gene Spafford's (spaf@cs.purdue.edu) work. At the most recent USENIX Security Symposium (Baltimore - September 14-16, 1992), he presented his work on project OPUS - "Observing Reusable Password Choices". While this work is being done to develop a password screening method for passwords in UNIXland (where they have less "built-in" capability than we do here in VMSland), it is - I believe - applicable to us VMSers. If nothing else, I believe that you'll find some things about it interesting. To test their work, they had to develop a "representative password sampler". Obviously - quoting Spafford here - ".. the challenge of such a sampling mechanism is how to protect it from attack and how to protect the results from being used against the system..." Now, I know that this is not a place for "CSish" research stuff, but I thought that you might be interested in a pointer, anyway. Basically, he uses public cryptography to protect the plaintext passwords in transit (i.e.: the remote systems all over the net have HIS public key and HE - back at the site that is receiving the encrypted passwords for analysis - has his private key ). He advertises the UNIX-based password collection software as being available, but the public key component must be licensed from RSA Data Security (Redwood City, CA). However, you could susbtitute your own crypto if you wanted to do so, I suppose. In his paper, he points out that a good dictionary-based method of disallowing the choice of poor passwords has a serious problem: storage. For his research, he is using a "moderately comprehensive" dictionary with 500,000 words in it and he points out that this consumes 5MB. Including his full-fledged collection of dictionaries (11 foreign language, proper names, atlas, and slang terms) it takes up 30MB! OPUS is targeted at screening passwords without this massive storage requirement. His paper is available in the 1992 USENIX Security Symposia proceedings (available from USENIX at 2560 Ninth St., Suite 215 - Berkeley, CA 94710 for $39 for non-USENIX members + $11 per copy for outside-U.S. shippments). OPUS is part of COAST (Computer Operations Audit and Security Tools) project at Purdue. Contact Spaf about these projects and try to bring some $ to the table. This is good work that needs support. OPUS will be offered - first - to COAST members, and then to the rest of us. Bring money - become a COAST member! (Write spaf@cs.purdue.edu with offers of $). If you have no $, I'd wait for Gene's work to be published and then just grab his algorythims for inclusion in a local filter UNTIL DEC gets around to supplying it by default - if they ever do. Meantime, the only problem with the collection and storage of plaintext user password choices is the not-so-obvious one of inadvertently making them available to an attacker. Come, come now. There has to be someone out there who said "Hey - the plaintext files ARE protected against access, you know!". Experience shows that passwords STILL are the biggest problem. Consider that the ability to "mix in" with the legit user community (un-noticed by curious system managers and annoying programs that whack your illicitly obtained privs) makes you "golden". You 1) steal/guess a password and then 2) just "slip" in with the rest of the users where, (presumably) you can use a system bug or a system/network management oversight to get/give up privs as you need them during your attack. ... (and he was seen wandering off toward the bar, talking to himself...) RayK 8) Ray Kaplan I don't need to have my point of view prevail - I just want to be correct.