yba@arrow.bellcore.com (Mark Levine) (11/12/88)
In article <4627@rayssd.ray.com> gmp@rayssd.RAY.COM (Gregory M. Paris) writes: >Encouraging the use of more password selection methods is what is really >desired. Not only must you choose something you can remember, but it must be something relatively secure against guessing, and it must be changed regularly to prevent the "kid with a pc" from doing exhaustive generate and match runs against it. I was given some software by another group here to help tighten password administration, and even if it becomes known, the generator a cracker will build is still acceptable. The scheme is also easier on the administrator if somewhat bothersome for the user: - modify /bin/passwd (on your central server if you distribute the passwd file) to require that all passwords are at least 7 characters in length, have at least one upper-case and one lower-case letter, and one non-alphabetic character. This immediately removes short passwords, dictionary entries and passwords which match the user name (in _most_ cases!). The patches are straightforward, but I don't have the author's leave to post them (yet, and since the author has not, I question whether I will obtain same). Then comes the problem of getting people to use it. If you distribute the password file, then all slave machines get a dummy program that tells the user to log in to the central password machine and change passwords, which becomes the shell in /etc/passwd. On the master machine, this program is the real one. It is named as "needpass_sh" (or _csh or _ksh) on both types, indicating what shell to restore after the password has been changed. The program then requires the user to know: - the old password to log in - some piece of other data (or even a pass-algorithm) to convince the program this is indeed who we think (perhaps a file of less than public data to match against: SS#, boss, first day on job) and runs the new passwd program for the user, logs the entry, and uses chsh to restore the old shell (then the file is propagated in the distributed scheme). We have a database in the company that helped with selecting the "other data" and that I don't want to describe in detail. Having something like this allows you to get people to change their passwords on a regular basis, because you can just edit all shell entries in /etc/passwd to the needpass_* name whenever the "age" acceptable to you arrives. Should be about every 90 days with a password so constructed (but I don't keep up with theory, so let me know of this is optimistic!). When it was explained to local users that crackers had been working on old copies of our /etc/passwd, they were both understanding and cooperative, even though I screwed it up on the first run for 30 of them (remember to make sure that /bin/chsh believes all your local shells are valid!). This is also a great way to find out who your ex-users and non-users are (after 30 days of unchanged shell). If you can exchange email and are interested in more detail, please get in touch. Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com
jim@applix.UUCP (Jim Morton) (11/15/88)
In article <931@sword.bellcore.com> yba@arrow.bellcore.com (Mark Levine) writes: > - modify /bin/passwd (on your central server if you distribute the > passwd file) to require that all passwords are at least 7 characters > in length, have at least one upper-case and one lower-case letter, > and one non-alphabetic character. This immediately removes short > passwords, dictionary entries and passwords which match the user > name (in _most_ cases!). The patches are straightforward, but I > don't have the author's leave to post them (yet, and since the author > has not, I question whether I will obtain same). > In Unix V.3.2, as some people have pointed out, the encrypted passwords are now in /etc/shadow. Also, AT&T added some serious passwd restrictions - not like in BSD where it asks you a few times to enter a longer password and then gives in to you using a short one. The V.3.2 passwd mechanism: -REQUIRES user accounts to have a password. You can't put one on, then edit /etc/shadow, and from then on log in without one -will not let you re-use the user name as the passwd -will not let you use short (I forget the length) passwords -REQUIRES that they be alpha and numeric This was such a change for me that I found myself both using a common alphanumeric string that I wouldn't forget (license plate, "lotus123", etc.) and/or writing the password on the system console. The end result, from a cracker's point of view, I believe is worse than having any type of password be acceptable. Password cracking programs now have a set of guidelines to go by! -- Jim Morton, APPLiX Inc., Westboro, MA UUCP: ...harvard!m2c!applix!jim jim@applix.m2c.org
msb@sq.uucp (Mark Brader) (11/16/88)
Eleazor bar Shimon (yba@sabre.bellcore.com) repeats an often-made suggestion: > - modify /bin/passwd (on your central server if you distribute the > passwd file) to require that all passwords are at least 7 characters > in length, have at least one upper-case and one lower-case letter, > and one non-alphabetic character. And I will repeat my standard response to it: Passwords meeting the above specifications, while more secure against electronic forms of cracking, are LESS secure against casual observation of the typing fingers! This is particularly an issue if they are to be used by occasional typists and in an environment where physical security is minimal -- a common enough situation. Nobody would do that? I did! I once learned a root password by that method. (It was only 5 characters.) If you're going to modify the system's password code, I think the first thing you should do is remove the standard UNIX limit of 8 significant characters on a password. (If you didn't think there was such a limit, try it! I believe that only the first 8 characters are significant on *all* common UNIX systems. The reason is the DES key length, though the password encryption is not pure DES.) Here is an easy way to raise this limit to 16 characters: #define MAXPWD 8 register char *pwd; /* pointer to password as typed */ .... char pw1[MAXPWD+1], pw2[MAXPWD+1]; /* result */ register char *p = pw1, *q = pw2; while (p < &pw1[MAXPWD+1]) { *p++ = *pwd; if (*pwd) pwd++; *q++ = *pwd; if (*pwd) pwd++; } *p = *q = '\0'; This splits the given password into 2 virtual passwords of up to 8 characters each. Encrypt them separately by the present method, each with its own salt, and concatenate the results to form the character string to place in the password file. The inverse process, for login and the like, should be obvious. Now require that all passwords be at least *12* characters, preferably 16, and not obvious from dictionary search, keyboard patterns, and so on. I think that with 16 characters all-lower-case-letters is quite sufficient if one wants to use it, and desirable if there is any chance of being watched. Mark Brader "Alas, there is NO SUCH THING as SoftQuad Inc., Toronto 'NO SUCH THING as privileged access.'" utzoo!sq!msb, msb@sq.com -- Alan Silverstein
yba@arrow.bellcore.com (Mark Levine) (11/17/88)
In article <1988Nov15.205258.12029@sq.uucp> msb@sq.com (Mark Brader) writes: >> - modify /bin/passwd ... to require that all passwords are at least 7 characters >> in length, have at least one upper-case and one lower-case letter, >> and one non-alphabetic character. > >Passwords meeting the above specifications, while more secure against >electronic forms of cracking, are LESS secure against casual observation >of the typing fingers! The context of my suggestion was prevention of electronic cracking by the worm and by network crackers. Not to be petty, but I don't see how your conclusion follows at all. Are you claiming that use of the top row and the shift key makes it easier to follow a typist? Changing one program, /bin/passwd, seems far easier than systematcally replacing all routines and doing double encryption (ah, for dynamic linking!). Part of any solution for admins should probably be the notion that the solution is cheap, ie: does not cause more trouble than the cracker does by at least a factor of two. I'd suggest that if you are concerned with physical security, hiding the hands of users is the wrong place to start, and making them type in 16 character passwords is going to be even harder to sell than remembering ones that are not common words (leading to the dreaded "write-it-down" problem). Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (11/18/88)
In article <853@applix.UUCP> jim@applix.UUCP (Jim Morton) writes:
: -REQUIRES that they be alpha and numeric
: This was such a change for me that I found myself both using a common
: alphanumeric string that I wouldn't forget (license plate, "lotus123", etc.)
: and/or writing the password on the system console. The end result, from
: a cracker's point of view, I believe is worse than having any type of
: password be acceptable. Password cracking programs now have a set of
: guidelines to go by!
This is why it is important to for passwd to only be smart about the kinds
of passwords that are *bad*. ANY time you try to specify what a good password
looks like, you either cut down the search space greatly or make unmemorable
passwords. There are many ways to make good passwords, so don't restrict
people to one way. Just don't let 'em use any bad ways.
Larry Wall
lwall@jpl-devvax.jpl.nasa.govtrn@aplcomm.jhuapl.edu (Tony Nardo) (11/22/88)
In article <853@applix.UUCP> jim@applix.UUCP (Jim Morton) writes: >The V.3.2 passwd mechanism: >... > -REQUIRES that they be alpha and numeric There are some versions of System V which have an interesting bug. "passwd" will permit entry of an illegal password without complaining. When the user logs off, it is impossible to directly log back on to that account. However, one may still use "ftp" to access the user's account with the new password! ============================================================================== ARPA, BITNET: trn@aplcomm.jhuapl.edu UUCP: {backbone!}mimsy!aplcomm!trn "Always remember that those who can, do, and that those who can't, teach. And those who can't teach become critics. That's why there're so many of them." PORTRAIT OF THE ARTIST AS A YOUNG GOD (Stephen Goldin) ==============================================================================