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.
Related
I'm building an Outlook Add-in (which is basically an iframe served in Microsoft Outlook client, be that Windows, Mac or browser). It's an internal company tool that sends data to our server. It uses React/JS/Node.
Our endpoints use basic authentication, so I need to pass a username/password with each request.
The problem is I would like to "remember" each user so they don't have to enter credentials every time the app loads up. I've figured I can use HTML5 localStorage to persist username/password values.
However I'm wondering how safe this is and suggestions for how to keep a copy of the password?
Maybe do a base64 encoding of 'username:password' (for Authorization HTTP header) and store that instead?
I think there's no safe way to store the password on the client side. However I have two recommendations.
Because you are using React you don't have lot's of page refreshes, you can ask for the password on each page refresh and store it as a variable (very safe).
If you want to store it, then do not use base64 encoding. Instead sign the password with jwt on the client and store the signing secret as a config variable then uglify the config file and minify it. This will make it very hard to find the secret.
A session key might be a good alternative. Instead of passing around the username/password pair, you can instead have the server create a session cookie to be used for authentication.
I'm not an expert on this, but here is one way I'd do it if I had to:
The client should generate two keys: A public and private key. Store these keys in sessionStorage (not localStorage).
When the client attempts to "authenticate" with a username/password, the username, password, and secret key, should be encrypted with the server's public key and sent to the server.
The server's public key can be stored in localStorage. Find a way to transmit this key to the client. Maybe an endpoint like /pub-token?
The server will decrypt this username/password and after validating the pair, store the client's secret key, and generate a session cookie, which is sent back to the client.
Now in subsequent requests, the client will encrypt any message being sent to the server using it's public key and the session cookie will accompany those requests.
The server will validate the session cookie, and decrypt messages sent by the client using the client's secret key.
On the server side, you can use a fast key-value store like redis or memcached to map the session key to a client's secret key.
When the server determines the session is "over", it will delete the session cookie and the client will need to generate a new key-pair again (or keep using the same one...).
I'm not sure if this flow fits the notion of a "session key", but I find this is more secure than simply having the server generate a key and using only that key as authentication.
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.
I just read about the Stanford Javascript Crypto Library (jsfiddle example) which supports SHA256, AES, and other standard encryption schemes entirely in javascript. The library seems very nifty, but I don't know of a reasonable use case for it.
As some questions have already pointed out, client side encryption is not a safe way to pass secure data to a server. HTTPS should be used instead. So, are there any projects that would benefit from or require client side encryption?
Use Case 1
How about local storage? You might want to store some data, but encrypt it so that other users of the computer cannot access it?
For example:
User connects to server over HTTPS.
Server authenticates user.
Server serves an encryption password specific to this user.
User does some stuff locally.
Some data is stored locally (encrypted with the password).
User wanders off
User comes back to site at later stage.
User connects over HTTPS.
Server authenticates user.
Server serves the user's encryption password.
Client-side JS uses encryption password to decrypt local data.
User does something or other locally with their now-decrypted, in-memory local data.
This could be useful in cases where you have a fat client, with lots of (sensitive) data that needs to be used across sessions, where serving the data from the server is infeasible due to size. I can't think of that many instances where this would apply...
It could also be useful in cases where the user of the application generates sensitive data and that data does not need to (or shouldn't) ever be sent to (or stored on) the server.
For an applied example, you could store the user's credit card details locally, encrypted and use JS to auto-enter it into a form. You could have done this by instead storing the data server side, and serving a pre-populated form that way, but with this approach you don't have to store their credit card details on the server (which in some countries, there are strict laws about). Obviously, it's debatable as to whether storing credit card details encrypted on the user's machine is more or less of a security risk than storing it server side.
There's quite probably a better applied example...
I don't know of any existing project which use this technique.
Use Case 2
How about for performance improvements over HTTPS, facilitated via password sharing?
For example:
User connects to server over HTTPS.
Server authenticates user.
Server serves an encryption password specific to this user.
Server then redirects to HTTP (which has much less of an overhead than HTTPS, and so will be much better in terms of performance).
Because both the server and the client have the encryption password (and that password was shared over a secure connection), they can now both send and receive securely encrypted sensitive data, without the overhead of encrypting / decrypting entire requests with HTTPS. This means that the server could serve a web page where only the sensitive parts of it are encrypted. The client could then decrypt the encrypted parts.
This use case is probably not all that worthwhile, because HTTPS generally has acceptable performance levels, but would help if you need to squeeze out a bit more speed.
Use Case 3
Host proof storage. You can encrypt data client side and then send it to the server. The server can store the data and share it, but without knowing the client's private key, it cannot decrypt it. This is thought to be the basis for services such as lastpass.
Like anything on the client, you can use obfuscation to make things more difficult for casual users to peek inside, but since the client would also need to have a copy of the decryptor there's nothing to stop the user from using the decryptor themselves either.
JavaScript is an insecure environment, period.
One use that comes to mind is host-proofing. That is where you want to store the data on the server or store and forward through the server but not give the server access to the data.
The client can encrypt the data prior to transmission to the server and keep the private key or at least the password for the private key locally.
I believe that this is the basis for services such as lastpass.
Some of the guys here are developing an application which incorporates some 'secure areas' accessible by logging in. In the past, the login form and subsequent 'secure' pages were all plain text transmitted over http, as it's an application that goes out for use on shared servers where there is little chance of being able to use SSL (think WordPress and the like). Most people just shrugged their shoulders as that's all they expected - it's hardly a national bank.
We are now thinking of writing the next version using a JavaScript front end, with the advantage of loading all the images & CSS once, then writing HTML into the DOM thereafter with extJS (or maybe jQuery). We'd like to encrypt user input at the client before being sent to the server, then decrypt server output at the browser before being rendered to HTML so as to introduce some sort of security for users. There are also gains to be had with reducing page loading times, as we're only sending gzipped JSON back and forth.
While playing around, we realised that the method we were looking at to encrypt the basic stuff also doubled up as an authentication mechanism for login in the first place.
For simplicity...:
The user connects to the login page over standard http, where the browser downloads the JavaScript package containing the hashing and encryption algorithms (SHA-256 and AES for example).
User enters username, password and secret into a login form.
The browser JavaScript sends a hash of username and password to the server via AJAX. The secret is only stored in JavaScript and is never sent across the internet.
The server looks up the hash and retrieves username and secret from the database.
The server sends a hash (same algorithm as the browser) of username and secret back to the browser.
The browser JavaScript creates a hash of username and secret and compares it to the hash sent back from the server.
If they are the same, the browser JavaScript encrypts response with secret and sends the message back to the server.
The server decrypts the message with secret to find the expected response and starts a new session.
Subsequent communications are encrypted and decrypted both ways with secret.
There seem to be a few advantages of this type of system, but are we right in thinking:
The user knows they are talking to their server if the server manages to create a hash of username and secret, proving the server knows and understands username and secret.
The server knows the user is genuine if they manage to encrypt response with secret, proving the user knows secret.
At no time is secret ever transmitted in plain text, or is it possible to determine secret from the hash.
A sniffer will only ever find out the 'secure' URL and detect compressed hashes and encryptions in the query string. If they send a request to to the URL that is malformed, no response is given. If they somehow manage to guess an appropriate request, they still have to be able to decrypt it.
It all seems quick enough as to be imperceptible to the user. Can anyone see through this, as we all just assumed we shouldn't be playing with JavaScript encryption!
Don't do this. Please use SSL/TLS. See Javascript Cryptography Considered Harmful.
If you can provide a single SSL site to deliver your JavaScript securely (to avoid the attack mentioned above), then you can use the opensource Forge library to provide cross-domain TLS connections to your other sites after generating self-signed certificates for them. The Forge library also provides other basic crypto stuff if you opt to go in a different direction. Forge has an XMLHttpRequest wrapper that is nearly all JavaScript, with a small piece that leverages Flash's socket API to enable cross-domain communication.
http://digitalbazaar.com/2010/07/20/javascript-tls-1/
https://github.com/digitalbazaar/forge
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.