4 ms·

What is not secure about using HTTP basic auth over a properly secured HTTPS connection?

by u801e 7y ago

nnutter 7y ago
Haven’t read the article yet but I will be surprised if it claims that. I would imagine it’s more about using your primary means (password) of authn which has worse consequences than using a secondary, revocable means (token) upon compromise.
- nnutter 7y ago
  A comment below also points out the token ensures a higher quality secret is being used most of the time. Edit: typo
- u801e 7y ago
  The blog post[1] that the article links to does state: >> We are announcing deprecations that will improve the security of GitHub apps and APIs [1] https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/ https://developer.github.com/changes/2019-11-05-deprecated-p...
  - ptoomey3 7y ago
    It’s not at all about the security of delivering credentials over https, but more about the the complexity of trying to defend against weak passwords/credential stuffing with an api. For example, it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices https://github.blog/changelog/2019-07-01-verified-devices to an api.
    - u801e 7y ago
      > it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices https://github.blog/changelog/2019-07-01-verified-devices to an api. Except that email, as described in the blog you linked to, is not a secure means of communication. What would be secure is to use a client side TLS certificate as part of the authentication process. That is, your browser/device sends it as part of the TLS connection negotiation process and then you authenticate via the username and password (via HTTP basic auth). They're already doing something like that whenever one pushes or fetches from a git repository hosted on Github through ssh key authentication. It wouldn't be much of a stretch for Github to allow an account holder to upload a CSR and then Github signs it and makes a certificate, which the account holder can then add to the browser's or OS's certificate store.
      - ptoomey3 7y ago
        The verified device flow isn’t meant to be as strong as 2FA, but is a very strong mitigation against mass credential stuffing attacks for all users. In terms of client certs, see my response in https://news.ycombinator.com/item?id=22849985 https://news.ycombinator.com/item?id=22849985. I agree client certs would be great. However, it can be tricky to couple your app logic with transport based security. A good example of this...chrome/google introduced a crazy cool concept called “channel bound cookies” - http://www.browserauth.net/channel-bound-cookies http://www.browserauth.net/channel-bound-cookies, but it never gained any traction because of the complexity noted.
veesahni 7y ago
We similarly deprecated password auth on our API previously. We used to allow basic auth over HTTPS. Two issues: * users will ultimately hard code the passwords in a script * the user may have used the same password on other sites Combine the above together and it can result in a bad situation. It's best for a vendor (like GitHub) to encourage good security, where possible. A token which is unlinked to the password and can be revoked independently of the password adds minimises the extend of the compromise.
- thanksforfish 7y ago
  Did you end up using the token with HTTP basic auth over HTTPS? Or did you switch to something else to transport the auth token?
  - veesahni 7y ago
    Authorization: Bearer <token> Ultimately similar to what github did..
remus 7y ago
Perhaps not about the security of basic auth per se, but if you are using basic auth then setting up mfa is a little more painful as you first need to migrate all your API access to tokens before you can change to mfa. If you're already using tokens then turning on mfa is just flipping a switch and scanning your totp code.
- u801e 7y ago
  What would be nice is if Github would allow one factor of authentication via a client side TLS certificate. That's what's essentially being done when one clones a repo via SSH since Github has a copy of the account holder's SSH public key. That is, 2FA could be achieved via use of that certificate and a username/password.
  - tedivm 7y ago
    Can client side certificates be "locked" in the same way that SSH keys can (where you require a passphrase before it is loaded into the ssh agent)?
    - u801e 7y ago
      When you generate a private key using openssl, it will prompt you for a passphrase.
  - ptoomey3 7y ago
    One issue with HTTPS client cert auth is that it can be non-trivial to support at the application level when you have a multi-tier architecture where TLS termination happens at the edge of your infrastructure.
    - u801e 7y ago
      I wonder if there are any solutions out there that can handle TLS client cert verification along with validating the username/password (which, if provided via HTTP basic auth, would be in the header of the request). That way, the application itself could just concern itself with serving resources, interacting with resources, etc instead of handling authentication or authorization. The infrastructure edge device could communicate additional information if needed by adding headers to the original HTTP request when it's passed down to the endpoint that actually handles the request.
