cesemj
asked on
Automatically encrypt a passwprd when
Platform: PHP
hi,
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: http://stackoverflow.com/questions/3087095/encrypted-user-credentials-when-they-are-transmitted 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.
Eg:
Entered password:
1234
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:
1234
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!
hi,
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: http://stackoverflow.com/questions/3087095/encrypted-user-credentials-when-they-are-transmitted 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.
Eg:
Entered password:
1234
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:
1234
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!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
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).
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).
ASKER
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?
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.
http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/
http://www.networkworld.com/news/2013/080213-black-hat-elliptical-curve-cryptography-272476.html
http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/
http://www.networkworld.com/news/2013/080213-black-hat-elliptical-curve-cryptography-272476.html
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.
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.
ASKER
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.
ASKER