archive or MD5

[So...@aol.com]

Can anyone direct me to the archives for this list  or could the gentleman 
who posted the MD5 example last week in response to password cookie, please 
repost. Thanks, Jake

Re: archive or MD5

[Damien Serra <da...@telcel.net.ve>]

Soch88@aol.com wrote:

> Can anyone direct me to the archives for this list  or could the gentleman
> who posted the MD5 example last week in response to password cookie, please
> repost. Thanks, Jake
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Quoted from my inbox.
Is this one (the example)?


> Subject:
>          Re: password cookie
>      Date:
>          Thu, 24 Aug 2000 22:47:29 -0400 (EDT)
>     From:
>          Ethan Adams
>  Reply-To:
>          general@jakarta.apache.org
>       To:
>          general@jakarta.apache.org
>
>
>
>
> The following is a Java method to MD5 encrypt using the java.security.*
> package
>
> static public String md5Encrypt(String toEncrypt) {
>     StringBuffer hexString = new StringBuffer("");
>
>     MessageDigest algorithm = null;
>     try {
>         algorithm = MessageDigest.getInstance("MD5");
>     }
>     catch(Exception e) {
>        return "failed";
>     }
>     algorithm.reset();
>     algorithm.update(toEncrypt.getBytes());
>
>     byte hash[] = algorithm.digest();
>     for (int i = 0; i < hash.length; i++) {
>         if((0xFF & hash[i]) < 0x10) {
>            hexString.append("0" + Integer.toHexString(0xFF & hash[i]));
>         }
>         else {
>            hexString.append(Integer.toHexString(0xFF & hash[i]));
>         }
>     }
>     return hexString.toString();
> }
>
> Hope this helps.
>
> On Thu, 24 Aug 2000, Doug Bateman wrote:
>
> > How cookies are actually formatted when saved to disk is browser specific.
> > I believe IE's format includes a checksum, so simply editing the file with
> > notepad creates an invalid record and IE discards it.  But there are cookie
> > editing tools out there that do allow you to properly edit cookies.  So
> > changing the username to fake the credentials of another user is still
> > possible.
> >
> > To prevent this type of attack, you need to store something in the cookie
> > that would be impossible for an attacker to guess, like the secret
> > pass-token mentioned in prior e-mails.  It doesn't matter what this token is
> > as long as: (a) It's different for every user (so I that can't use my token
> > to get into your account) and (b) It's impossible for an attacker to
> > generate or guess on his own (ie simply Base64 encoding the username would
> > be a bad choice, since a hacker could do that too.)
> >
> > Randomly generating a passtoken and storing it along with the username and
> > password in the database satisfies the requirements above.  The attacker has
> > know way of learning the random string without accessing either the client
> > machine's cookie or the server's database.  (One exception, if the attacker
> > can tap into the client or servers network link, he can listen to the
> > conversation and learn the secret pass token.  SSL (https) is designed to
> > block this type of attack by encrypting all communication between browser
> > and server.)
> >
> > Now you asked, why can't everyone just use the same passtoken, ie "let
> > pass".  Well, now the attacker can visit the site, create an account in his
> > name, learn the generic passtoken, and now all user accounts are accessable
> > to him by editing his cookie to now represent the victems username with
> > token "let pass".  Yes, with IE I do have to use a cookie editing tool since
> > editing with notepad breaks the checksum.  But that's really not a problem
> > since such tools are available and easily manufactured.
> >
> > You are quite correct to complain that the idea of generating a unquie
> > random passtoken for each user does require a trip to the database to
> > authenticate a user.  This is an unfortunate disadvantage of the
> > implementation I proposed.  However, I point out the same problem applied to
> > the original suggestion of storing the password (or hashed version thereof)
> > in the cookie.  I really like David Koblas's recommendation for an
> > alternative means of generating the passtoken without requiring it to be a
> > random string stored in the database.  It's simply a matter of deciding how
> > important avoiding an extra trip to the database is versus the work involved
> > using the MD5 algorithm in your code (may not be that bad if you can find a
> > free MD5 implementation on the web).
> >
> > I also like David Bock's suggestion of storing an MD5 version of the
> > password in the server database instead of the password.  This is how most
> > unix operating systsems store the system password information.  With this
> > approach if the db is compromised, the password still isn't.  On the flip
> > side, you can't e-mail a user his password if he forgets it since it's no
> > longer in the db.  Not to bad though since instead you can simply set the
> > password to a new value, e-mail it to him, and store the MD5 of the new
> > password in the DB in place of the old one.  Not a bad solution really.  Of
> > course, this approach still requires that extra trip to the db to compare
> > the MD5 has of the user's password with the MD5 hash value stored in the DB.
> >
> > Doug
> >
> > ----- Original Message -----
> > From:
> > To:
> > Sent: Thursday, August 24, 2000 12:31 PM
> > Subject: Re: password cookie
> >
> >
> > > I had questions about what is written on the bottom. What is the
> > significance
> > > of making the pass token random? Do you have to store that token also on
> > the
> > > DB to verify that it is associated with that particular user? Can you just
> > > have a cookie saying something static like "let pass"? In my experimenting
> > I
> > > found if some imposter tried to copy and paste someone else's userID into
> > the
> > > their (the imposter's cookie) , when both user's passwords are the same,
> > the
> > > server does does not accept the cookie and does not allow the imposter to
> > log
> > > in as the other person.  So just wondering why this pass token needs to be
> > > random and why cant it be some thing static. Thanks
> > >
> > > In a message dated 8/23/00 12:13:51 PM Eastern Daylight Time,
> > doug@techie.net
> > > writes:
> > >
> > > << Lucky for us, there's a nice solution providing the same automatic
> > login
> > >  functionality without requiring the password be persisted on the users
> > >  machine as a cookie (encryped or no).  The solution is to introduce a
> > >  second, server-generated random "pass token" which the user is unaware
> > of,
> > >  and store that as a cookie.  When the user next visits the site, the
> > cookie
> > >  is recognized as being the pass-token for the user.  Now the server can
> > send
> > >  the user a login page with the password field prepopulated from the
> > database
> > >  with the real value, or the server could even skip the login page all
> > >  together as the user has already been recognized.  Yes, the security of
> > this
> > >  system is still equal to that of the security of the cookie file on the
> > >  client, but atleast this way if the cookie is compromised, the original
> > >  password itself is still safe. >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>