Using crypt()

I'm testing a encryption program that includes use of crypt().  
(I know its not the strongest scheme.)  Here's the problem:

We ask users to e-mail us an encrypted password derived form the
crypt() utility when they set up an account.  When they want to
change information related to the account, we ask them to e-mail the
cleartext of the encrypted password.  The program then checks to see
if the cleartext matches the original encrypted password. If so, their
information is automatically updated.

The only problem is when users mistakenly supply cleartext initially,
they can never update their information because the program isn't
smart enough to realize that the user was submitting cleartext instead
of an encrypted password when setting up their account.

Is there any way to check and see if the text the user 
supplies initially has been encrypted or is cleartext?

Or is there a better way to do this?

The account does not contain financial information, otherwise a
stronger scheme would be required.  Right now the program allows the
user to choose from the auth schemes MAIL-FROM, CYPT-PW or PGP.

Any hints would be appreciated.

Eric

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 4 Apr 1996, Eric Eden wrote:

> I'm testing a encryption program that includes use of crypt().
> (I know its not the strongest scheme.)  Here's the problem:
>
> We ask users to e-mail us an encrypted password derived form the
> crypt() utility when they set up an account.  When they want to
> change information related to the account, we ask them to e-mail the
> cleartext of the encrypted password.  The program then checks to see
> if the cleartext matches the original encrypted password. If so, their
> information is automatically updated.
>
> The only problem is when users mistakenly supply cleartext initially,
> they can never update their information because the program isn't
> smart enough to realize that the user was submitting cleartext instead
> of an encrypted password when setting up their account.
>
> Is there any way to check and see if the text the user
> supplies initially has been encrypted or is cleartext?

The only way I can think of is if the text that the user supplies is not 13
characters long and contains characters not used in crypt(3) base64 encoding,
then the text is definitely not a hashed password.  This would catch nearly
all cleartext passwords, although there is a little room for error.  FYI, the
characters used for base64 encoding are [0-9],[A-Z],[a-z],'/', and '.'.

- -- Mark

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
markm@voicenet.com              | finger -l for PGP key 0xf9b22ba5
http://www.voicenet.com/~markm/ | bd24d08e3cbb53472054fa56002258d5
"The concept of normalcy is just a conspiracy of the majority" -me

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMWRTIbZc+sv5siulAQGf3AP+LfrlTrpvQgFju2k5yOyUTAxHDGxjHWFg
9M32OU1/Lsj9DtVk/WJBqBmy3SfHJ0ZdppZlxsrT4eywTUaqeg+dOxrQ/WPMPz8c
smNykbfmVvzdiwFn4pQJ4/mPiSzFOSz3vshgMnZHzum6SpQ1+Hd4WYPD0Qcsc83q
5SKrfDRfVSs=
=IgUR
-----END PGP SIGNATURE-----

On Thu, 4 Apr 1996, Eric Eden wrote:
> The only problem is when users mistakenly supply cleartext initially,
> they can never update their information because the program isn't
> smart enough to realize that the user was submitting cleartext instead
> of an encrypted password when setting up their account.

Far from bulletproof, but the three Unice I just checked, SCO Unix, 
UnixWare and FreeBSD, all generate 13 character encrypted passwords.
I believe this is the norm for crypt.

Very few people around here have 13 character clear text passwords,
those that do are either very security concious and won't use CRYPT-PW
or it's just coincidental and their bad luck.

Anyway, requiring the supposedly encrypted password to be 13 characters
is probably about the best you can do.  If crypt generated recognizable
patterns it wouldn't be very useful, would it?

I'm still debating whether or not to allow our clients to use this 
option.  We may require clients registering domains to pick up a copy 
of PGP first.  

Dan
-- 
 Dan Busarow
 DPC Systems
 Dana Point, California