4 ms·

> This means that as long as you have one example of a signed message, you can forge signatures for that message plus any arbitrary request parameters you like

> This means that as long as you have one example of a signed message, you can forge signatures for that message plus any arbitrary request parameters you like and they will authenticate under the above described scheme. If all requests are made over HTTPS, how could a third party intercept a signed message? How is this any greater of a risk than a third party intercepting user login information? (This is a serious question; I'm not being flippant or saying 'gotcha')

jd007 13y ago
If you do not manage SSL certificate properly (trust only your server's certificate), a MITM attack can break the system easily. Otherwise I don't think you can intercept the signed message if everything is over TLS.
- moakakala 13y ago
  Is the risk any greater with APIs (like described in the article) compared to typical username/password login systems?
  - _phred 13y ago
    A lot of API authentication is half-assed, like the examples in the article. "OAuth is hard, roll your own" is a common approach. Even with, e.g., OAuth 2, who's to say that the scheme is completely safe and that your implementation is correct? As far as API vs. user account, it depends on the loot. An API might let me do more damage faster, or subtly lurk and alter/steal data over time. It might also be harder to detect from the UI, no "last logged in" giveaway. Also, some API vendors recommend disabling SSL cert validation client side. Even for credit card gateways, unbelievably. Since it's a script talking to a script, no one is going to see the cert problems from a MITM until it's too late.
- _phred 13y ago
  Right. If the attack vector is "break SSL" I'm going to try some other attacks first. There's an underlying assumption in the question: my app (and everything else hosted on the box) is safe from XSS, CSRF, injections, and other information leakages. Is it really? How do I know for sure? And who's to say that your forum server (for example) is just as secure? That could be a foothold into your environment too. And let's not forget social manipulation of your staff and users. Maybe I'll just steal the machine in question, or your laptop. After I try all those avenues, I'm either finding another target or ramping up for a protracted attack on your SSL connections. If your site attracts this dedicated of an attack, you'd better get that high paid security consultant. ;)
  - dlitz 13y ago
    The problem with these attacks on SSL is that they're not protracted; They're trivial. Python's httplib doesn't check SSL certificates at all by default, for example, so you just hijack the TCP connection, negotiate SSL, and then you're done. With libcurl, I think you have to set CURLOPT_SSL_VERIFYHOST to 2. If you set it to TRUE (i.e. 1), it skips part of the certificate check, rendering the whole thing trivially insecure. Most (all?) crypto libraries have terrible APIs, or have APIs that are far too low-level to be safely used by most developers. SSL shouldn't be the easiest thing to attack, but in the current state of affairs, it often is.

jd007 13y ago

If you do not manage SSL certificate properly (trust only your server's certificate), a MITM attack can break the system easily. Otherwise I don't think you can intercept the signed message if everything is over TLS.

moakakala 13y ago
Is the risk any greater with APIs (like described in the article) compared to typical username/password login systems?
- _phred 13y ago
  A lot of API authentication is half-assed, like the examples in the article. "OAuth is hard, roll your own" is a common approach. Even with, e.g., OAuth 2, who's to say that the scheme is completely safe and that your implementation is correct? As far as API vs. user account, it depends on the loot. An API might let me do more damage faster, or subtly lurk and alter/steal data over time. It might also be harder to detect from the UI, no "last logged in" giveaway. Also, some API vendors recommend disabling SSL cert validation client side. Even for credit card gateways, unbelievably. Since it's a script talking to a script, no one is going to see the cert problems from a MITM until it's too late.
_phred 13y ago
Right. If the attack vector is "break SSL" I'm going to try some other attacks first. There's an underlying assumption in the question: my app (and everything else hosted on the box) is safe from XSS, CSRF, injections, and other information leakages. Is it really? How do I know for sure? And who's to say that your forum server (for example) is just as secure? That could be a foothold into your environment too. And let's not forget social manipulation of your staff and users. Maybe I'll just steal the machine in question, or your laptop. After I try all those avenues, I'm either finding another target or ramping up for a protracted attack on your SSL connections. If your site attracts this dedicated of an attack, you'd better get that high paid security consultant. ;)
- dlitz 13y ago
  The problem with these attacks on SSL is that they're not protracted; They're trivial. Python's httplib doesn't check SSL certificates at all by default, for example, so you just hijack the TCP connection, negotiate SSL, and then you're done. With libcurl, I think you have to set CURLOPT_SSL_VERIFYHOST to 2. If you set it to TRUE (i.e. 1), it skips part of the certificate check, rendering the whole thing trivially insecure. Most (all?) crypto libraries have terrible APIs, or have APIs that are far too low-level to be safely used by most developers. SSL shouldn't be the easiest thing to attack, but in the current state of affairs, it often is.