Solved

Automatically encrypt a passwprd when

Posted on 2014-03-18
14
3,797 Views
Last Modified: 2014-03-26
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!
0
Comment
Question by:cesemj
  • 4
  • 3
  • 3
  • +3
14 Comments
 
LVL 82

Assisted Solution

by:Dave Baldwin
Dave Baldwin earned 125 total points
ID: 39938871
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.
0
 
LVL 13

Accepted Solution

by:
Daniel Helgenberger earned 125 total points
ID: 39938989
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:
http://enarion.net/programming/php/google-client-api/google-client-api-php/
0
 
LVL 108

Assisted Solution

by:Ray Paseur
Ray Paseur earned 125 total points
ID: 39939253
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).
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_2391-PHP-login-logout-and-easy-access-control.html

 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.
0
 

Author Comment

by:cesemj
ID: 39939495
THank you all, I am reviewing the articles you presented and will update.
0
 
LVL 34

Assisted Solution

by:gr8gonzo
gr8gonzo earned 125 total points
ID: 39939507
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.

http://blogs.cisco.com/security/breach-crime-and-blackhat/

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:

https://www.pidder.de/pidcrypt/?page=rsa

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.
0
 
LVL 34

Expert Comment

by:gr8gonzo
ID: 39939524
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.
0
 
LVL 13

Expert Comment

by:Daniel Helgenberger
ID: 39939566
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).
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:cesemj
ID: 39939680
Thanks for the information, I am reviewing and will update.
0
 
LVL 27

Expert Comment

by:serialband
ID: 39939731
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?
0
 
LVL 13

Expert Comment

by:Daniel Helgenberger
ID: 39940093
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.
0
 
LVL 27

Expert Comment

by:serialband
ID: 39940616
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
0
 
LVL 13

Expert Comment

by:Daniel Helgenberger
ID: 39940712
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.
0
 
LVL 27

Expert Comment

by:serialband
ID: 39940973
You may be right.  I only glanced through the articles back then.  I'll read them more carefully.
0
 

Author Closing Comment

by:cesemj
ID: 39956974
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.
0

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

Suggested Solutions

Part of the Global Positioning System A geocode (https://developers.google.com/maps/documentation/geocoding/) is the major subset of a GPS coordinate (http://en.wikipedia.org/wiki/Global_Positioning_System), the other parts being the altitude and t…
Nothing in an HTTP request can be trusted, including HTTP headers and form data.  A form token is a tool that can be used to guard against request forgeries (CSRF).  This article shows an improved approach to form tokens, making it more difficult to…
The viewer will learn how to dynamically set the form action using jQuery.
The viewer will learn the basics of jQuery including how to code hide show and toggles. Reference your jQuery libraries: (CODE) Include your new external js/jQuery file: (CODE) Write your first lines of code to setup your site for jQuery…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now