[UPHPU] RE: Javascript form validation [was Re: Posting a form]

Jeffrey Moss jeff at opendbms.com
Fri Feb 25 12:32:20 MST 2005

It does a really good job. It emulates SSL encryption by sending a seed (the 
host key) to the client which gets hashed in with the plain text password 
they enter.  If it is a man in the middle attack and someone has it out for 
you you may be screwed, but the man in the middle would have to be running 
something that searched http headers for fields with "pass" in them or 
something. On top of that, he wouldn't know the password, he would only have 
a one-use pass key to send back to the server, because in order to log back 
in a new key has to be issued.

Its detailed here: http://pajhome.org.uk/crypt/md5/
and more specifically here: http://pajhome.org.uk/crypt/md5/chaplogin.html

I originally discovered the idea when someone mentioned why hotmail and 
yahoo allow you to log in using a non-ssl page. People can intercept your 
email messages still but they wont know what your password is.

Sure SSL is better, but that's not always an option.  I have a homegrown SSL 
certificate on my webmail site that says "warning! this site may not be who 
they say they are!" and most people would prefer no security over that.

But you're changing the subject Mac, I'm talking about how great javascript 
is, even for the simplest tasks. It is the ONLY way to get any sort of 
procedural code running reliably on the client. I wouldn't count on flash 
like I count on javascript.


----- Original Message ----- 
From: "Mac Newbold" <mac at macnewbold.com>
To: "Jeffrey Moss" <jeff at opendbms.com>
Cc: <uphpu at uphpu.org>
Sent: Friday, February 25, 2005 8:55 AM
Subject: Re: [UPHPU] RE: Javascript form validation [was Re: Posting a form]

> Yesterday at 7:59pm, Jeffrey Moss said:
>> Well that's what's clever about this _HASH_ scheme is the seed is unique 
>> for each request, sent by the server. Of course a certificate is better 
>> but in this case it offers a decent level of protection from http 
>> sniffers where none was previously available.
> That was half my point in the last message. It may _seem_ to offer some 
> protection, but it really offers very little protection at all when it 
> comes to keeping people from logging in who shouldn't be.
> Let's assume that the attacker can see all your traffic, and it's all in 
> the clear, since you're not using SSL.
> First, it means he can see all your source code. So he knows exactly what 
> algorithm you're using, and can duplicate it himself.
> Second, it means he can see any "magic numbers" that the server is sending 
> to the client.
> Third, it means he can see all the hashes and other values getting sent 
> back to the server.
> If you're not directly sending the password, then he won't see that, but 
> he will see all the values you compute with the password. He can't go 
> backwards from the md5, but he knows part of the plaintext that was used 
> in each of those computations. Even a clue like the length of the password 
> would be helpful in breaking it. And every transaction he sees is another 
> clue. It probably is a problem similar or equivalent to a "known 
> plaintext" attack.
> The other big problem about not using ssl is one of authentication. The 
> client has no way of knowing who they're talking to. If he can impersonate 
> the server (either via some form of phishing or by a man-in-the-middle 
> setup) he can not only _know_ the plaintext "seed" you send, but _choose_ 
> it, which lets him mount a "chosen plaintext" attack, which is more 
> effective. The whole reason that you get your SSL cert signed by someone 
> else that their browser trusts, is to verify that _you_ are the person 
> they intended to be talking to. You can use a self-signed cert if all you 
> need is the SSL encryption, but that's still vulnerable to 
> man-in-the-middle and other impersonation attacks.
> If he can impersonate the server, or be a man-in-the-middle, there's not 
> even anything stopping him from changing the javascript that gets sent so 
> that it sends him the password in the clear.
> The moral of the story is that for security protocols, it's almost always 
> a very bad idea to roll your own or come up with some new thing. At best, 
> you'll end up with "security by obscurity", which is no security at all. 
> And at worst, which is normally the case, you end up _thinking_ you have 
> some security, so you do stuff that you normally wouldn't be dumb enough 
> to do if you knew you didn't have any security.
> If you want to put the security to a test, tell us where it is, and a few 
> of us will do independant "security audits" on your site, and tell you how 
> long it takes to crack it. :)
> Mac
> --
> Mac Newbold MNE - Mac Newbold Enterprises, LLC
> mac at macnewbold.com http://www.macnewbold.com/ 

More information about the UPHPU mailing list