Password Decryption using RSA

Hi ,

My use case is , i am exposing my LDAP as service to the internal teams for there authentication process. I am using secure connection , user wants to encrypt the password field and send the request to Apigee , can you suggest if there is a way to decrypt and validate the password ?

Thanks

Solved Solved
0 2 909
1 ACCEPTED SOLUTION

Sure, you can have the client encrypt things and send them to Apigee Edge.

But let's get a one thing clear, first.

If you are using a secure (https) connection between the client and Apigee Edge, then the payload, the URL, the headers... are already all encrypted. They are encrypted using TLS, using the servers certificate. So anything the client sends, including the password, will travel over this encrypted channel.

You said "user wants to encrypt the password field". what problem are you solving? why is TLS not sufficient security?

----

you *could* layer application-level encryption on top of the TLS (transport-level) encryption. One simple way to do it would be to use symmetric encryption, using a shared secret. What shared secret is common to the client app and Apigee Edge? The client secret, of course.

The client could encrypt using AES256 with the client_secret as the key. Then transmit the ciphertext to Apigee over https. (Effectively double-encryption, or two levels of encryption). and then, after Apigee Edge decrypts the HTTP packets at the TLS layer, your Apigee Edge proxy could decrypt the actual payload using the known client secret. There is a Java callout that can help here.

But you asked about RSA encryption. To make that happen I think you need a public/private key pair, provisioned for each client. The private key would be known only to the server, and the public key to everyone and anyone. You could attach the private key as a custom attribute to the developer app (client) inside the Apigee Edge store. The client could encrypt with the public key, then Apigee would decrypt with the private key.

Actually, it's a little more involved than that. Crypto with RSA limits the maximum size of the plaintext and cipher text, so you'd generate a random secretkey (just a set of random bytes), and use that as a key for AES. then, the output (cipher) stream from encryption would include the secretkey encrypted with RSA, followed by the plaintext encrypted with AES.

And the decryption just is the reverse.

View solution in original post

2 REPLIES 2

Please have a look here it contains a similar question. Hope it helps!

Sure, you can have the client encrypt things and send them to Apigee Edge.

But let's get a one thing clear, first.

If you are using a secure (https) connection between the client and Apigee Edge, then the payload, the URL, the headers... are already all encrypted. They are encrypted using TLS, using the servers certificate. So anything the client sends, including the password, will travel over this encrypted channel.

You said "user wants to encrypt the password field". what problem are you solving? why is TLS not sufficient security?

----

you *could* layer application-level encryption on top of the TLS (transport-level) encryption. One simple way to do it would be to use symmetric encryption, using a shared secret. What shared secret is common to the client app and Apigee Edge? The client secret, of course.

The client could encrypt using AES256 with the client_secret as the key. Then transmit the ciphertext to Apigee over https. (Effectively double-encryption, or two levels of encryption). and then, after Apigee Edge decrypts the HTTP packets at the TLS layer, your Apigee Edge proxy could decrypt the actual payload using the known client secret. There is a Java callout that can help here.

But you asked about RSA encryption. To make that happen I think you need a public/private key pair, provisioned for each client. The private key would be known only to the server, and the public key to everyone and anyone. You could attach the private key as a custom attribute to the developer app (client) inside the Apigee Edge store. The client could encrypt with the public key, then Apigee would decrypt with the private key.

Actually, it's a little more involved than that. Crypto with RSA limits the maximum size of the plaintext and cipher text, so you'd generate a random secretkey (just a set of random bytes), and use that as a key for AES. then, the output (cipher) stream from encryption would include the secretkey encrypted with RSA, followed by the plaintext encrypted with AES.

And the decryption just is the reverse.