Re: Encryption Question
- From: "shimmyshack" <matt.farey@xxxxxxxxx>
- Date: 13 Mar 2007 16:37:53 -0700
On 13 Mar, 21:48, "egg...@xxxxxxxxx" <egg...@xxxxxxxxx> wrote:
On Mar 13, 2:21 pm, "shimmyshack" <matt.fa...@xxxxxxxxx> wrote:
On 13 Mar, 20:09, "egg...@xxxxxxxxx" <egg...@xxxxxxxxx> wrote:
I have a form where a user can change his password, but I'm confused
on how to prevent this from being transmitted in plain text.
Well, I know how not to transmit it in plain text - use any type of
encryption, but then the problem is, how do I decrypt it on the server
to store it?
If I use some type of key based encryption, the how do I get the key
to the client without it being intercepted, rendering the whole
process useless.
My question is, how can I set up secure password change functionality
on my site?
easy answer: SSL
not so easy answer: you will need a javascript implementation of
either
a) (not so good) symmetric enc/decryption algo.
b) (more secure) RSA encryption with decent key bit size, and will
need to encrypt as little as possible, because it is 100x slower than
(a)
Assuming (b)
1. get your public key as a javascript string and send to client,
holding back the private on the server.
2. tell your user "please wait" while you use the freely available
RSA.js to encrypt the password field and copy it to a field called
encrypted-password
3. blank the password field
4. send the form off
5. capture $_POST['encrypted-password'] and decrypt using your private
key on the server side
google for "RSA javascript implmentation"
So the key to getting the new password from the client to the server,
while being able to decrypt it on the server is RSA encryption?
I suppose it might be worth saying that in order for your SSL or
javascript based method to work in a truly secure fashion, you will
have to take steps to ensure your site is not vulnerable to XSS on any
page, and that it is protected from SQL injection, if these or other
vulnerabilities exist in your app layer, no amount of secure
transportation will help.
(most sites have some form of this I would say, so make sure yours
doesnt!)
For instance, you have a page which takes as one value the URL where
you were passed along in the URL to your "contact me if there was an
error with this page" where it is included in the body somewhere. With
a little modification it is possible to inject a piece of javascript
which calls a payload from another server. This payload rewrites the
page to add two further fields "login" and "password" so you can be
credited with bonus points or whatever for reporting the trouble, the
password is nicked and posting to attacker.com before posting the
correct data on to the right place.
This exact problem exists on an ISPs portal page that shall remain
nameless. I was told that due to "random seeding of our SSL sessions
the attack is not possible".
Lesson XSS gets transported and included into the SSL encrypted HTTP
session, so don;t regard any system as secure until the last remaining
vulnerability has been identified - however you do seem to have
security in mind which is great.
While David is right, SSL is best, in general there is a trade off
between getting creative when there are perfectly good tried and
tested open source security solutions out there already, and being
"satisfied" that just because you use one of them you are secure. In
this case javascript is secure provided you stick to a tight
implementation.
.
- References:
- Encryption Question
- From: eggie5@xxxxxxxxx
- Re: Encryption Question
- From: shimmyshack
- Re: Encryption Question
- From: eggie5@xxxxxxxxx
- Encryption Question
- Prev by Date: Re: interference from the previous page
- Next by Date: Re: interference from the previous page
- Previous by thread: Re: Encryption Question
- Next by thread: Re: Encryption Question
- Index(es):
Relevant Pages
|
Loading