Raible Designs

« OGNL 2.6.4 Released | Main | Carpal Tunnel »

Monday March 22, 2004

Password encryption with JavaScript This morning, I found some scripts to do MD4, MD5 and SHA encryption with JavaScript. If I add these to AppFuse and Roller, it means that a user's password will never be sent in plain-text. Very nice - anyone using any of these scripts? Any reason I should use someone else's scripts instead of the ones I found? Posted in Java at Mar 22 2004, 06:32:02 AM MST 7 Comments

Comments:

So how does this add to security? Instead of sending a plain-text password in plain-text, you send an md5-string in plaintext. Anyone can just as easily capture that and use it as a token to gain authorization. Unless, of course, all was done via SSL, but then your password would already be protected more than enough. I don't use https for my blog, neither, it seems, do you? (I came to a Redhat test-page at https://raibledesigns.com) So I honestly don't see the point, except that you can say you used md5 and making more guillable people use no security at all.

Posted by Niklas on March 22, 2004 at 08:41 AM MST #

Niklas - you make a good point. I guess the only thing that would buy you added security would be to use challenge hash authentication - but good luck in getting that to work with J2EE's container managed authentication.

I agree that SSL is the best solution, and I have SSL-for-login-only as part of AppFuse, but not part of Roller. Maybe I should add it. As for SSL on this site, I should probably buy a certificate for my domain (InstantSSL has good deals). Maybe I'll do that as part of the move to my new hosting provider.

Posted by Matt Raible on March 22, 2004 at 09:01 AM MST #

I think I'd have to agree - it doesn't really add any security but through obscurity, does it? Shadowed (ie. hashed) passwords are good for when you store passwords in a database, it means that even if someone gets read access on your database they don't know what the user's password is (unless they can invert the hash function!). Where does extra security come from if you hash passwords client-side?

Roberto

Posted by Roberto on March 22, 2004 at 09:02 AM MST #

I'm doing a university paper this trimester. The online 'get your lecture notes and stuff' application uses something similar

Here it is

Posted by Koz on March 22, 2004 at 02:53 PM MST #

Looked at this a couple of months ago - the challenge for the client is to return a server-generated sessionID with a hash containing the sessionID, username and password. Here's a PERL-implementation. Seemed to me like a nice SSL-alternative, however it's a bit clumsey to encrypt complete pages with this (is possible), and changing your password is not possible

Posted by G3rt on March 22, 2004 at 04:31 PM MST #

LiveJournal uses the challenge hash scheme IIRC. One of the problems is that a login will fail if the challenge has expired (if you wait too long to post the form). I remember reading a good discussion on it, but couldn't find it. Here's another one.

Posted by James A. Hillyerd on March 22, 2004 at 06:05 PM MST #

Sorry I'm a little late joining this discussion, but I use both SSL and the MD5/SHA Javascript. Why? So that the user's password isn't just secure while crossing the wire (via SSL), it's also secure once it gets to the server. There's no possibility that some server-side process will see the unencryped passwords once they've arrived and log them or email them to somebody. The advantage to this is that if somebody gets hold of the plain-text hash, at least that won't reveal the user's password to other systems if they happen to use the same password for them.

Posted by Kelzer on April 02, 2004 at 03:06 PM MST #

Sun	Mon	Tue	Wed	Thu	Fri	Sat
« May 2012
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Today

Search This Site

Recent Entries

Tag Cloud

Navigation