chris@GYRE.UMD.EDU (Chris Torek) (11/09/88)
From: auspex!guy@uunet.uu.net (Guy Harris) >... specify a password with complex characters in it, >either non-alphabetic, or numeric mixed with alphabetic and of >at least a certain length (10 characters seems like a good size). Except that UNIX systems tend to pay attention only to the first 8 characters of the password. There is, of course, a perfectly good reason for this limit, and it should be mentioned: The Unix password encryption algorithm is to use a `salted' DES to encrypt a constant string using the password as a key. DES keys are 56 bits long; ASCII is a 7 bit code; and 8 times 7 is, of course, 56. It is therefore obvious that there are no passwords that cannot be specified in at most eight characters, and any more are theoretically superfluous. (The `salt' above is to discourage brute-force attacks using hardware DES implementations. It is used to shuffle the E box in some manner. I am not a cryptographer; I leave the details to those who are.) Nonetheless, there are some ASCII characters that are inordinately difficult to type (for reasons which I would rather not argue on the TCP-IP list [I myself am firmly in the `Emacs camp': unescaped in-band flow control is wrong :-) ]). There is also a question of implementation of the password reader: can one type a sequence with an imbedded ASCII NUL? I would rather that the password reader accept an arbitrarily long password, and use some mapping function to compress longer passwords into eight 7-bit `bytes' for use by the modified DES encrypter. This longer password would still be `the same' as some shorter one, but the shorter one might be impossible to enter. At worst, you will require people with long passwords either to type the whole thing every time, or to figure out the equivalent eight character string. Chris
wbe@bbn.com (Winston B Edmond) (11/15/88)
Chris Torek writes: > ... It is therefore obvious that there are no passwords >that cannot be specified in at most eight characters, and any more are >theoretically superfluous. ... Nonetheless, there are some ASCII >characters that are inordinately difficult to type ... CR, LF, and the line oriented input editing characters come to mind as characters that are difficult to include in passwords. -WBE
bart@videovax.Tek.COM (Bart Massey) (11/17/88)
In article <8811090812.AA13935@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes: > [ a quite stylish explanation of why UNIX passwords are currently 8 chars max] What I think I'd rather see is just doubling the size of the password field in /etc/passwd, and encrypting the 2 8-char chunks of a 16-char password in two steps. This way, you really would greatly increase the security of reasonable-length passwords, and I don't really see any disadvantages over Chris's scheme of hashing bits together... Also note that storage capacity is growing like crazy, and one can almost construct a reasonably fast crypt() inversion dictionary on e.g. optical store even given the two salt chars (at least by my calculations, which are probably totally hosed.. :-). This would push that problem into the future again... This probably isn't an appropriate topic for TCP/IP. I'm moving it to misc.security... Bart Massey ..tektronix!reed.bitnet!bart