lmc@denelcor.UUCP (Lyle McElhaney) (12/09/84)
My posting about a mailing list for Unix security issues seems to have
gotten out (I sometimes wonder...) and one comment about the security
of the mail list itself is that the contents should be encrypted. So...
a few questions to the assembled masses seems to be in order:
Would crypt(1) be appropriate for this use? I know the enigma codes can
be broken, but has anyone actually done it in the case of crypt? Is it
something to worry about? If crypt is not right, what would be a more
acceptable way of encryting the data? I assume we have a way of passing
the keys about securely.
Lastly, since crypt is not *supposed* to be passed outside the US of A,
how can we extend the list to those in, say, Korea? Caesar encoding
probably won't hack it.
Comments to me via mail, please. I'll summarize.
--
Lyle McElhaney
{hao, stcvax, brl-bmd, nbires, csu-cs} !denelcor!lmcgwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/09/84)
> My posting about a mailing list for Unix security issues seems to have > gotten out (I sometimes wonder...) and one comment about the security > of the mail list itself is that the contents should be encrypted. So... > a few questions to the assembled masses seems to be in order: > > Would crypt(1) be appropriate for this use? I know the enigma codes can > be broken, but has anyone actually done it in the case of crypt? Is it > something to worry about? If crypt is not right, what would be a more > acceptable way of encryting the data? I assume we have a way of passing > the keys about securely. > > Lastly, since crypt is not *supposed* to be passed outside the US of A, > how can we extend the list to those in, say, Korea? Caesar encoding > probably won't hack it. > > Comments to me via mail, please. I'll summarize. > -- > Lyle McElhaney > {hao, stcvax, brl-bmd, nbires, csu-cs} !denelcor!lmc "Crypt" has indeed been broken; you can find out how to go about it by reading an article in the latest BLTJ. I assure you that anyone who is serious about snooping on the security newsgroup would. I think a more severe problem is that you cannot possibly know whether the people on your restricted mailing list are good guys or bad. Just because I post a request to you from "somehost!root" does NOT mean that I am trustworthy. Indeed, it doesn't even mean that I have access to a UNIX system!
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/09/84)
I apologize for my response to Lyle getting broadcast. After stashing my edited copy of his note into a file while in "followup" mode, I clobbered the editor buffer and wrote what should have been a 0-length file to be "posted", intending for that to abort safely. I should know better than to expect software on UNIX to do the sensible thing..
menageri@mit-eddie.UUCP (The Menagerie) (12/16/84)
Can anyone out there tell me how passwords are encoded on Unix? (4.2BSD at least, although if it is different on others, I'd be interested to see other algorithms) Please note that I am *NOT* trying to break the encryption, I just want to know specifically how it is done, so please don't flame at me about the possibility/impossibility of breaking it. Thanks in advance. greg uucp: !genrad!mit-eddie!menagerie arpa: greg@grape-nehi%mit-mc or g.mcmullan@mit-eecs%mit-mc us snail: 500 memorial drive cambridge, ma, 02139[-4326] (617) 225-8942
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/19/84)
> Can anyone out there tell me how passwords are encoded on Unix?
All versions of UNIX from 7th Edition on encrypt the passwords
with a C library routine described in CRYPT(3C). See the manual
for details; basically the NBS DES is used, with variations.emks@uokvax.UUCP (12/20/84)
/***** uokvax:net.crypt / mit-eddi!menageri / 9:54 pm Dec 16, 1984 */
Can anyone out there tell me how passwords are encoded on Unix? ...
... Please note that I am *NOT* trying to break the
encryption, I just want to know specifically how it is done, so please
don't flame at me about the possibility/impossibility of breaking it.
Thanks in advance.
greg
/* ---------- */
Greg,
The actual source code that does the encryption is considered "proprietary"
under the provisions of the UNIX* license agreement, but the /bin/passwd and
/{bin,etc}/login programs use the crypt(3) call which you can locate in
/lib/libc.a. Crypt(3) is simply a software implementation of the DEA (or
DES, depending on who is certifying the algorithm, if anyone).
Most sites use "/bin/passwd" to generate the crypted password for installation
in the /etc/passwd file. [I know this isn't what you were looking for, but I
found this information useful when I first learnt about it several years ago.]
In /bin/passwd, the "salt" is generated using the time and other factors in
a fashion like (NOTE: may be site-dependent, and the means don't affects the
security of the password at all, since the salt is usually available.]
time(&salt);
salt += getpid(); /* I've seen other variants used -ks */
saltc[0] = salt & 077;
saltc[1] = (salt >> 6) & 077;
while(i < 2) {
c = saltc[i] + '.';
if(c > '9')
c += 'A' - '9' - 1;
if(c > 'Z')
c += 'a' - 'Z' - 1;
if(!(c & 037))
c += '@';
saltc[i++] = c;
}
But, again, the actual password is generated using the crypt(3) call using
the output of the routine above for the salt. And I think you'll have a
difficult time, should you be inclined, reversing the process by anything
short of brute force. But it is not impossible. Read the most recent BLTJ
supplement volume on UNIX for more security information.
Crypted passwords are a definite "plus," but when people are told "NO,"
they'll *always* find a way. It reminds me of saying "NO!" to my little
nephew...
Have a safe holiday.
kurt
P.S. Does anyone know if the output of crypt(3) is unique? I.e. could there
be more than one key/salt combination which outputs the same result?davy@ecn-ee.UUCP (12/22/84)
The output of crypt(3) is not "straight" DES (DEA). The "salt" is used to permute one of the tables (the E-table) in one of 4096 different ways. This means that you cannot simply reverse the DES algorithm to decrypt the password (see below for more on this). Actually, most people have a misconception about password encryption on UNIX -- your password is not encrypted, rather, your password is used as the KEY to encrypt a block of zeros 25 times. This encryption is performed after the E-table has been permuted. Then, the output of the encryption is "converted" such that you get 10 characters from the set a-zA-Z0-9, '.', and '/'. The salt is tacked on to the front of this, giving you a 12-character encrypted password. Because the encryption key is thrown away after the encryption, and since the output of the encryption is shifted, anded, ored, etc., crypt(3) is essentially one-way encryption. When you log in and type your password, login does NOT decrypt the password contained in the password file. Rather, it calls crypt(3) with your password attempt and the salt from the password file, and then compares the encrypted result with that stored in the password file. A friend and I once sat down and calculated some things about crypt(3). One of the things we came up with was that to generate every possible encrypted string and store it along with a password which generated it (thus, you could crack passwords using table lookup) would take something on the order of 45 415-MByte disk drives! Of course, since it takes a VAX about 1 second to crypt(3) a single string, the idea is probably computationally infeasible even if you could get the disk drives. We also decided (I don't remember how -- I think it was by trial and error) that there are multiple passwords which will give you the same encrypted result. This is not including the fact that any passwords which are identical in the first eight characters (e.g., "bookkeeper" and "bookkeeping") will encrypt to the same thing (except of course if they use different salts), since DES only uses a 56-bit key (8 chars * 7 bits/char = 56 bits). --Dave Curry
henry@utzoo.UUCP (Henry Spencer) (12/29/84)
> P.S. Does anyone know if the output of crypt(3) is unique? I.e. could there > be more than one key/salt combination which outputs the same result? Definitely. If for no other reason, because the output is folded into a more limited character set than is used either for input or for internal processing. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (01/02/85)
Ooooppsss... My mistake. It was the V6 password encryption that did the
folding to a more limited character set. It's been a long time since I
last read the "password security" paper, and I had gotten the two mixed
up. The V7 algorithm does not do this. One wonders why; it seemed a
useful precaution against cryptanalytic (as opposed to brute-force-search)
attacks on passwords.
My thanks to Steve Bellovin for pointing this out.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry