2

Let's say I want to build an app in which I don't want to register or can't get an SSL certificate (whatever the reason).

I was wondering if it is possible to get security benefits of SSL by using RSA instead.

Im using the CrypticoJS library - https://github.com/wwwtyro/cryptico)

For example lets say when a user POSTS info to my App. I would do the following:

1) Have RSA private key on server, and give each client an RSA public Key.

2) On Client: Encrypt data with RSA PublicKey before POST, and POST Encrypted Data

3) On Server: Decrypt POST data with Private Key.

4) On server: Save Decrypted Data to DB

The goal is to prevent my user's sensitive info and passwords from being hacked. I know I wont get the green 'Trust' banner when people visit my app, but my User's security is a priority. Please let me know if this is possible. Thanks.

Meowzie
  • 21
  • 1
  • 2
    It would protect data being transferred from being sniffed, but a man-in-the-middle attack could modify your scripts to add code that also posts the data you are encrypting to another server. This would probably be a better question for [security.stackexchange.com](https://security.stackexchange.com/). – Alexander O'Mara Dec 28 '14 at 19:10
  • Thanks for your reply. To prevent man-in-the-middle, I would also use sessions that expire and set maximum of 1 session per logged in user/ip/country. – Meowzie Dec 28 '14 at 19:24
  • 2
    sessions won't protect against an automated man in the middle – Jasen Dec 28 '14 at 19:32
  • @Jasen So what might protect against MITM attacks besides sessions? – Meowzie Dec 29 '14 at 00:23
  • 1
    basically you need an SSL cert. They will get cheaper. https://letsencrypt.org/ – Jasen Dec 29 '14 at 04:33
  • 1
    StartSSL provides free SSL certificates that are widely accepted. If you really mean it when you say that your users' security is a priority, then you should be using SSL. – Iridium Dec 29 '14 at 16:35

1 Answers1

2

TLS/SSL provides many more security benefits than just data encryption (via RSA or other algorithm). To get a breakdown of how TLS/SSL works and the protections it provides, see this answer from a true expert: https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work/20847#20847.

Technically you could use a JavaScript crypto library to encrypt data on the client side using an RSA public key and submit it a server for decryption by the corresponding private key. A few of the many things you would also need to consider:

  • Unless you have a very small amount of data to encrypt, use of RSA for data encryption/decryption can be slow. TLS/SSL uses asymmetric algorithms like RSA for symmetric key encryption only resulting in far better performance than basic use of RSA for all encryption/decryption.

  • Without TLS/SSL your end users could not be assured that they were submitting their encrypted data to a trusted web server. For example if an attacker was to sit in the middle of the request (such as over public wifi) they could manipulate the responses sent from your website to change the RSA public key to use, as well as the URL to submit the encrypted data to. Your end users would likely not notice anything was wrong in this scenario.

  • Use of TLS/SSL comes with browser level protections that you cannot fully replicate using JavaScript alone. One example is web server trust. If there is no SSL certificate from a trusted certificate authority, your end users have very little guarantee that their sensitive data is being protected. On secure sites the browser will provide a padlock and/or green address bar as a visual indicator that data is being sent over a secured connection. If this is not present users need to trust that you have implemented an alternate secure mechanism. Even if you have (which is near impossible in my opinion), a user cannot be assured that a man-in-the-middle attack will not alter your implementation.

If as you say your users' security is a priority, I would strongly encourage you to consider use of TLS/SSL for your needs.

Community
  • 1
  • 1
Brice Williams
  • 588
  • 1
  • 4
  • 9