Develop Reference

Client Server Encryption

I have Xamarin as my mobile client, node.js as my backend and MongoDB as database. I am trying to encrypt the user's data and save it in Database. If I do server encryption, still hackers can see the data while transmitting through APIs. Should I do client encryption, pass the data to API and store it in Database or should I do double layer encryption (i.e) Encrypting user data from client side, pass it through API, again do a server-side encryption and store it in Database. Basically, I wants to know how client server encryption works in real world.
The concern is that user's data is sensitive and needs protection even if the database is hacked.

There are several points where we can apply encryption, this is a bit confusing, but let me explain this to you part-by-part.
Database encryption
Your concern about the safety of sensitive data even if the server is hacked is justified. So, whatever sensitive information you have, you will need to encrypt. However, there are several ways to achieve encryption. To avoid overcomplication, I will speak about two types of encryption for this level:
one-way encryption
two-way encryption
The user's password is a data that is only interesting for the user in its raw form. So, you can apply one-way encryption, that is, given the password of the user you know how to encode it, so you store the encrypted version of the password and subsequently whenever the user logs in, validate his/her password by comparing the result of encrypting whatever he/she typed in vs. what is stored in the database. However, you should not be able to decrypt the encrypted password, because passwords need a single direction anyway, that looks like:
user types the value
which is sent to the server
which receives it
and encrypts the raw password
and then compares the encrypted version of the received password with the encrypted password that is stored
The other way to encrypt data at this level is a two-way encryption, that is, an encryption method that you can actually decrypt. You need to use this approach for any data that you may need in raw form for some reason, like showing it to the user.
Server encryption of data sent to the user
If your project owner is worried about the safety of your user's device/application (like the vulnerability of browsers using unsafe extensions or users visiting strange sites with their browser), then some data sent to the user can be encrypted. Avoid this unless you are specifically needing to perform such an act.
Client encryption of data sent to the server
If the communication channel is unsafe, then you might need to apply some encryption on client-side before sending the values to the server.
Good news! HTTPS!
HTTP stands for HyperText Transmit Protocol. Its HTTPS version is already encoding the messages, it stands for HyperText Transmit Protocol Secure. If you are already using HTTPS as a protocol, then your client-side requests are already encrypted, so a third-party listening to the requests you are sending will receive some gibberish of data at request send and response receive events.
Summary
If you are not asked for further encryptions, then you should use HTTPS and one-way-encoding of passwords on your database, because this is the real-world approach in general. If you need to perform further safety-measures either because you have further sensitive user information or some genuine worry about some aspect of the project, or just a requirement, then you can extend this approach with whatever else you need. But HTTPS and one-way encoding the password on database level is an absolute must.

Best way to store private crypto key in browser?

I would like to encrypt some user data before it's sent to the server. That is, the data will be encrypted on the client side in browser using JavaScript.
My question is, what options are available for storing private keys on the client side (it will be used for decrypting the data when user views it later on)?
HTML5 local storage or just reading local text file containing the key from JavaScript seems a bit off...
Is it possible to use personal certificates for this purpose? Or is there any other option?
EDIT:
Slight clarification,
All the sensitive data that needs to be encrypted is generated on the client machine and it should never leave it in plain-text. The data in question is mostly files which user will upload to the server, however we might want to encrypt some form fields as well in the future.
Once the encrypted data is sent to server it is stored in ciphered form and will never be decrypted anywhere else other than the same client machine. For example if the user decides to download his files back, he will receive encrypted files which will be decrypted in browser using JavaScript.
Also it's crucial for us that the Public-Private key pair is generated on the same client machine. This will be done only once manually by the user or with the help of some automated solution.
Bottom line is, private key nor plain-text data should ever leave client's machine.

According to your description the data in files and form fields should only ever be used on the client. There is simply no need to use public-key-encryption in this case. You should use a symmetric block cipher like AES to encrypt this data and send it to the server. The single random symmetric key will be generated in the client browser and stored in localStorage possibly protected by a password (e.g. second layer of AES). The AES key is 128/192/256-bit long binary string and it should never leave the client browser.
I think localStorage is the only viable option, because it is implemented by all modern browsers.
There may be other solutions like browser plugins or even a custom browser, though.

RSA over Jquery Ajax

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.

ASP.NET form's data encryption without SSL

Normally, if I complete a form, the data will be sent to the server as raw plain text which could be read by sniffers.
I want to encrypt form's data client-side (like username, password,...) and then send them to the server.
It seems that there are two ways:
1- Using SSL (in my scenarion, I can't use)
2- Using custom ActiveX control.
3- Using server side dynamic javascript encryption function.
Which one is better or any other solution?

If you can't use SSL, which is the only sane option here IMHO, you must use client-side public key encryption with javascript, because symmetric encryption would require a key exchange over an insecure channel, which kind of defeats the purpose.
I haven't tried it myself, but I found this library for doing RSA encryption in javascript.

Server-side encryption won't work, because it wouldn't solve the problem (plaintext data being transmitted from the client to the server). What you would need is a javascript implementation of an asymmetrical encryption algorithm. Something like RSA. The server can provide the client with the public key, which would be used to encrypt the form data before it's sent, and then can use the private key to decrypt the data after it's been received.

How to encrypt a value on the client and pass it through a web server without decrypting it

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.