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.
Related
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.
Is there any solution for secure user registration and authentication without SSL?
With "secure" I mean safe from passive eavesdropping, not from man-in-the-middle (I'm aware that only SSL with signed certificate will reach this degree of security).
The registration (password setup, i.e. exchanging of pre-shared keys) must be also secured without SSL (this will be the hardest part I guess).
I prefer established and well tested solution. If possible, I don't want to reinvent the wheel and make up my own cryptographic protocols.
Thanks in advance.
For logging in you could try SRP from clipperz:
I'm not sure how strong the random number generator they use is. You might want to try and use the Crypto API to get stronger values. I'm not sure how you can get secure seed values in javascript without using Crypto API.
For sending initial password to server you could use public key encryption. So the server sends the client its public key (ok under the no mitm assumption) and the client encrypts the whole registration request when registering. Cipperz has support for public key encryption but in a very raw form. Often you use public key encryption to encrypt a randomly generated symmetric key and use the symmetric key to encrypt the payload. You have to be quite careful with padding/etc to make public encryption properly secure. I don't know of any robust public key crypto libraries for javascript.
You may want to check out jsbn for public key encryption because it looks like it does padding correctly. Though, I suspect it suffers from insecure random number generation. It would be a good idea to use Crypto API or make the user bang the keyboard to generate some entropy. Snippet from rng.js
// For best results, put code like
// <body onClick='rng_seed_time();' onKeyPress='rng_seed_time();'>
// in your main HTML document.
I am searching for a way to clientside decode RSA respectively openssl encoded messages.
Idea:
Special data is only stored encrypted with a public key on the server so that nobody is able to see the real data - even in case of server hacks.
An admin in the adminforce then can "open" these files by transfering them to the browser and some javascript code will decode the data so that it'll never decrypted on the server, only on the secure clientside.
I really need it to be decoded direclty in the browser with custom javascript because these data has then to be used by some algorithms clientside in js.
Problem:
There seems to be no openssl library in javascript or i didn't find one yet. While there are several pure js implementation of RSA they only implement the plain RSA algorithm but, plain RSA is not secure to be used as a block cipher and has some attacks like "choosen plaintext attacks".
Does anybody know of an javascript implementation of openssl decoding, or a plugin for firefox/chrome which adds these features to the document? Or any other secure asymetric encryption that's built into javascript?
As I was pointing out in a comment to your question, the vector of attack you're envisaging (compromised server) implies that the JavaScript is likely to be compromised too, in which case the JavaScript code running on the client shouldn't be trusted anyway. (It would be quite easy to make the JavaScript send the deciphered data back to the server with an asynchronous request in the background: again, since the server would be under the attacker's control, there wouldn't be any need for tricks to circumvent same-origin policies there.)
I would suggest going down the route of a standalone application (such as Java WebStart), perhaps signed (with a private key that's not held on the server).
If you're still willing to go ahead with this sort of architecture, avoid releasing the user's private key into the JavaScript at all cost. This could compromise the user's private key, not just the encrypted data.
When you use a private key in your browser for SSL/TLS client-certificate authentication, the private key isn't exposed to any code used by the server. It's used by the browser for the handshake, and the server gets the certificate (which is public), but the private key doesn't go anywhere near what the HTML+JS code can see. (In fact, in OSX with Safari, the private key is used by the underlying SSL/TLS library, and not even exposed to the user process.)
The JavaScript libraries for RSA that I've seen require direct use of the private key, that is, they need to be able to use the private exponent directly. That's clearly not good if you're in a situation you can't trust the server.
Being able to use a private key within the browser for RSA operations, without letting the script get hold of the private material itself would require tighter integration with the browser, in particular, some API to sign and decipher that would use these functions directly in the browser's security mechanism, without exposing the private key material (overall, a similar approach to what PKCS#11 offers to applications using it).
As far as I'm aware, the current Mozilla crypto JavaScript API doesn't provide functions to decipher/sign using the browsers (it's only for certificate request and key generation). There seems to be plans to do this, though:
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
http://mozilla.ddahl.com/domcrypt/demos/demo.html
On the IE plaform, CAPICOM should have been of interest, but it seems to be deprecated nowadays.
Encrpytion is complex and expensive - particularly assymetric encrpytion (in most cases the assymetric encryption is only used to encrypt a randomly generated symmetric algorithm key).
There are implementations of RSA (and probably other asymmetric algorithms in javascript) and in some cases, compatible implementations in other languages (usually C) - try google for specifics - but I'm not aware of any which handles x509 encryption. OTOH writing a java applet to do this would be trivial.
But why bother? From my understanding of what you've written, you'd get just as much functionality for a lot less effort by using a symmetric algorithm and never sending the key back to the server:
allow the user to enter some data in a web page
allow the user to enter an encryption key
encrypt the data using the key
send the encrypted data back to the server
provide a decryption page where the user can retrieve the encrypted content and enter the key
decrypt the contents
Instead of relying on web server to send you both the encrypted data & the associated JavaScript code to decrypt the data (which could be corrupted in case of a compromised server), you could only download the data from the web server & decrypt it with a standalone application or a webpage with JavaScript that does NOT come from the same webserver (could be from another server or a local file). This way there wouldn't be any responses returned to the originating server or the attacker.
The data kept on the server could be encrypted with a key that only you know about and can decrypt (AES or RSA), and server could only be for storage. For decryption, download data to a trusted local machine first, so you only you will have access to unencrypted data, of course for a very limited amount of time.
Check out this native implementation of TLS in JavaScript.
Here's a guide to enable Windows Subsystem for Linux in Win 10 to install
Bash, which comes with SSL. Check your version & get the latest.
think about this. if there is a server hack, the hacker will have access to your encrypted data and to all your site source code. including the one used to decrypt the data. and it can get those from the website interface in plain javascript by looking at the source of the page.
Does anyone know how to encrypt in javascript (maybe with sjcl?), post to a webapp and decrypt with java?
I wish to intercept some of a form data, encrypt it and then post to my spring application. ? already use jasypt PBEWITHSHA256AND128BITAES-CBC-BC algorithm for database encryption.
Any client-based symmetric encryption algorithm is likely going to be hackable since the code and keys is all sitting right there in the web page.
Wouldn't it be better to just use https to deliver the data to your server (the transport will be encrypted by https) and then do whatever final encryption you want on the server before storing it or passing to your spring application?
Answering my own question: I've found the precious jCrypting javascript library (based on jquery) and developed a spring integration (https://gitorious.org/jcryptingspring)
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.