Page 1 of 2

paranoid authentication system :) Criticize needed.

Posted: Sat Aug 03, 2002 8:57 am
by Polar
Hi all !

We here still trying to make "hard to hack" PHP-Mysql authentication system :) So if somebody have time to read this stupid article
http://www.polar-lights.com/hackerhunter/
any comments will be greatly appreciated :)

Posted: Sat Aug 03, 2002 4:58 pm
by BDKR
I haven't yet gotten a chance to read all of it and won't until Monday afternoon, but it did address something that's been a concern of mine for some time. The fact that passwords with most system travel to the server unencrypted. I wrote a tutorial on encrypting client side that I sent to Jason at phpcomplete.com (I don't know if he's going to use it yet...) and I don't see why something like this isn't done more often.

Anyways, I think I'm going to print it out then read it sometime in the next couple of days. I like it so far.

Later on,
BDKR

Posted: Mon Aug 05, 2002 11:54 am
by Zmodem
Gah! I really wanted to read this article, but the link appears to be broken. Can you fix please?

Danke

Posted: Mon Aug 05, 2002 1:16 pm
by Polar
HI !

as i can see it from here, link is still alive :)

Posted: Mon Aug 05, 2002 1:30 pm
by Zmodem
Ok, works now.

I didn't get a chance to read all of it. I do think you have some good points, but think it is kind of unfair to critize Perl so much.

I also found it humerous in places..hehe

Yes, Perl can be a culprit sometimes, but I highly doubt 99% of all server breakins are due to poorly writen Perl scripts. And, we will only see that number decrease, with the increase of PHP scripts whose authors learned bad practices from the many poorly writen tutorials out there.

I have been working on an authentication system of my own, and would like your opinion of it:

**************************************
Usernames and Passwords are stored, MD5'd, in a SQL DB. When a user requests a protected page, this is what happens:

1) The server generates a random number, and sends that to the client.
2) The client prompts the user for proper credentials
3) The credentials, and the random number, are MD5'd throught the use of Javascript. This ensures that the MD5 operation happens on the client, and prevents the credentials from being transmitted in clear text.
4) The client sends the information back to the server.

The authentication is successful if TWO things happen:
a) The server compares the credentials the client sent it, to the credentials stored in the DB. If they match, the first part checks out OK
b) If the MD5 hash of the servers random number, matches that which the client sent it, then part 2 checks out ok.

Allow entry if, and only if, a and b check out.

Thoughts Polar...or anyone?

Posted: Mon Aug 05, 2002 3:27 pm
by Polar
Hi !

No :) I never critize Perl :) I just critize poorly writen Perl scripts :)
And i am sure, that perl | hole in OPEN is still main hackers food :) Even some billing servers standard scripts can be exploited using |, or most part of billing servers standard scripts... PHP have one great advantage - it always and internaly escape all strange symbols from get or post and if forget about uploading bugs in some latest releases, poorly writen PHP scripts look more secure :)

And about your system. I understand it right that in "a)" you just compare
received_variable (md5 crypted on client) with password inside database (where it is already md5 crypted)?
If yes and somebody will read your db (it is easy if it is not your own server (on hosting for example)), he will be able just md5() on client random munber received from server and send as plan text string found in database :) So there will be no need to know real password.

Posted: Mon Aug 05, 2002 3:38 pm
by Zmodem
The random number is generated by the server, and stored in a session. Hopefully, the session data is NOT stored in the web root ;)

The MD5 hashed number received from the client, must be the same MD5 hash that is stored in that session.

In order for authentication to be successfull, all three things have to match: username, pwd, AND random number.

Does that make more sense? Or does this still not work?

Posted: Mon Aug 05, 2002 3:59 pm
by Polar
Hi again !

I still curious - sorry :) Before sending MD5 hashed number to server, client must be able to operate with not MD5 hashed number ? So that number must be visible on client side. And lets say that i found in your database MD5 hashed password "098f6bcd4621d373cade4e832627b4f6". For using in standard web form with username and password fields, i'll have to bruteforce that "098f6bcd4621d373cade4e832627b4f6" string and find real password fast - because it is easy word "test" :) But if i'll find in database for example "5080c0e5853d5f5f2bcbc8f209abdc60" string, brute force will take years because it is MD5 hash of strong passwords "KF9gDrw". And in your system (if i understand everything right :) i can apply md5 on that random number (visible on client side) and send md5 hash of that number to server together with string "5080c0e5853d5f5f2bcbc8f209abdc60" without brute force or MD5 hashing it
Think that it is not so good :)

Posted: Mon Aug 05, 2002 6:56 pm
by lc
Good article Polar ;)

was very informative... and basicly confirms what I sorta figured out already. You do what you can without getting completely obsessive. You can spend a year securing a script and then one good hacker comes along and messes up your entire creation.

All we can do indeed is protect against those that want to do damage but don't take the time to really learn the tricks of the trade.

Posted: Tue Aug 06, 2002 8:37 am
by BDKR
Well, after having got a chance to read the article, one thing has me curious. There wasn't much info as to why he wants to use Flash over Javascript for client side encryption. Of course he takes the time to mention java, but what I'd like to see is a benchmark showing just how fast Flash can run through an md5 job compared to Javascript. I'll bet that Javascript is faster. Especailly on Mozilla based browsers.

