Authentication system

bastiaanolij

Hey guys,

I am new on this board and relatively new to PHP and web development. I have done a few things so far but still learning. Today I wrote a new user authentication module after learning some new things. I think it works pretty nicely but would like the opinion of more seasoned developers. I wrote a little explination document about it and put a simple test site online, hope I didn't overdo the explination, I tend to get carried away abit🙂. Check it out here:

http://www.basenlily.nl/login/howthisworks.htm

(hope my server holds up, its just a simple one I've got running for fun at home).

planetsim

Nice work on the Javascript had a quick view however it is also going to be your downfall.

Im sure you may be still quite new to the feild but Javascript shouldnt be used in any sort of user authentication or trusted at all.

You have encrypted the password from the client side (Javascript) now what is going to happen if i turn it off?

I suggest you also validate with PHP as well.

bastiaanolij

Hi planetsim,

If you turn javascript off, you simply can't log on. The password will be send clear text to the server, and the server will not understand and just tell you the password is wrong.

Remember, the javascript only creates the encrypted password, it does not do the validation! Validation is done server side.

Same if you turn off cookies btw, then the random generated number will be lost because the session ID will be lost (although that can be fixed by sending the session ID by another means).

pml

I think to use SSL is much better than any JSP on client side to send protected passwords from client to server.

planetsim

His not using JSP but JS and PHP. SSL is good but can still be spoofed no matter what people say. Also SSL isnt free + this is only a module.

bastiaanolij

SSL also has the 'downside' everything is encrypted, so not just your post data but also all the html being send back and forth. Waists alot of bandwidth that way.

Another approach I have been thinking about though is using a technique like PGP to send the data back and forth. So the server gives out a public key, the client encrypts the data is wants to send to the server with this public key and only the server can decrypt it using its private key. The public key is just send with every page load and the public key/private key combo is changed every now and then just in case (or maybe randomly selected from a stack of keys).

Using this approach it would be possible to encrypt all post data.

To make it completely safe you could also have the client generate an encryption key (in this case it doesn't have to be a public/private combi) that is send with the post data (and thus encrypted with the public key of the server) and let the server use that encryption key to encrypt the returned html page.

You could have php send the page like this:

<html>
... title stuff and includes for decrypter and code for retrieving encryption key stored in other frame etc. goes here
<body>
<script language=javascript>
doDecrypt("encrypted page data goes here");
</script>
</body>
</html>

All you need now is a compression algarith you run on your html data before you encrypt it and you'll even limit bandwidth🙂

mtimdog

Possible flaw:
What if said hacker intercepts encrytion key, then attempts to use key to login before the person can.

Most likely, the hacker can't get in (would have to guess user/pass), but the user couldn't as well. If you're logging possible hacks, you would log the user as he would be the 2nd person using that encryption key.

If the hacker set up a script to automatically do this, the user would be locked out indefinitely.

bastiaanolij

mtimdog,

I'm assuming you are reacting on the PGP security idea?

Actually, there is no problem in the hacker having the public encryption key, its public, everyone can know it. Thats the beauty of RSA encryption.

The point is, the public key can be used to encrypt all the data send by the client to the server but only the server can decrypt it. The public key can't decrypt the data, only the private key can do that and the private key is only known to the server.

The hacker can't do anything with the public key. It's the data being send that is important, the public key is just to ensure a 3rd person can't decrypt what is being send from client to server (namely the password). The public/private key combo being used could basically be used for ever, for each connection. A hacker can do a DOS attack by sending false passwords reusing the session ID and user name of a user logged on. But also that can be avoided. Just tell PHP not to send the session key by default but do session handling yourself (so not through a cookie), when the user brings up the login screen that user does not yet get a session, it isn't until the client sends the encrypted password + an encrypted random number when the session ID is assigned, the session ID is then send back to the client using the random number the client gave to the server to encrypt this value (normal encryption, not public/private key encryption). As the hacker will never ever see the random number, the password, or the session ID, he/she has no foothold to do a DOS.

mtimdog

When I said encryption key, I meant random number sent to client from server.

bastiaanolij

Hey mtimdog,

You're talking about the original idea I posted then right? If so you are right, the random generated number send by server to client is readable by a hacker and although he/she cant use that by itself to login to the system, he/she can use that in combination with the session ID to attempt a login causing the random number to be invalidated and the real user being logged out. This way the hacker can do a DOS attack. That is indeed a flaw. It denies access to the system by the hacker, but does pose a treat that can make it impossible for a normal user to do his/her thing.

Sorry, I was mixing up my original and my new idea🙂 With the public/private key approach this would not be possible. I'm going to work that out as soon as I have more time.

mtimdog

What if a random number is stored in a $_SESSION variable everytime login page is loaded. (upon reload, overwritten)

user submits form user/pass

upon submitting, js md5's the password

then js md5's (password+$-sessionvariable)

js submits form

php sends new pass to mysql which matches against
md5(password in db+$-sessionvariable)

btw, password in db is already md5ed

the person must have the $-sessionvariable defined, otherwise it fails.

It could also check the $_SERVER['HTTP_REFERER'] variable to make sure it came from the correct page. (not implemented)

This is similar to what I have working currently, but I also added in lockout after 3 wrong passwords for username(locks out ip, blocks username for 30 mins).

bastiaanolij

Hey mtimdog,

That works fine for the first login, but every subsequent page hit you no longer have the password to send. Unless if you save the password in a frame like I do in my example. The problem you then have is that the result of md5(md5(password)+sessionid) would be a constant value.

The session ID is send clear text on every page hit, so the hacker knows this value.
The result of md5(md5(password)+session id) is also send along with the data and thus known by the hacker.

The hacker simply needs to use my session ID + the hash the client has send to the server to mimic a login and voila, he is in, he just reuses my info..

That is why I introduce a random number I keep changing on every page hit.

You basically suggest the same thing, generate a random number when the login page is brought up, send that over, use that for the hash so the hash is different every time you login. That will stop the hacker from doing the same login request.

But what happens after the user logs in? You need a similar system for each time the user access your website. If every page hit the user does after he logs on simply uses the session id, or if every page hit you use the same hash as before, the hacker can simply mimic those fields and he is in. Thats why I make sure the data send needs to be different for each page hit and only the client knows how to make this data useable.

$_SERVER['HTTP_REFERER'] is a good way to determine if the page hit comes from the same location. If a hacker uses the session ID of an already logged in user you see this value changes and you can block him out.

But it is far from foul proof. The hacker will know this value for the real client and there are ways to fool your server into thinking the hacker has the same value. Also if the user is behind a NAT, firewall or a proxy, anybody behind that same "wall" can mimic being that client. It will only stop inexperienced hackers but any hacker with some real skills can work around this.

Weedpacket

Originally posted by bastiaanolij
$_SERVER['HTTP_REFERER'] is a good way to determine if the page hit comes from the same location. If a hacker uses the session ID of an already logged in user you see this value changes and you can block him out.

Um, that will change with every page visited (if it's sent at all).

Still, this is starting to look like "try to recreate SSL without the paying for identity authentication bit", and you have to start asking what it is that's so valuable that you want to go to so much convoluted effort to protect it, but not that valuable.

Like, is it worth anyone's time to bother sitting on someone else's line with a packet sniffer?

bastiaanolij

Weedpacket,

You are very correct, in many cases you have to wander if there is any reason to make a website that secure and still not go for SSL. I am working on one or two projects that security in this magnitude is needed and we always go https for those situations.

But this is more a private thing, its more for the fun then any commercial goals. I want to see if I can make something that works good only using freely available software.

Besides, there is some practical gain for me. I have two things against https in its current form.

1) its bandwidth intensive. All data is encrypted with public keys and decrypted with private keys on the other side. Its unbelievably inefficient and slow. PGPs method of only encrypting a 'normal' encryption key with the public key, then compressing the data and encrypting it with this encryption key is way more effective then SSL and just as safe.

2) I don't like the whole setup. I am only interested in creating a secure connection between client and server. I am not interested in creating certificates that concern more then just the safety of the connection for a high price. SSL is nice if you have a webshop and you want your users to know their credit card information is safely transmitted and there is a legal body backing you up on this sure. The user in this case may not know the company he/she is dealing with and these certificates give them some feeling of security they are not giving this data to a bogus company.

But I am in the business where the clients are just employees of my customer who only need a secure line to access there database without a third party (their competitors) snooping the data off the line. In these situations all this extra legal document signing isn't interesting. Sure I can use SSL with a invalidated certificate and that would secure my data nicely but that still does not solve the problem that all this data is send back and forth waisting bandwidth due to the inefficient way the data is encrypted.

Weedpacket

Inefficient in what way? Sure there is a query to a third party for an independent check of identity but the same goes for PGP, and encrypted streams themselves are not significantly larger (just now tried RC4/arcfour and a typical 12kB HTML file; the ciphertext was only ten bytes longer).

Of course, all these document signings are going on to prevent exactly the vulnerabilities that you're trying to avoid with your own working - that a given response actually does come from the claimed source (and hasn't been e.g., intercepted and read/altered en route). That's why those private and public keys are transferred back and forth (and validated independently). Of course you still have the opportunity of someone interposing themselves between yourself and the certification authority, but that won't be of any help to them unless they have the CA's private key that matches the public key in your keeping.

