Maximum PC

I'm in the process of working on a new portion of a site for someone that deals with passwords and logins.

Now, when it comes time to perform the login functionality and verify the username and password, should I encrypt the password with PHP functions, and then send to the server (in the encrypted form) and do the comparison there?

I'm using PHP sessions, which I feel are quite safe for this functionality.

I'm using built-in PHP and MYSQL functions to encrypt and decrypt, but more or less want to know if it's safer to do it all (the decryption, comparison, etc) on the server via a PHP script.

How do most others handle this type of matter?

This isn't really my area of expertise, so I might be missing something important here, but how could you do authentication on the client machine without putting the entire username:password database in the page? Sure, the traffic could be encrypted, but this won't help prevent an attacker from decrypting and running a brute force attack on the entire set.

Also, I don't think that you can trust the response. Couldn't an attacker just send the server something back saying they're authenticated?

A few things about what you said are very worrisome.

First, when you're talking about encrypting passwords, then sending them to the server, that implies to me that you are storing the password in plain text, which is a very bad idea (if you are encrypting them in the database, it is slightly better, but still not ideal, since the key would still be stored on the server somewhere in plain text).

Second, PHP code is not executed on the client's machine, so even if you did encrypt the password with PHP, it would still be sent to you in plain text, which is bad.

What I would recommend, is that you store the hash of the password in the database (preferably a salted hash), then have the client (in javascript for example) hash the password and send the hash to the server over HTTPS (PHP sessions aren't encrypted), and then the server can compare the hashes together.

Note: I know more about the theory than the actual technologies, so I may have a few of the details wrong, but the overall concept is correct.

Depends, if your DB has hashing algorithms, use them instead. This way you can write one procedure that does authentication. Otherwise, use the PHP ones if MySQL doesn't support hashing.

No, you're quite incorrect. PHP's encryption function resides on the server itself. He's not storing the passwords as unencrypted text, however, he is sending it unencrypted via the wire (from the browser to the server). His best bet is to get SSL encryption on the domain itself (https://) so everytime he logs in, the request (and corresponding response) is hashed using the latest algorithms.



This is vague. When the client causes a POST in a form, the password is sent to the server unhashed. All HTTP traffic is insecure, if you want to secure traffic then use HTTPS (but you need to purchase an SSL license). This way, even if the user enters his password, the browser encrypts the request and sends it to the server encrypted.



That's one way of doing it. Sending it via an HTTPS session secures the unencrypted password over the wire by encrypted the request in itself.

I think there is a bit of confusion with our definitions. When I'm saying encryption, I'm meaning applying a key to some plain text to encrypt it, so that it can be decrypted at a later date (such as AES, RSA, HTTPS, etc). By hashing, I mean applying an algorithm on some plain text to encrypt it, so that it cannot be decrypted later, by anyone (such as MD5, SHA-1, SHA-256, etc; not HTTPS).

He was talking about two different things: encryption between the client and the server and encrypting/hashing the passwords in the database. You're correct that the PHP/MySQL functions will handle the encryption/hashing of the passwords in the database, but they will do nothing for encrypting the communication between the client and the server (he'll need HTTPS).


That's correct (he could use a self-signed certificate for free, but that is not as secure as one from a certificate authority - i.e. if you can afford one, buy it).


On further thought, I don't think the first hash is necessary (the one done on the client's machine), because if they can get that hash, they can get access to the account, and if they have your password, they can determine the hash.

If you are doing this in PHP....

You need to encrypt the password on the client side, using JavaScript. If you try to encrypt the password with PHP, it will need to be passed across the wire in clear text. This is a big no-no.

You should then save the encrypted value and ONLY compare the encrypted value stored with the encrypted value of the password being entered for log in. You should never be decrypting the password you have saved.

It really doesn't matter if either the password or the hash is sent in the clear (ie plaintext). In fact, the attacker wouldn't even need to know whether what is being sent is the password or the hash in order to compromise the account.


Maybe I'm missing something here, but I don't see how encrypting the password on the client side helps matters. How are you transmitting the key to the client in this case? The attacker would have full knowledge of your encryption scheme unless you use something like https, but then why would you need to encrypt on the client side using javascript?

Still better than xmitting in the clear, amirite?

That was what I was meaning to say.


Not by much, because you'd still be transmitting the key in the clear. Also, if the attacker was somehow unable to get the key, he could view the encrypted password and just send it to the server whenever he wanted to access the account, as Gadget was saying.

I haven't put my finger on it, but something is really bugging me about hashing client-side. I'm afraid you'd be giving an attacker additional information about the hashing function that they might be able to take advantage of. I don't really have the means to verify it, but I know that a recent man in the middle attack worked by simply sending people to the http equivalent of an https address. I'm wondering if an attacker can do something similar and perform a bruteforce/word-list attack using the hashing function and http address.

The way your sentence was phrased was weird. I mentioned to cbassett01 that it's best to use a hashing algorithm in the database. I know SQL Server and MySQL have such hashing algorithms. You made mention in your post about encrypting plain texts in the database. That sounded off to me; why encrypt when you can hash? Anyways, I re-read the parts and no, there's no confusion - just misunderstandings.



My point to him as well.


On further thought, I don't think the first hash is necessary (the one done on the client's machine), because if they can get that hash, they can get access to the account, and if they have your password, they can determine the hash.[/quote]

Getting the hash and knowing the pre-hashed values are two different things. SHA2 (and SHA3) have better mechanisms for collisions so it should be safe and sound to use client-side hashing. Honestly, another layer of security isn't a bad thing either. HTTPS + client-side hashing should make it difficult to break into the password (though at that point, I'd rather just exploit server side flaws like SQL Injections or whatnot).

Correct me if I'm wrong, but hashing algorithms don't have a key like an encryption algorithm would, right? Also, even if you could figure out the hash (and SHA2 is pretty much the defacto and I'm sure the source can be found and read anywhere), you'd still need to figure out the pre-hashed value.

Then again, a man-in-the-middle attack definitely is the better way to do it. If you can hijack the DNS or the web server and redirect them to your own page, then yeah, no amount of HTTPS traffic that will stop them from gaining access to your password.

I mean, either way, to be blunt... your fucked. Either xmit in the clear. Something has to be transmitted over the wire somewhere.

Correct. Some hash functions include a 'salt' to make techniques like rainbow tables, which can be used to store pre-computed passwords (even for 'secure' hash functions), more difficult. However, I still think using a hash function client-side could lead to unintended security issues. While most developers could implement a hash function, very few have the mathematical background to properly test one for correctness. They might believe their implementation is correct, but it could be the case that they've screwed up some small detail and compromised the function. While I can't think of any specific weaknesses offhand, it is pretty clear that a flawed implementation can compromise the normal browser security protocol, so why run the risk when there aren't any clear benefits.


Well, you're not supposed to be able to get into the middle with HTTPS. Even if you were able to exploit a flaw in DNS, the security certificate should prevent you from spoofing the login to the site. Also, IIRC, all the header info for all hops is encrypted separately, which should prevent you from fooling with the header info to include yourself in the loop.