Automatically encrypt a passwprd when

Platform: PHP


I have a php web app that allows a user to login using their user name and password.  When the user enters their password the password field displays asterisks instead of clear text characters.  When the user clicks the login button the password is transmitted in clear text even though the website uses an SSL certificate. The password entered is encrypted and stored in a mysql db table named login.

Is there a way to encrypt and transmit the password when a user logs into the website. Is there a plugin that I can use to encrypt the password client-side.  The concern is what happens when if SSL fails

I have been reviewing a couple of articles over the internet: and a section in one article:

Article reference
   However, one way to do this in a semi-secure way (it is easily crackable, but atleast you won´t send the password as-is over http):

    Upon submitting the form, have a client-side javascript alter the entered password with some kind of function. Then have a php-script reverse the altered password, and then check it with the password in the database.

    Entered password:
    client-side altered password:
    2345 (every char incresed with 1)

    2345 is being passed as clear-text over insecure http-connection.

    php-script reads the variable and decreases every char with 1; password is again:

    php verifies if the decoded password match the password in the mysql-db. This can be done in several ways, the easiest being to have a field "password" in the user-table which contains the users password in clear-text. However, security won't be high unless you make sure that only localhost can connect to the db and check your grants.

    To make this a bit more secure you could always make the encryption (increasing every char with 1) a little more difficult arithmetic operation. But as long as you use javascript to encode the password, anyone will be able to figure out how the encryption is done and decode it.

    Maybe freebsd should look at the differences between clear-text and as-is.

****************Article Reference End***************

Please share any articles you may know of - I am open to suggestions!
Who is Participating?
Daniel HelgenbergerConnect With a Mentor Commented:
I agree with Dave.

Transmitting passwords in clear over TLS is very common. Almost every mail server does this. This not ideal but easier to secure because you have control over the server, not the client.
The concern is what happens if SSL fails
SSL cannot fail, it can only be compromised by a man in the middle attack. These are not very common because they are hard to achieve and in most cases only work for one connection at a time.
More common are database thefts. You should use a strong hash algorithm as soon as the server application receives the password and validate it against a hashed stored password.

If you want to add another security layer in your application, add a two factor auth, for instance with Google Authenticator. This is IMHO the most widespread API in use:
Dave BaldwinConnect With a Mentor Fixer of ProblemsCommented:
If you are entering your password on a page that is loaded using 'https' and it is posted to a page using 'https', then it is encrypted in transmission.  It is not sent 'in the clear'.

Client side javascript is totally exposed to anyone who looks at the code for the page.  There really isn't any useful form of encryption available by using javascript in the browser because any one can read the code.
Ray PaseurConnect With a Mentor Commented:
concern is what happens when if SSL fails
In the current science, that is not really a problem. The problem is more likely that your programming and storage strategies can be compromised in ways that will reveal users' passwords.  If you're running on a shared server you already have one foot in the grave, etc.

Please see the part about An Afterword: About Storing Passwords in this article for a better understanding of this many-layered issue (it goes through the end of the article; cf #10).

 You will want to read the linked articles, too.  The man pages about PHP Security are important, as well.  Membership in OWASP may be helpful.

Ultimately all questions of security are boiled down to "what am I trying to protect" and "how long do I have to protect it."  Bowling scores, medical records, financial transactions and nuclear launch codes all take different security measures.
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

cesemjAuthor Commented:
THank you all, I am reviewing the articles you presented and will update.
gr8gonzoConnect With a Mentor ConsultantCommented:
I agree with most of the stuff said here, although I wouldn't go as far as to say that "SSL cannot fail, it can only be compromised by a man in the middle attack." You never know what the future will bring, and we've seen a lot of SSL-related attacks recently.

Tools like sslstrip only make it easier for malicious users (though to be fair, a lot of that technology relies on stealing data from a network you're already on, so it's not as targeted as simply intercepting all data to a specific site).

While SSL still relies on public/private key encryption, the methodology is still considered the safest crypto approach today (at least available to us normal folk), and there have been Javascript implementations of public/private key RSA encryption, like this one:

With this, you could use a separate public key to perform a 2nd layer of encryption on the password (or even the entire data set), and have the server decrypt the data with the corresponding private key. If the SSL transport layer is compromised in any way, you'll still have another layer using a separate certificate set.

It's probably overkill, but for certain situations, that's what is needed.

Aside from answering the original question, follow the advice provided by the others. You're far more likely to end up with an application vulnerability that compromises data than to fall victim to a MITM attack.
One last thing - disregard what the article suggested about incrementing password chars by 1.

THE golden rule of crypto is NEVER ROLL YOUR OWN. It means never try to make up your own algorithm of encryption/decryption. If someone is determined enough to attack your site specifically and compromise SSL, then a simple second algorithm is not going to be make one ounce of difference.

Also, never store passwords in clear-text in the database. Store a hash like a SHA-1 hash of the password and compare the hash of the password that is sent against the hash in the database. Trust me - storing passwords in clear-text (or in any decryptable way) is a bad idea.
Daniel HelgenbergerCommented:
Gr8gonzo, of course I meant with 'it cannot fail' that TLS cannot suddenly crash and you have  an unencrypted connection. But I suppose this was to bold and simple.

But nevertheless, TLS with ecliptic curve DH can be considered reasonable secure for the foreseeable future.
As always in encryption it is a question how economical a decryption for an attacker might be.

As I said in my post and agree with you about the storage and the the own code used being the critical point here (thanks for pointing out the article, Ray).
cesemjAuthor Commented:
Thanks for the information, I am reviewing and will update.
I thought that elliptic curve Diffie-Huffman was considered compromised or back-doored by the NSA.  Wasn't that the concern recently with the RSA conference and several noted security researchers boycotting it?
Daniel HelgenbergerCommented:
I thought that elliptic curve Diffie-Huffman was considered compromised

serialband, I am not so much into security news and this was new to me. But all I could find was about Dual_EC_DRBG; which is a random number generator. Though used with some EC-DH implementations by RSA, it does not compromise the technology as such. Can you provide sources?
Thanks and sorry for off topic.
Unless you're talking about a different elliptical curve encryption,  here's 2 articles about elliptical curve cryptography from last year pointing to a possible back door.
Daniel HelgenbergerCommented:
Ok, thanks! I still fail to see how this effects elliptic curve ephemeral Diffie-Hellman perfect forward secrecy in general. Though one critical thing in EC DH is the random number generator, you are perfectly fine if you do not use Rsa's DRBG.  (EC_DHDSA for instance.)
I looked through the cypher settings in my web servers - and none uses Dual_EC_DRBG.
You may be right.  I only glanced through the articles back then.  I'll read them more carefully.
cesemjAuthor Commented:
Thank you all for the information. It was a lot of reading but it was worth it.  Your conversations have opened the door to exploring new development methods using various encryption methods.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.