Xref: utzoo comp.unix.sysv386:6649 sci.crypt:4432
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!tcdcs!dce.ie!em
From: em@dce.ie (Eamonn McManus)
Newsgroups: comp.unix.sysv386,sci.crypt
Subject: Re: New Login: need crypt
Message-ID: <silhouette@dce.ie>
Date: 4 Apr 91 12:54:49 GMT
References: <1991Mar27.082707.17385@logixwi.uucp> <bigpryct@dce.ie> <4802@lectroid.sw.stratus.com>
Organization: Datacode Communications Ltd, Dublin, Ireland
Lines: 23

cme@ellisun.sw.stratus.com (Carl Ellison) writes:
>>It produces the same result as
>>crypt() for short passwords (<= 8 plaintext characters); for longer
>>passwords it apparently crypts each block of eight characters separately
>>and concatenates the results.
>
>If I understand this correctly, bigcrypt() will let you know, through the
>number of output blocks, truncate(password_length / 8).
>
>Needless to say, that's a security flaw.

The passwords are stored in a user database that is not pleb-readable.  So
the security of the encryption scheme is not as important as in the
traditional setup where encrypted passwords appear in /etc/passwd.  Not
that I think this is an excuse for laxity.

I think that 2^56 is an adequately large keyspace, so it would be better
to treat long passwords by combining the extra characters with earlier
ones so as to produce 8-byte keys containing characters that would not
ordinarily be in passwords.

,
Eamonn