#1
  1. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Apr 2003
    Posts
    573
    Rep Power
    70

    How secure is this?


    Hi

    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
    2. PHP script embeds a dynamically generated public key in a predefined javascript variable and returns the page.
    3. User enters text in a field
    4. Javascript function encrypts field text using public key and sends AJAX request back to server.

    I've never really bothered with security before, so I have no idea whether this would be secure or not. If the primary weakness in Javascript is when info is sent back and forth using AJAX, then the above seems like it should work, but I really don't know.

    Any security experts out there who could shed light on this?

    Thanks in advance.
  2. #2
  3. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Hi,

    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:

    OK, so you send your public key to the user. What prevents me from jumping in and simply replacing the key with my own so that I can read the data? This is a classical man-in-the-middle attack. The only way you could stop me is by establishing a secure connection first. But when there already is a secure connection, the whole JavaScript magic is pointless.

    As you can see, the concept doesn't even make sense. And if you consider to write your own JavaScript crypto algorithm, things will get even worse. In fact, many experts think that the whole idea of JavaScript cryptography is plain nonsense.

    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).
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Apr 2003
    Posts
    573
    Rep Power
    70
    Originally Posted by Jacques1
    Hi,

    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:

    OK, so you send your public key to the user. What prevents me from jumping in and simply replacing the key with my own so that I can read the data? This is a classical man-in-the-middle attack. The only way you could stop me is by establishing a secure connection first. But when there already is a secure connection, the whole JavaScript magic is pointless.

    As you can see, the concept doesn't even make sense. And if you consider to write your own JavaScript crypto algorithm, things will get even worse. In fact, many experts think that the whole idea of JavaScript cryptography is plain nonsense.

    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).
    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.

    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...
  6. #4
  7. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,632
    Rep Power
    1945
    Originally Posted by ktoz
    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.
    The question is not how; the issue is that it is possible to get the data "hacked"/sniffed somehow.

    The question is whether you want to have security that has been proved to work or not.

    Originally Posted by ktoz
    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...
    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.

    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?
  8. #5
  9. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Sorry, ktoz, but what you're saying doesn't make sense.

    If you think that sending plaintext through the Internet is perfectly secure, then what the hell do you need your JavaScript crypto for? There's no risk it would protect against.

    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 02:58 AM.
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Apr 2003
    Posts
    573
    Rep Power
    70
    Originally Posted by MrFujin
    What kind of information do you plan to transfer using AJAX?
    Account info. Stuff like user name, email, password etc. I may at some point want to include credit card info as well.
  12. #7
  13. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    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.
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

IMN logo majestic logo threadwatch logo seochat tools logo