Hi - (I'm the 'someone' who said crypt worked on windows) -
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 14, 2003 5:06 AM
> To: Patricia Hinman; [EMAIL PROTECTED]
> Subject: RE: crypt() unix function, what about windows cryption?
> .htpasswd file
>
>
>
> ------------------------------------------------
> On Thu, 13 Feb 2003 20:57:05 -0800 (PST), Patricia Hinman
> <[EMAIL PROTECTED]> wrote:
>
> > OOPS mistake corrected
> > > I did stumble across a method call to a cryption()
> > -------wrong crypt() is the method ------
> >
> > I have just discovered it is a unix function. It
> > doesn't decrypt. One must always crypt user input then
> > check for equality.
> > if (crypt ($guess, $pass) eq $pass) {
> > # guess is correct
> > }
> >
> > I guess that means I can't use it on my Win98 box. I
> > was really hoping for a platform independant method.
> >
>
> Is there a reason why this isn't able to work in your environment
> (assuming crypt works on windows, which someone stated it would)?
> In general passwords should not be stored as readable text
> *ever* despite the contrary being used on an overly popular OS.
> In general, the only problem this introduces, is rather than
> sending someone their password, you simply create them a new one,
> send that to them and ask them to change it again. You do not
> want to start messing with encryption unless it is a core feature
> of what you are trying to do (aka I am employed to develop an
> encryption application, it makes up 50% of what our app does, so
> I have to concentrate on it, otherwise I wouldn't).
>
> As an aside, you mentioned .htpasswd in another message.
> .htpasswd has the ability to store passwords in an encrypted
> format (MD5 hash or using the crypt() method), this may be the
> easiest method to use, aka let apache handle the whole thing.
> Most likely it is better than anything you (or I, that is a royal
> you) could write.
>
> http://httpd.apache.org/docs-2.0/programs/htpasswd.html
> (adjust for your version of apache)
>
> Some databases also provide a specific field for passwords that
> handles all of the crypting, and verifying for you automagically,
> check with your db docs if you are using one.
>
> http://danconia.org
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Here is a password implementation I use on *both*
Windows (W2K) and Linux (SuSE 8.1) with Perl 5.8.0.
When building my user/password file, I use crypt
as follows:
# $pswd1 is *plain text* gathered from STDIN ..
my $epswd = crypt ($pswd1,
join '',('.','/',0..9,'A'..'Z','a'..'z')[rand 64,rand 64]);
# $epswd is the encrypted password that is put into
# a user/password file
When validating the password (in my case the password is
gathered from from an incoming HTTP header):
# $cpswd is gathered from the user/password file created
# above
my $cpswd = $USERS->{$user};
# $pswd is gathered from the HTTP header and is *plain text*
# at this point
if (crypt ($pswd, $cpswd) eq $cpswd) {
$LOG->Log (Auth => "$user AUTHORIZED");
return 1;
}
# at this point the received password ($pswd) is invalid
Please notice that the user/password file contains only
*encrypted* passwords. The crypt documentation states that
it is impossible (well, nearly...) to extract plain text
from the encrypted password - so the user/password file
is secure. The password received from the user in the incoming
message is NOT secure in my case, because I currently use
the HTTP basic authorization scheme. I can (and may) fix this
by using HTTPS for protected pages with openssl.
Note that 'crypt' is portable; my application works on
Windows and Linux using the *same* user/password file.
I hope I have explained what I have done clearly.
Aloha => Beau.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
