I'm building a website and my payment methods will be Google Checkout and Paypal. There will be links/buttons which will redirect the user to the secure Google/Paypal sites for processing the payments. This means I do not need the $150/year added expense and complexity of installing SSL certificates for my site.
However I would like to encrypt user's passwords as they are logging in so that if they are on a network some malicious person running FireSheep etc can't read the user's actual password as it is being sent to the server. The rest of the site doesn't need encryption as it's not really sensitive data and would probably slow the user experience down significantly.
My thoughts are this could be implemented with public key cryptography. Lets say the process goes something like this:
Anyone know of an actual working solution for this? If not how about we write one then open source it. Unfortunately writing encryption/decryption code is pretty complex so I don't really know exactly what the existing libraries are doing and how to modify them to make it work. I already have protection for session fixation/hijacking so I'm not interested in that. Just interested in encrypting the data before it gets to the web server.
Also if you could refrain from posting comments like "just use SSL". I'd actually like a solution to this exact problem even if it's not best practice, it would be interesting none the less.
http://www.jcryption.org/ -- Is the combination you are looking for.
Only one problem: An attacker does not need to know the actual password. All he needs to see is the value that is sent to the server. This value allows the user to log in. It does not matter what that value is; whether it's plaintext, encrypted text or a picture of a cat. It's just a token that authenticates the user. If an attacker can see this token and repeat the same request and that same request allows him to log in, you gained nothing.
RSA is overkill; what you probably need is a simple challenge-response protocol. For example:
The weakness of this scheme is that the password hashes in the database are in some sense password-equivalent; while it's likely infeasible to extract the original password used to produce those hashes, knowledge of the stored hash is sufficient to impersonate the user on your site.
SSL certificates serve an entirely different purpose: the purpose of an SSL certificate is to make it difficult for a third-party rogue server to claim to be your server, because it doesn't have a certificate signed by some mutually trusted third party that it belongs on your domain. On the other hand, if you can't stop a rogue server from impersonating yours, you can't protect your users from giving their password to that rogue server, cryptography notwithstanding.
First, I don't think this is a good idea. I found some examples using Google that may be useful for you (I have not tested these, however):
You should establish some salting mechanism to salt every encrypted value otherwise the key could get compromised.
You don't need to encrypt the password. You need to hash the password. You really really don't want to have any access to the plaintext password yourself whatsoever, otherwise you lose non-repudiation, which has serious legal consequences. You need to investigate the meaning of this thoroughly before proceeeding.
This is the code to take the input and then encrypt the content by java script The entire code is also available in github.you guys can search for it encrypt_js_decrypt_php. The problem was running since long.I have come up with the solution.Just import it into localhost.
Now,lets decrypt the code in php
©2020 All rights reserved.