8 ms·

First off, I'm not an expert at security, but I do have a background in it and in development of microservices. So fair warning. API keys provide reasonably g

First off, I'm not an expert at security, but I do have a background in it and in development of microservices. So fair warning. API keys provide reasonably good security, but there is a reason why companies have moved to OAuth. Using https, your payloads are protected by SSL, but the URI and the request and response headers aren't. That means no matter how you intend to pass along your API key, it is in the open and thus can be intercepted. So, bad, right? Well, maybe not. If whatever you are securing with an API key is not that critical to anyone and you just want to prevent outsiders from calling your API or calling it repeatedly and abusing it, then API keys are fine. I would make it hard to guess, but I wouldn't go crazy with that, either, because everything is "easy to guess" for anyone who is really working hard at gaining access. If you are just working on a game, I would do the basics to secure your services and then move on to the more critical matters.

whatthemick 9y ago
Headers and URI are encrypyed aswell, in a HTTPS request. Only the domain is exposed (when SNI is supported)
- davidgh 9y ago
  Not trying to be pendantic but the entire hostname is exposed, not just the domain name. I’m assuming that’s what you meant.
  - singlow 9y ago
    The hostname is a domain name. Some domain names may not be hostnames, but all hostnames are domain names. So the entire domain name, which is also a hostname, is exposed.
    - quesera 9y ago
      These definitions are highly context-dependent, though. Even more pedantic, but sometimes surprising: SNI reveals the full text of the final lookup query that the requester used to obtain an IP address to open a TCP connection to the server. Neither the text nor the address are necessarily "correct", and the text might be formally a nodename, a hostname, a domain name, a fully-qualified domain name, or a text representation of an IP address (which, again, is not necessarily correct). In practice, certificate authorities constrain the possibilities of the lookup text (for a successful connection using the CA-signed cert), but that is not a technical limitation. And of course, a self-signed certificate has no such constraints. With cooperation between the server owner and users, an SNI-sensitive publisher could make their site available at https://fbi.gov/ https://fbi.gov/. But it's probably easier just to use a meaningless domain instead. :)
      - zAy0LfpBZLC8mAC 9y ago
        > Neither the text nor the address are necessarily "correct", and the text might be formally a nodename, a hostname, a domain name, a fully-qualified domain name, or a text representation of an IP address (which, again, is not necessarily correct). Please don't make claims about standards that you haven't read. SNI supports only DNS FQDNs.
        quesera 9y ago
        You are incorrrect. That's not quite what the spec says, and furthermore it is not true in practice. Giving you the benefit of the doubt, I reread the spec, and I tested in nginx. Works fine.
        detaro 9y ago
        What spec? RFC6066 (https://tools.ietf.org/html/rfc6066#section-3 https://tools.ietf.org/html/rfc6066#section-3) says "Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document)." [snip] ""HostName" contains the fully qualified DNS hostname of the server, as understood by the client." [snip] "Literal IPv4 and IPv6 addresses are not permitted in "HostName"."
        quesera 9y ago
        RFC6066, correct. The "as understood by the client" is very important, apparently. Furthermore, the name does not need to be in DNS. There is no single source of true DNS anyway (though of course the ~whole world uses the same root servers). Try it. I just set up a remote server for "snitest", added the IP address to /etc/hosts only, generated a cert for that name only, and got the correct cert via SNI in a local browser. The same process (minus /etc/hosts modification) also worked for a bare (textual representation of an) IP address.
        zAy0LfpBZLC8mAC 9y ago
throwanem 9y ago
You appear to be shadowbanned for no immediately obvious reason. I vouched this comment to point out that it contains a factual error, to wit, the claim that the headers and URI of a request made via TLS are sent in the clear. They are not; the socket is encrypted before any protocol messages are exchanged. Perhaps you're thinking of SMTP STARTTLS? Companies have moved to OAuth, and to JWT as the payload, because it provides a lightweight, shared-little authentication/authorization framework that's well suited to the needs of a distributed microservice architecture and to third-party service integration - not because it overcomes a nonexistent problem with HTTPS not encrypting headers.
- 0x0 9y ago
  A properly configured SMTP STARTTLS would not really send anything substantial in cleartext either, it would issue the STARTTLS command as the first command and the rest would be wrapped in encrypted TLS. You can think of the unencrypted STARTTLS preamble as a set of static ascii bytes that are the same for every connection.
  - throwanem 9y ago
    It's the closest common parallel I can find for what the prior commenter is describing, but yeah, it isn't really all that close. I've seen poor implementations leak, but not for many years now.
    - bmm6o 9y ago
      I don't think the op had something else in mind. IME it's a strangely widespread misunderstanding that https encrypts just parts of the http request. I think it's because of the advice to not put sensitive data in urls. The reason for that is due to logging at the endpoint, but it's misunderstood that it's not encrypted. It's funny because it's so easy to test the hypothesis, and it's hard to even propose a reason it would be that way.
- ataturk 9y ago
  I am shadow banned because my politics are unpopular here. I am locked to 2 posts every few hours because otherwise my dangerous ideas might get out into the wild. Thanks for the clarification on the headers part, though. As I said, I am no expert on TLS, only work on micro services that don't have to be heavily secured and have done work with OAuth and noted that API keys aren't much favored anymore. I really a am a thoughtful, well-rounded person, it's not my fault that the Internet world won't accept me, or perhaps because Y-Combinator has a particular agenda.
deleted 9y ago
[deleted]

whatthemick 9y ago

Headers and URI are encrypyed aswell, in a HTTPS request. Only the domain is exposed (when SNI is supported)

davidgh 9y ago
Not trying to be pendantic but the entire hostname is exposed, not just the domain name. I’m assuming that’s what you meant.
- singlow 9y ago
  The hostname is a domain name. Some domain names may not be hostnames, but all hostnames are domain names. So the entire domain name, which is also a hostname, is exposed.
  - quesera 9y ago
    These definitions are highly context-dependent, though. Even more pedantic, but sometimes surprising: SNI reveals the full text of the final lookup query that the requester used to obtain an IP address to open a TCP connection to the server. Neither the text nor the address are necessarily "correct", and the text might be formally a nodename, a hostname, a domain name, a fully-qualified domain name, or a text representation of an IP address (which, again, is not necessarily correct). In practice, certificate authorities constrain the possibilities of the lookup text (for a successful connection using the CA-signed cert), but that is not a technical limitation. And of course, a self-signed certificate has no such constraints. With cooperation between the server owner and users, an SNI-sensitive publisher could make their site available at https://fbi.gov/ https://fbi.gov/. But it's probably easier just to use a meaningless domain instead. :)
    - zAy0LfpBZLC8mAC 9y ago
      > Neither the text nor the address are necessarily "correct", and the text might be formally a nodename, a hostname, a domain name, a fully-qualified domain name, or a text representation of an IP address (which, again, is not necessarily correct). Please don't make claims about standards that you haven't read. SNI supports only DNS FQDNs.
      - quesera 9y ago
        You are incorrrect. That's not quite what the spec says, and furthermore it is not true in practice. Giving you the benefit of the doubt, I reread the spec, and I tested in nginx. Works fine.
        detaro 9y ago
        What spec? RFC6066 (https://tools.ietf.org/html/rfc6066#section-3 https://tools.ietf.org/html/rfc6066#section-3) says "Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document)." [snip] ""HostName" contains the fully qualified DNS hostname of the server, as understood by the client." [snip] "Literal IPv4 and IPv6 addresses are not permitted in "HostName"."
        quesera 9y ago
        RFC6066, correct. The "as understood by the client" is very important, apparently. Furthermore, the name does not need to be in DNS. There is no single source of true DNS anyway (though of course the ~whole world uses the same root servers). Try it. I just set up a remote server for "snitest", added the IP address to /etc/hosts only, generated a cert for that name only, and got the correct cert via SNI in a local browser. The same process (minus /etc/hosts modification) also worked for a bare (textual representation of an) IP address.
        zAy0LfpBZLC8mAC 9y ago

throwanem 9y ago

You appear to be shadowbanned for no immediately obvious reason. I vouched this comment to point out that it contains a factual error, to wit, the claim that the headers and URI of a request made via TLS are sent in the clear. They are not; the socket is encrypted before any protocol messages are exchanged. Perhaps you're thinking of SMTP STARTTLS? Companies have moved to OAuth, and to JWT as the payload, because it provides a lightweight, shared-little authentication/authorization framework that's well suited to the needs of a distributed microservice architecture and to third-party service integration - not because it overcomes a nonexistent problem with HTTPS not encrypting headers.

0x0 9y ago
A properly configured SMTP STARTTLS would not really send anything substantial in cleartext either, it would issue the STARTTLS command as the first command and the rest would be wrapped in encrypted TLS. You can think of the unencrypted STARTTLS preamble as a set of static ascii bytes that are the same for every connection.
- throwanem 9y ago
  It's the closest common parallel I can find for what the prior commenter is describing, but yeah, it isn't really all that close. I've seen poor implementations leak, but not for many years now.
  - bmm6o 9y ago
    I don't think the op had something else in mind. IME it's a strangely widespread misunderstanding that https encrypts just parts of the http request. I think it's because of the advice to not put sensitive data in urls. The reason for that is due to logging at the endpoint, but it's misunderstood that it's not encrypted. It's funny because it's so easy to test the hypothesis, and it's hard to even propose a reason it would be that way.
ataturk 9y ago
I am shadow banned because my politics are unpopular here. I am locked to 2 posts every few hours because otherwise my dangerous ideas might get out into the wild. Thanks for the clarification on the headers part, though. As I said, I am no expert on TLS, only work on micro services that don't have to be heavily secured and have done work with OAuth and noted that API keys aren't much favored anymore. I really a am a thoughtful, well-rounded person, it's not my fault that the Internet world won't accept me, or perhaps because Y-Combinator has a particular agenda.

deleted 9y ago

[deleted]