191–200 of 310 posts
You can’t make this decision until you know how many customers are on http and how lucrative they are . Breaking an API because you read a blog post is a bad idea
Then you can work with those customers to help them upgrade their clients to HTTPS.
If you do not want to do that, then don't accept connections on port 80, at least when version 6 internet is being used. (For version 4 internet, it is possible that you might use the same IP address for domain names that do want to accept connections on port 80, so you cannot easily block them in such a case.)
And, if you want to avoid compromising authentication data, then TLS is not good enough anyways. The client will need to know that the server certificates have not been compromised. HMAC will avoid that problem, even without TLS.
There is also the payload data. TLS will encrypt that, but the URL will be unencrypted if TLS is not used, whether or not the API key is revoked; the URL and headers may contain stuff other than API keys.
Some APIs also might not need keys; e.g. read-only functions for public data often should not need any kind of API keys (and should not have mandatory TLS either, although allowing optional TLS is helpful, since it does provide some security, even though it doesn't solve everything).
HSTS is even worse.
TLS prevents spies from reading and tampering with your messages, but does not prevent the server from doing so (although in this case it might be unimportant, depending on the specific file being accessed). It also is complicated and wastes energy, and there are sometimes security vulnerabilities in some implementations so does not necessarily improve security.
Of course, these ideas will not, by itself, improve security, and neither will TLS; their combination also won't do. You will have to be more careful to actually improve security properly. Some people think that, if you add TLS and HTTPS, and insist on using it, then it is secure. Well, it is very wrong!!! TLS will improve security in some ways as described in the previous paragraph, but does not solve everything.
It is also problematic if a client does not have an option to disable TLS (or use unencrypted proxies), since if you deliberately want to do MITM on your own computer, you will then have to effectively decrypt and encrypt the data twice. (If the client uses TLS by default, that would work, although if it is according to the URL then it might be by the configurable URL instead; however, the URLs do not always come from the configuration file, and even if it does, and if you want to avoid typographical errors (although even if "https" is specified, typographical errors are still possible (e.g. in the domain name), so just checking for "https" won't even necessarily help anyways; specifying what certificates to expect might sometimes help), then you might have your program to display a warning message, perhaps.) Another problem is if the client and server require different versions of TLS and it is difficult to change the software (there are reasons you might want to change only some parts of it, and that can be difficult); using a local unencrypted proxy which connects to the server using TLS, can also avoid problems like this, too.
Earlier quoted context omitted.
If a malicious party has access to the API key, it should be revoked regardless
Of course. But I think the poster above was referring to just posting random keys to the server. In other words I don't have your key, or any key, but I have "all of them". The correct response to this though is that "there are lots of keys, and valid keys are sparse." In other words the jumper of valid keys that could be invalidated in this way is massively smaller than the list of invalid keys. Think trillions of t…
People could just hit important data fetch endpoints with random keys, until they find one that’s good, and then have a compromised account.
npm is misusing 426 Upgrade Required. https://httpwg.org/specs/rfc9110.html#status.426 : > The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 7.8). https://httpwg.org/specs/rfc9110.html#field.upgrade : > The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transpo…
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
https://www.iana.org/assignments/http-upgrade-tokens/http-up...
I think that it would be better to allow both as much as possible. One way to handle authentication is to use HMAC; you can do that even without needing TLS (and HMAC won't leak the keys if one of the systems (e.g. a reverse proxy or something else) is compromised). If you do not want to do that, then don't accept connections on port 80, at least when version 6 internet is being used. (For version 4 internet, it is p…
> The client will need to know that the server certificates have not been compromised. HMAC will avoid that problem, even without TLS.
HMAC doesn't solve the problem: the client still doesn't know that the shared key isn't compromised. What does it even mean for either a client or server to know something is compromised? If Alice and Bob have a shared key, what can they do to ensure Mallory doesn't also have the shared key?
Maybe shttp would have been better than https to reduce typo errors or maybe even something completely different from http.
Earlier quoted context omitted.
What's stopping the MITM just copying that header?
Even if the copy the header, they can only perform a replay attack, which is an improvement over leaking an API key. Also, you could include a timestamp in the signature to limit the amount of time it could be replayed.
I think that it would be better to allow both as much as possible. One way to handle authentication is to use HMAC; you can do that even without needing TLS (and HMAC won't leak the keys if one of the systems (e.g. a reverse proxy or something else) is compromised). If you do not want to do that, then don't accept connections on port 80, at least when version 6 internet is being used. (For version 4 internet, it is p…
HMAC is a fine suggestion but let's be practical. These days you can tell a junior engineer to go use TLS, but you can't tell a junior engineer to implement HMAC to sign API requests. > The client will need to know that the server certificates have not been compromised. HMAC will avoid that problem, even without TLS. HMAC doesn't solve the problem: the client still doesn't know that the shared key isn't compromised.…
Of course, that is true, but TLS doesn't help with that, either. However, if a reverse proxy (especially if run by a third party) or something else like that is compromised, then HMAC won't allow you to compromise the shared key if the reverse proxy does not know the shared key (unless they can somehow trick the server into revealing it, but that is a separate issue).
An additional issue arises if it is compromised even before the client receives the key for the first time, if it is sent using the same communication channels; in that case, of course neither TLS nor HMAC will help (although certificate revocation may do in this case, but some other method will then be needed to be able to correctly trust the new certificate).
However, different services may require different levels of security (sometimes, hiding the key isn't enough; and, sometimes, encrypting the data isn't enough). How you will handle that depends on what security you require.
Completely agree, and arguably why stop at API servers? Depending on server-side HTTP -> HTTPS redirects for security reinforces/rewards bad practices (linking to HTTP, users directly entering HTTP etc.), in a way that makes users vulnerable to one of the few remaining attack vectors of "scary public Wi-Fis".
The push for "TLS all the things" was already a massive overreach that actively made security worse overall, because it further ingrained the user tendency to click through scary browser warnings (all for the sake of encrypting things that were fine in plaintext). And you want to go even further ? No thank you.
What was fine in plaintext?