Re: LoginMD5.pm (Perl/CGI - Javascript User Authentication)

John,

Maybe I should have cut and pasted my entire description into the email from my web site,
this is the basic algorithm from http://perl-md5-login.sourceforge.net/ :

Hash-based authentication methods work via a challenge-response mechanism. The server sends a random challenge. The client
combines the random challenge with the password, and computes a one-way hash. The client sends the hash to the server, which
performs the same computation. If the client's supplied hash matches the servers computed hash, the authentication succeeds.

This is the entire web page description:

Perl/Javascript MD5 Secure User Authentication

This project implements an MD5-based encryption scheme on both client and server machines to allow encrypted password
protection for web-based Perl/CGI applications. Although there are many free Perl/CGI application for password protection,
only a few use MD5 on the server-side, but the password still travels over the internet as plain text. All server-side only
schemes (like .htaccess password protection) are completely open to packet-sniffing. With this scheme, the browser
JavaScript encrypts the password on the client's machine, and session tracking allows only one response per session ID,
making simple packet-sniffing and session replaying much more difficult.

Paul Johnson wrote the JavaScript MD5 code, and released it under the GPL license. Without this contribution, and the
guidance of his web site this project would not be possible. The CGI code on his site didn't really create a useable
framework, so this is my contribution.

This is a one-way encryption scheme: the password is never transmitted or stored as clear text on the client or server, and
thus cannot be recovered. It now uses cookies to maintain the user session.

Session authentication verifies that the login page was created by the server and the user response is within 30 seconds of
the login page request. The login response hash is the MD5-encrypted user name/password hash combined with the unique
session ID, ie, it's unique and it can't simply be re-presented to the server for authorization. The latest release supports
file-level locking of the session database; this ensures that only one valid session response is possible.

How This Application Works

Hash-based authentication methods work via a challenge-response mechanism. The server sends a random challenge. The client
combines the random challenge with the password, and computes a one-way hash. The client sends the hash to the server, which
performs the same computation. If the client's supplied hash matches the servers computed hash, the authentication succeeds.

1) The adminstrator adds a user name and password to the user database on the
server via the shell utility addUser.pl. The name/password are saved as an
MD5 encrypted hash. The theory behind MD5 is that it would be very difficult to
determine the originating strings for any given hash. The hash is a unique
signature, but doesn't reveal the original password.

2) The remote user accesses the main program via their browser.

3) During this initial request, the server looks at the browser cookies; if the
user has already been authenticated, they will have cookies set (with a duration
of 24 hours by default). If a cookie exists for the application, then it's value
will be tested against the hashed name/password for that user name. If this test
passes, the user is allowed access without further intervention. Otherwise, the
client will be shown the login screen.

4) The server-side request for the login screen will create a new session ID value
and add it to the session database, also storing the time of the request.

5) When the remote user submits a name/password, the client-side javascript then:
    a) MD5 encrypts their user name and password.
    b) MD5 encrypts the user/password hash with with the session ID value.
    c) Returns the session ID and the encrypted user/password/sessionID hash
       to the server.

6) The server authenticates the user if:
    a) The session ID returned is a valid open session and
    b) The session ID was requested less than 30 seconds ago and
    c) The user/password hash stored on the server, hashed with the sessionID,
       matches the response from the remote client. Note that the response hash
       is unique because it combines the user/password hash (which is constant)
       and the sessionID string (which is always different). Only one response
       is allowed for each sessionID, so replaying the response hash to gain
       authentication doesn't work.

7) If the authentication fails a failure message is returned to the remote client
browser.

8) If the authentication is successful, the HTTP header will pass a cookie to the
remote client browser, allowing them access for 24 hours (by default). Note that
because of this, the set cookie string could be theoretically stolen by packet
sniffing and used as a bypass to the authentication process.

I'm not a security expert by any means, and so I'm not qualified to say exactly how safe/unsafe this scheme is. Judge for
yourself, I'd be curious to hear what you think.

Note that this module does NOT provide security agains eavesdropping or hijacking. A positive identification can be followed
by an attacker stealing the connection. This scheme is also open to a man-in-the-middle type attack. Also, the cookie itself
could be sniffed, which allows an authentication bypass. So my summary is that this is not SSL strength solution, but it's
better than using .htaccess or other methods that transmit the name/password information as plain text.

I don't have time to work on this code right now, so hack away if you have any other ideas to improve it. Another thing that
would be cool: an email-based admin approval scheme for new users. The major flaw in this scheme right now is the safety of
the cookie; ideally, the cookie hash should be related to the IP address, but this approach has it's own problems.

This application was intended to be an easy drop-in password protection scheme for Perl/CGI applications. It could easily be
updated to use other encryption methods (if both are available as Perl and Javascript). In it's current form, it is a
working code framework, but it doesn't have all the nice features of a some password login applications (new user signup,
admin screens, etc).

 <end of web page>

Hope that helps,

-alan

----- Original Message -----
From: John Francis <[email protected]>
To: Alan Raetz <[email protected]>
Cc: <[email protected]>
Sent: Saturday, August 24, 2002 11:01 PM
Subject: Re: LoginMD5.pm (Perl/CGI - Javascript User Authentication)


> Alan,
>      Just a quick note, MD5 is a secure hash algorithm, not an encryption
> algorithm. MD5 produces a 128 bit secure hash output of the input{s},
> unless you can explain your protocol a bit more I will have to assume
> that there a flaw in your application.
> - John
>
> On Sat, 24 Aug 2002, Alan Raetz wrote:
>
> > Hi,
> >
> > I created a module for Perl/CGI script user authentication that uses MD5 encryption
> > on both the client browser (using Javascript) and on the server (using Digest::MD5) and
> > I wanted to solicit comments and get any feedback from the group.
> >
> > http://perl-md5-login.sourceforge.net/
> >
> > http://sourceforge.net/projects/perl-md5-login/
> >
> > I'm definitely not a security expert, this was just something I needed for my own
> > project that I decided to make open-source, it seemed like something other
> > people could use...
> >
> > The additional feature that I have working but haven't released is tying the cookie
> > to the IP address; a user can move around, but each session is tied to the cookie hash.
> > But I know this is just an environment variable that can also be hacked...
> >
> > One thing I'm wondering if is if this could possibly be a candidate for CPAN...
> >
> > comments?
> >
> > -alan
> >
> >
> >
> >
>
>
>