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

[Mac Newbold]

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/