Arnavion 7y ago
Tokens (in general, not specifically GitHub's PATs) have more fine-grained permissions and can be revoked / rotated more easily.
tialaramex 7y ago
Mostly poor quality passwords and password re-use are the problem. The replacement tokens are generated by GitHub, so you can't choose "bad" ones, and if you were to re-use them it ought to be pretty clear that's crazy since GitHub chose them in the first place.
wp381640 7y ago
It's about the password management. Users get tempted into storing their passwords in plain text in env, config files, code etc.

What is not secure about using HTTP basic auth over a properly secured HTTPS connection?

by u801e 7y ago

What is not secure about using HTTP basic auth over a properly secured HTTPS connection?

Haven’t read the article yet but I will be surprised if it claims that. I would imagine it’s more about using your primary means (password) of authn which has worse consequences than using a secondary, revocable means (token) upon compromise.

nnutter 7y ago
A comment below also points out the token ensures a higher quality secret is being used most of the time. Edit: typo
u801e 7y ago
The blog post[1] that the article links to does state: >> We are announcing deprecations that will improve the security of GitHub apps and APIs [1] https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/ https://developer.github.com/changes/2019-11-05-deprecated-p...
- ptoomey3 7y ago
  It’s not at all about the security of delivering credentials over https, but more about the the complexity of trying to defend against weak passwords/credential stuffing with an api. For example, it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices https://github.blog/changelog/2019-07-01-verified-devices to an api.
  - u801e 7y ago
    > it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices https://github.blog/changelog/2019-07-01-verified-devices to an api. Except that email, as described in the blog you linked to, is not a secure means of communication. What would be secure is to use a client side TLS certificate as part of the authentication process. That is, your browser/device sends it as part of the TLS connection negotiation process and then you authenticate via the username and password (via HTTP basic auth). They're already doing something like that whenever one pushes or fetches from a git repository hosted on Github through ssh key authentication. It wouldn't be much of a stretch for Github to allow an account holder to upload a CSR and then Github signs it and makes a certificate, which the account holder can then add to the browser's or OS's certificate store.
    - ptoomey3 7y ago
      The verified device flow isn’t meant to be as strong as 2FA, but is a very strong mitigation against mass credential stuffing attacks for all users. In terms of client certs, see my response in https://news.ycombinator.com/item?id=22849985 https://news.ycombinator.com/item?id=22849985. I agree client certs would be great. However, it can be tricky to couple your app logic with transport based security. A good example of this...chrome/google introduced a crazy cool concept called “channel bound cookies” - http://www.browserauth.net/channel-bound-cookies http://www.browserauth.net/channel-bound-cookies, but it never gained any traction because of the complexity noted.

veesahni 7y ago

We similarly deprecated password auth on our API previously. We used to allow basic auth over HTTPS. Two issues: * users will ultimately hard code the passwords in a script * the user may have used the same password on other sites Combine the above together and it can result in a bad situation. It's best for a vendor (like GitHub) to encourage good security, where possible. A token which is unlinked to the password and can be revoked independently of the password adds minimises the extend of the compromise.

thanksforfish 7y ago
Did you end up using the token with HTTP basic auth over HTTPS? Or did you switch to something else to transport the auth token?
- veesahni 7y ago
  Authorization: Bearer <token> Ultimately similar to what github did..

remus 7y ago

Perhaps not about the security of basic auth per se, but if you are using basic auth then setting up mfa is a little more painful as you first need to migrate all your API access to tokens before you can change to mfa. If you're already using tokens then turning on mfa is just flipping a switch and scanning your totp code.

u801e 7y ago
What would be nice is if Github would allow one factor of authentication via a client side TLS certificate. That's what's essentially being done when one clones a repo via SSH since Github has a copy of the account holder's SSH public key. That is, 2FA could be achieved via use of that certificate and a username/password.
- tedivm 7y ago
  Can client side certificates be "locked" in the same way that SSH keys can (where you require a passphrase before it is loaded into the ssh agent)?
  - u801e 7y ago
    When you generate a private key using openssl, it will prompt you for a passphrase.
- ptoomey3 7y ago
  One issue with HTTPS client cert auth is that it can be non-trivial to support at the application level when you have a multi-tier architecture where TLS termination happens at the edge of your infrastructure.
  - u801e 7y ago
    I wonder if there are any solutions out there that can handle TLS client cert verification along with validating the username/password (which, if provided via HTTP basic auth, would be in the header of the request). That way, the application itself could just concern itself with serving resources, interacting with resources, etc instead of handling authentication or authorization. The infrastructure edge device could communicate additional information if needed by adding headers to the original HTTP request when it's passed down to the endpoint that actually handles the request.

Arnavion 7y ago

Tokens (in general, not specifically GitHub's PATs) have more fine-grained permissions and can be revoked / rotated more easily.

tialaramex 7y ago

Mostly poor quality passwords and password re-use are the problem. The replacement tokens are generated by GitHub, so you can't choose "bad" ones, and if you were to re-use them it ought to be pretty clear that's crazy since GitHub chose them in the first place.

wp381640 7y ago

It's about the password management. Users get tempted into storing their passwords in plain text in env, config files, code etc.