January 3rd, 2014, 01:01 PM
How secure is this?
I'm trying to work out a reasonably secure scheme for sending user data through AJAX calls and have come up with the following.
1. User loads url
3. User enters text in a field
Any security experts out there who could shed light on this?
Thanks in advance.
January 3rd, 2014, 03:03 PM
do not invent your own security protocols. You cannot win. 99% of all homegrown protocols don't even make sense, and the rest is technically broken.
Unfortunately, your concept proves that yet again:
So I repeat: Don't invent your own security protocols, and don't implement your own cryptography. Always use established solutions which have been designed by actual cryptographers and reviewed by a large group of experts over a long period of time.
In your particular case, what you want is HTTPS. This is what you use when you want to secure the HTTP traffic between a client and your server (regardless of whether you use Ajax or classical requests).
January 3rd, 2014, 05:26 PM
After reading the "man-in-the-middle" page at Wikipedia, I can see your point, but in real world situations, isn't it pretty difficult to insert yourself into the middle? It's trivial to set up password protection on wireless routers these days and unless you're a network admin with a grudge at a cable provider, I don't see how you'd do it.
Originally Posted by Jacques1
HTTPS sounds like a good option, but if I'm not mistaken, internet service providers charge extra for that? Godaddy, for example charges $70/year for it...
January 3rd, 2014, 08:14 PM
The question is not how; the issue is that it is possible to get the data "hacked"/sniffed somehow.
Originally Posted by ktoz
The question is whether you want to have security that has been proved to work or not.
If you think the hosting provider is too expensive, you will always have to option to search for another hosting provider, with the features you want for a lower price.
Originally Posted by ktoz
You should also look at how sensitive the information is and what the cost will be by NOT using a secured connection.
What kind of information do you plan to transfer using AJAX?
January 3rd, 2014, 10:51 PM
Sorry, ktoz, but what you're saying doesn't make sense.
If the Internet traffic is not secure by default (which seems to be your original assumption), then your crypto cannot work. There's no way for the user to tell whether the key actually comes from you, which makes the whole encryption pointless.
The outcome is always: You haven't gained anything. Insecure traffic is just as insecure as it was before. And secure traffic is just as secure as it was before.
So the concept doesn't even make sense. When it comes to actually implementing this stuff, the security level will drop below zero, because it's simply not possible for a layman to get this right. The fact that you chose an asymmetric cipher already tells me that there are fundamental misunderstandings regarding the purpose and properties of asymmetric cryptography.
Claims like “I don't think this attack will happen in reality!” are also one of those famous last words. A man-in-the-middle attack is in fact trivial if the traffic runs through a proxy, or if people are forced to use an insecure network (like in a hotel). But even if it was not trivial: Who are you to decide that the risk for your users is neglectable?
Long story short: Stop it. If you want to play around with cryptography just for the fun of it, that's great. But don't even think about using it on a real website. Broken cryptography is worse than no cryptography, because it will give the users a false sense of security.
“HTTPS is expensive” is a myth, unfortunately a very common one. First of all, HTTPS itself doesn't cost anything. The only thing that may or may not be expensive is buying a certificate from a commercial certificate authority (CA). But nobody forces you to do that:
- You can issue your own certificate. This is actually the most secure solution, because it doesn't involve any third parties. But it requires the users to personally verify the correctness of the certificate. On big sites, that's obviously not an option.
- You can get a free certificate from CAcert. They even offer free extended validation. Unfortunately, CAcert isn't preinstalled in most browsers, so your users will have to do some additional work.
- Another well-known issuer of free certificates is StartCOM, and they're actually accepted by all common browsers. This might be the best solution
The only reason for choosing a commercial CA is if you trust it more than the ones above.
Either way, do use HTTPS. If you're sending any sensitive data whatsoever (which you obviously do), there's no way around it. But HTTPS should actually be the default for every website.
Last edited by Jacques1; January 4th, 2014 at 03:58 AM.
January 3rd, 2014, 11:45 PM
Account info. Stuff like user name, email, password etc. I may at some point want to include credit card info as well.
Originally Posted by MrFujin
January 4th, 2014, 04:43 AM
Um, did you actually plan to send credit card numbers over HTTP using your homegrown pseudo-encryption? This would be utterly irresponsible and would probably get you into legal trouble as well.
If you care just a tiny bit about your users or like to avoid getting sued, you need to secure your website. Note that storing credit card numbers will come with additional requirements, so make sure you get it right.
To be honest, I find it quite sad that we still have to lead this kind of discussion. I hope that some day using HTTPS for sensitive data will be beyond debate.