I am looking to do a three-pass exchange with CryptoJS (client) and OpenSSL (server). I can not find any examples on how to do this, could any one pint me in the right directions. I am looking to do the following:
Server sends client a string encrypted with a randomly generated key.
Client encrypts the string with another key, and sends it back to the server
Server decrypts the string using server's key from step 1 and sends it back to the client
Client decrypts the string with client's key from step 2. Client now has original string from the server.
This is for a small app I am making. I have used CryptoJS before, but I never had to do the three-pass before, and an example to work from would be very helpful. Thank you for any help.
Related
What would be the most secure way to do so?
So far I tried providing the same public key for every user which automatically encrypts the data sent over a https request to my backend.
For that reason, people with enough knowledge can get the json payload before its encrypted and encrypt it by themselves on their end and send it over my server.
The most ideal case would be so the client side only has access to the public key while the server can view both user's private key and public key.
I'm currently using RSA for this
Frameworks in use: VueJS and NestJS
The web browser belongs to the user. It is completely under their control. Anything you do in the browser can be inspected and manipulated by the user.
You can encrypt data during transmission to protect it from third-parties with HTTPS.
You can't make the user's browser compensate for you not trusting the user.
I am developing SPA in angular and the specific requirement from customer to use RSA 2048 for authentication. I am a bit skeptical how the authentication token would get generated. I believe the token would generate at the server side and it's server's responsibility to verify against the encrypted credentials.
Am I wrong in my thinking? Has anyone tried with 2048 RSA authentication earlier?
So this is how it will work,
Generated a public & private key using a salt key & 2048 bits.
Public key is kept within the source code to generate a cipher text.
Private key is kept on server to decrypt the cipher text.
Server will decrypt both the stored password ( already encrypted) with the login password ( encrypted).
If both decrypted cypher texts are equal , server will send the auth-key otherwise request is failed.
The company i work for has found a problem working on a new page, in sending new/modified users passwords when the account is saved to server side code from client side using jquery ajax.
At the moment, the password is sent in plaintext to a webmethod in which it is processed and then encrypted server side before being sent to the database.
My major fear is a sniffer catching the traffic in the middle and taking the plaintext password, pretty logical problem.
My company does not use SSL/HTTPS therefore im looking at other encryption methods.
The only person capable of changing passwords is the administrator, and the logged in user is capable of changing their own password. Therefore nobody else has access to that page without authentication.
Should i use a plaintext key in javascript with 3DES to send an encrypted password to server side and reduce the chances of a man in the middle attack,
Or should i use a public/private key system with RSA so that a generated public key is sent to clientside on post, that can only encrypt the data, and then server side containing the private key to decrypt the data when sent.
Obviously the user/ admin is always going to be able to debug and see their password in their webbrowser, but which is the better solution to prevent a man in the middle attack.
Ive read that rsa encryption can be quite hungry on resources to generate keys.
Thanks.
You could use RSA to generate a key pair, and issue the public key to the client. The client could encrypt it using a usefull jQuery plugin pidCrypt
Back on the server, you could decrypt the sensitive data with the private key. We are actually doing something similar for our ASP.NET Web API solution (in addition it running over HTTPS).
The following is a nice post by John Peterson showing how to do something similar and use RSA with Web API
Hth.
This is my demand:
User content is ultimately stored on the server side, but the preservation of data is encrypted
Server side, that is, site technical staff, can not have any way to decrypt the contents of the user, as the user's password as stored on the server side is a long list of md5 encrypted characters.
For encryption, we can temporarily consider only the text
The same as the password I want to process the data, but these data need to output to the user, so i have to decrypt the data on the client-side ,
what can i do ,
thanks
updated:
if i use javascript obfuscator on my javascript data , How much chance to be cracked by somebody .
Encrypt and decrypt on the client, never store key in the server side.
See jsencryption for an example of client side encryption.
If you use javascript obfuscator chances are high it might be cracked, obfuscation is not encryption.
You should hash the conten on the serverside using md5.
Can you be more clear and specific in the question?
Hey everyone, I am researching a project where we would need to keep a value encrypted from the client all the way to a black box system without decrypting it at any point in between. We are using SSL between the browser and web server, but the values are automatically decrypted at the web server, which is what we need to keep from happening. We need to be able to pass it through the web server (still encrypted) and through other back end systems until it hits its final destination where it would be decrypted.
So my question is what options are available to us for maintaining an encrypted state for a value from the browser back, without decrypting it anywhere along the way?
Thanks
Mark
Have you thought about doing a simple RSA encryption on the values and sending that through the system? You will need to make sure the clients have the public key in which to encrypt the data with, but that would be easy and secure enough to pass around.
To my knowlege, most libraries out there will support RSA. A nice demo of how to do it purely in Javascript can be found here.
you'll want to take a look at public key encryption. SSL protects your session (browser <-> server) but not the full transport. i'd suggest encrypting your data once it's received from the client, then sending the encrypted data all the way in.
here's a terrible diagram outlining the flow of data
client browser web server random server blackbox
route ---- SSL -------------><------------- not encrypted ------->
data *-------- PGP/GPG encrypted --------->
basically your data is encrypted via SSL to the web server, where it is PGP/GPG encrypted, then sent downstream. SSL doesn't matter at this point (or at least, isn't the primary form of encryption).
unless you can guarantee javascript in your environment, it may be better to encrypt at the web server to make sure your data is secure if the user has javascript off for some reason.
If you use a binary type in your database, the web server should send it as-is. Your client can then encrypt the data before inserting it, and would then have to decrypt the data after fetching it. Neither the web server nor the database server itself would be able to view the data.
The black box system, by definition, can't decrypt the data unless it was built to do that. I'll suggest discussing the problem with the developers of the black box system.