In short, it sounds like you want all the security of SSL without any of the functionality that makes SSL secure.

bastiaanolij

Weedpacker, the only thing the 3rd source adds is that they supply an authentication that can be trusted by a party that is unknown with the second party.

A client logs on to an unknown server (a new webshop), gets a certificate that is given out by a company like verisign and thus knows that the trusted company verisign has legal agreements with the unknown server making sure you can trust this webshop aswell.

It adds an added assurence there that I do not need. But it has little to do with the encryption scheme used, it is only an implementation of that encryption scheme to ensure the source is a trusted source.

Just look at VPN software that also uses the same encryption methods and is just as secure, but just uses internally created public key/private key combinations + an internally created certificate for security. The only game here is that a party in the middle can not decypher the data stream going from client to server. Which is the only thing I am trying to attempt.

Your example of a 3rd party going inbetween to do identity theft on the server side is nearly unstoppable. Client side identity theft can be stopped because in every secured page load you send along data that the hacker has never got access to. That data was generated by the client and added to the password information when logging on, it becomes the identity keyword for that session. Only if the hacker has access to the memory on the client he can do identity theft.

Server side is a whole different story. After I have logged on and then a hacker catches my datastream and tries to emulate the server he has a problem. He does not know the private key of my server and can thus not decypher the data I am sending and thus never give a proper usefull responce. The only point the hacker can give the client a problem is if he/she emulates the logon page. The client thinks he/she is accessing the logon page of the right server but instead is accessing a page build by the hacker. Types in username and password, and voila, the hacker has username and password. But NOTHING is going to stop that from happening. 99% of the users out there will be fooled by this easilly, SSL or not. If the page looks the same as the real page, a user will not notice the little SSL key in the bottom missing. It wont be easy, it depends a bit on how good the original website is and the trickery needed for the user not realising http is used and not https. As a hacker you want to avoid the message "you are going from a secured page to an unsecured page" sorta thing, which usually is easy because most logins are originally on a unsecure page. You go to http://www.paypal.com and only when you press the login thing you go https. So if I was to redirect www.paypal.com and mimic the front end and never go https, I can fool most of their userbase (I actually got a warning from paypal some months ago that people were sending out emails in their name that would send the user to a paypal copy page to do just that). Most users of websites are computer illiterate and will not realize they are on the wrong page and happely give up their user name and password.

Bottom line, I will never say the system I suggest is as good as SSL. SSL is MUCH better when you need tight security where identity of the server is proven by a 3rd party. I am only saying my idea can be usefull in those situations where people do not currently use SSL now but just some normal unsecure login schemes. Also it is just nice to experiment and learn, if there will never be a practical use, so be it🙂

Also, your example of 12kb, I was expecting it to be a bit larger but so be it. Possibly SSL does do some compression before encryption. With the idea I am proposing it could be brought down to something like 6kb, maybe even less. Text is unbelievably compressable. Also the algorith for public key encryption is more processor intensive then the algorith for normal key encryption, although that gain may be compromised by the loss of the compression routine.

mtimdog

I forgot to mention that that username is blocked until he/she logs out. So, said hacker that has sniffed the information can't use it anyway until logout.

At that time, the $SESSION is destroyed leaving (not that I know of) a way for hacker to recreate the exact same correct $SESSION (random) variable. I think PHP stores that on the server in temp files (but I could be wrong). Now, if he has access to the server, why am I worried about him logging in?? He's already beat ya!