1

A client need to be authenticated by the server, so it need to send credentials. The credentials can be stored in a client database as in encrypted form. Since the server's certificate is known, in order to provide best security the client can use the public key of the server to encrypt the password. But the problem is now how to send the password without double encryption.

For example, suppose the server's authentication URL is "https://example.com/a?u=user&p=password", so the client have to send the SSL-encrypted data of this string to the server. Since the client stores only the encrypted password, it must find a way to send ssl_encrypt("https://example.com/a?u=user&p=")+pre_encrypted_password as a whole to the server.

The client is using WinHTTP api, so are there any way to achieve this?

Earth Engine
  • 10,048
  • 5
  • 48
  • 78
  • 1
    Good answer, but I would like to point out that there is one motivation for preencrypting the password even though the result is password-equivalent: in case the same password is used for different servwrs. Since the original password is not known anymore, one cannot learn it and try it on other sites. This is similar to precalculating the static HA1 in digest authentication and then "forgetting" the original inputs (username, realm, password). – Celada May 29 '13 at 01:33
  • @Celada I think you should comment on the answer, not the question ;) – Earth Engine May 29 '13 at 02:11
  • @Celada Anyway you are just saying exactly what I am trying to achieve. Ideally I hoped to do this without changing the existing server code. But it looks like due to the SSL facts it cannot be done so. – Earth Engine May 29 '13 at 02:18
  • oops, you're right, I meant to comment on the answer. Sorry! – Celada May 29 '13 at 05:59
  • You're using HTTPS, which already does all that for you. The URL will be encrypted by HTTPS. You don't have to do anything about it yourself. – user207421 May 28 '13 at 23:55

2 Answers2

4

No. SSL does not work that way - data sent over an SSL connection is encrypted using a symmetric cryptographic algorithm (usually AES, RC4, or similar), using a key that is established during the initial SSL handshake. The public/private key of the server are only used during the initial handshake; after that, they are not used.

Anyways, storing the password this way does not make it any more secure. If it's stored in an encrypted form that can be sent to the server, anyone who managed to get it would be able to use it that way; that encrypted form is password-equivalent, so it's no better than just storing the password!

0

Potentially you can save the certificate sent by the server (assuming that this certificate has RSA key which allows encryption), then use it in PKCS#7 encryption of your data, and send the encrypted data to the server. There's another question that appears - does the server-side code have access to the certificate. This is not the case in many configurations. So the server won't be able to decrypt the data.

Also, as pointed by EJP, this does not make much sense as you will be double-encrypting the data with merely the same key (technically keys will be different but the added security level will be minimal).

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • The additional protection is for client site local hacking prevention, not for network traffic or "man in middle" attack. – Earth Engine May 29 '13 at 06:15