I am writing a program that uses a webserver as a backend for communication between different users. Is it okay to use my own encryption (such as http://www.logikdev.com/2010/11/01/encrypt-with-php-decrypt-with-java/) instead of purchasing an ssl certificate for communication between the program and the server?

In particular, can I hard-code a key into a publicly-distributed program or is there too great a risk of someone decompiling it to discover the security method and using it to snoop on other users' interactions with the server?

I can't imagine that typical users of the program will have access to any communication between the client and server, and someone that would have access to it probably wouldn't realize where the program is to start tinkering around with it, and it's not such highly sensitive data in the first place that someone would bother hacking into.

  • 6
    Your final paragraph has two assumptions which are regularly proven to be entirely false. Users always tinker. It is easy to analyse a programme to identify hardcoded values. Why would you not user https? – Rory Alsop Dec 14 '14 at 21:49
  • 2
    Is the purchase of a cert your only concern? What about free certs? Or a self-cert? – schroeder Dec 14 '14 at 21:53
  • 1
    As Schroeder says, self-signed certificates. You can't really use those effectively on the public web because they'll cause browser warning dialogs, but if I understand your question, you have an app (not a human with a browser) communicating with the web server. – Bob Brown Dec 14 '14 at 21:56
  • 1
    There are certification authorities which offer simple server certificates free of charge. Startssl ist trusted by all major browsers. – Hendrik Brummermann Dec 15 '14 at 8:49

No, it isn't safe because you expose (in your program) a key which should be secret.

Your proposal is based on symmetric key cryptography, where both ends of the communication channel need a copy of the same key. Symmetric key cryptography is effective only when both ends of the channel are secure. As others have pointed out, a key embedded in a program released to users isn't secure. TLS/HTTPS is built on public key (asymmetric) cryptography, where the information given to the client need not be secret. The secret – the private key corresponding to the public key in the certificate – is stored only on the server, where it is (relatively) easy to protect.

See the notes in the comments about potentially using a self-signed certificate. The value of a certificate from a certificate authority is that one can validate the signature on it. If you're setting up an app-to-server channel, you can validate your own certificate within your application, and in fact, "pin" the certificate so no other will be accepted.

| improve this answer | |

No, this is not a secure alternative. It is entirely possible that a hard-coded key could be discovered, which would leave you with application traffic that is essentially unencrypted.

So, if you feel the data is not sensitive enough to secure, don't bother encrypting it at all. Deliver it over HTTP. If, however, there is any reason to secure it, do it properly, and use HTTPS.

| improve this answer | |
  • It's an interesting question whether there's anything sensitive worth encrypting. Really my only concern is that user's passwords shouldn't be stolen because very often people use the same passwords for different sites. But maybe I should just provide each user with a generated password that they can't choose to avoid this problem. Anyways they only have to put in their password once on each computer that they install it. – clum Dec 15 '14 at 5:01
  • 1
    Users really really really dislike only having pre-generated passwords. That said, even if you go this route, you still haven't achieved any sort of security. Someone can still steal the generated password pretty easily, especially if you're sending the generated password via an insecure media like email. Like the others say, HTTPS is your friend here, and there are services that can provide free certificates. – Greg Dec 15 '14 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.