views:

120

answers:

2

say i have strings that are sent back and forth from the client, and server via AJAX.

however i wish to securely encrypt it before being sent via the client. once it's on the server, it should be decrypted, and processed.

additionally, how does password encrypting work ? user signs up, and upon entering password, its encrypted on the server, and stored on the database. what about when user logs in? is the user password being encrypted again and being matched against the one in the database?

+9  A: 

An asymmetric algorithm could be used like so:

  1. The server generates a pair of private/public keys
  2. Client asks server (via AJAX) its public key
  3. Client encrypts data with the public key
  4. Client sends encrypted data to server
  5. Server uses private key to decrypt data

All these things have already been implemented and tested, so why reinvent the wheel and not directly use HTTPS? This will guarantee you that any exchange between client and server will be encrypted.

Darin Dimitrov
+1 for HTTPS. that is the correct solution.
rmeador
Although this use of the Public/Private key pair is effectively used to share a short message (typically a symmetric encryption key, or a simple password), the bulk of the encrypted exchange in https is done with symmetric encryption.
mjv
Absolutely, symmetric algorithm should be used for larger data payloads.
Darin Dimitrov
It is also highly likely that there are defenses built into SSL that you will not even think of when rolling your own encryption scheme. If the experts have already built something that is secure enough, I wouldn't even think of trying to build my own. There are just too many obscure and complex attacks that can be made.
Glenn Condron
+1  A: 

On the login question

There are many ways passwords can be used. The most direct (but less secure) is where the password itself is sent, in the clear, to the server. Other approaches still require the password to be sent but it is encrypted, for example with the server's public key. Other approaches involve an authentication challenge, whereby the server sends a random value/string which the client converts thorugh a hash function of sorts (involving the password as a key, of course), the result of the conversion is sent to the server which compares it with its own computation of the same process. The advantage of using a challenge is that it prevents man-in-the-middle attacks, since the authentication message is different each time (whereby a fixed message would allow the "man in the middle" to replay a recorded sequence of packets associated with the password passing, and hence falsely identify itself)

On the [badly worded] main question ("only being able to be decoded on the computer it resides on"...)

There exists several physical devices (dongles and such) as well as intrinsic identity indicators on a given computer (MAC addresses), along with logical constructs/contents on the hard disk (although we're getting in the "soft", i.e. more easily portable area here...), which can be used to identify a given host and thence supply the necessary elements (keys and such) to decode a message.

However, I believe this question was more generic:

It is possible for two computers to share, secretly, a key which they can use to exchange information that other computers could not decrypt (easily). These keys can either be put in place externally, or be negociated on the fly of each new session, using, initially, public key encryption for example as the Diffie-Hellman key exchange

mjv