Also, Javascript is allready installed in most browsers (I don't think Konqueror yet has a Javascript engine). And in as much as people can turn it off, the vast majority don't. That's why people are allways squawkin' about pop up ads! However, when you tell them that they need to use it, it's faster than downloading the flash engine.

Additionally, who cares if the hacker can see the code (if we are using JavaScript md5). Remeber that this is a one way hash. That's also why we should be doing something like sending along digital signatures or something else along those lines to ensure that the information returns from where it came. And not just that, but platform and OS information as well. At that rate, a hacker trying to listen for a password has to do it from the users keyboard as the unencrypted stuff never sees a network. His only other option would be to invade memory in use by the browser. In other words, he would have to have allready coopted the users computer.

But beyond that, everything else is pretty cool. The use of flash for ecrypting client side was my only contention.

Good show,
BDKR

Posted: Tue Aug 06, 2002 11:03 am
by Polar
HI !

Thanks for post BDKR :) And yes, i am sure that you are right about JS - it is faster and already installed in more browsers, but i always fight against "one way hash" cryptying on client-side. That principle absolutely have no future. Show me system with md5 on client side, and i'll say how it can be hacked :) On client side we can only use "reverse hash" to let server decrypt received data, and in that case easy access to code can and will help hackers to do harm. And now ask yourself how much people know and understand js, and how much heard about ASV3, can look inside FlashMX .swf and understand something harcoded ? :) So, Flash it is just one more paranoid protection step :)

Posted: Tue Aug 06, 2002 1:06 pm
by llimllib
But I think BDKR has a valid point in avoiding security through obscurity. If an attacker has the md5 hash of your password, and you chose a good password, it should be worthless to the attacker.
All the system designer has to do is make sure that when a user logs in, a random variable is concatenated to the md5 hash and then md5ed again and checked both client and server side.To forge this, an attacker would need control of the server to log in, at which point he would have no necessity of logging in.

On a side note, I would like to say that your article was excellent and well written. If you would like help cleaning up the grammar, drop me a pm or an email, and I'd be glad to help you out. More people need to really take security into account when designing web scripts.

Peace

Posted: Tue Aug 06, 2002 3:50 pm
by BDKR
Polar wrote:HI !

Thanks for post BDKR :) And yes, i am sure that you are right about JS - it is faster and already installed in more browsers, but i always fight against "one way hash" cryptying on client-side. That principle absolutely have no future. Show me system with md5 on client side, and i'll say how it can be hacked :) On client side we can only use "reverse hash" to let server decrypt received data, and in that case easy access to code can and will help hackers to do harm. And now ask yourself how much people know and understand js, and how much heard about ASV3, can look inside FlashMX .swf and understand something harcoded ? :) So, Flash it is just one more paranoid protection step :)
In regards to passwords, why would the server need to decrypt? This may be an issue or question of "how much information" we are talking about encrypting here. My commentary (and perhaps I should've said this at first) is aimed squarely at login / authentication systems. A password should never be stored on the server or in the data base in plain text. That said, why should it travel to the server in plain text? En route is when it's most likely to be captured no?

Now seeing the details of an md5 algorithm isn't going to help a hacker one bit! What he needs to see is the plain text password before it's run through that algorithm, unless he's the NSA :!: How many of us have the ability to brute force an md5 or sha1 hash in an amount of time that makes it worth our while? But when you get right down to it, how many different ways can you add up all the required integers to make 4?

2+2
1+3
3+1
1+1+1+1
0+4 (does this one really count?)

That's it right? That said, how many different ways are different languages going to pump out md5 hashes? The truth of the matter is that the answer to that question is useless. What's most important is that each of those limited ways kicks out a correct md5 hash. That's why PHP and Javascript will kick out the same hash of "Jango" for instance.

There is also the risk that if the hash is captured, the attacker simply bypasses whatever form you created for the login purpose. But I'm not going to go into it as limlib allready brought up a viable way of dealing with this issue.

So, unless the user while registering chooses a combination like "harley:beer" or something else that's ridiculous and simple, we've just traversed the first two levels that you wrote of and skidded to a halt at the elite level. But if there's something else I'm not seeing in all this, I'd love to know and understand it.

But once again, everything else is ace. Some of the things there are great ideas and well thought out. The stuff about detecting dis-repair reallly got my attention. My hat is off to you on that one amigo.

Later on,
BDKR

Posted: Tue Aug 06, 2002 4:19 pm
by Polar
Hi !

Thank you both for such words :) I just specialize in reparing and increasing security of already hacked servers, saw a lot of awful and inexplicable events and was always trying to trace all hacker's steps and pick out weak sides of protection :)
But i am still insist on this rule
"server always must be able to decode received passwords and compare
md5 of received password with string from DB"
my English is not good enough for real explaining why, but any system with not reverse hashing on client side always will be more weak (saying it again - show me such system and i'll say you how it can be hacked :)
And thanks again llimllib - grammar is a great problem here - everybody can read anything, but can hardly write and nearly can't speak English :) I'll ask for your help when that crazy DNS problems in our area will be solwed :)

Posted: Tue Aug 06, 2002 4:30 pm
by hob_goblin
he makes it sound like one could 'unencrypt' an md5 hash..