4 ms·

I've never understood whats so "ugly" about http authentication. Digest auth can get a little verbose, to be sure, but Basic+SSL is simple, and both are far eas

I've never understood whats so "ugly" about http authentication. Digest auth can get a little verbose, to be sure, but Basic+SSL is simple, and both are far easier than roll-your-own Cookie auth. In fact, the way most people & frameworks implement cookie auth sessions are no less secure than Basic auth. Haven't the events of the past week demonstrated we should all be using SSL anyways, in which case Basic auth would be fine for everyone.

tptacek 16y ago
Basic auth is only simpler than cookie auth if you (a) aren't using a modern web stack (ie, you aren't using ASP.NET, J2EE, Rails, Django, &c) and (b) have only a few users. If either (a) or (b) do not hold, Basic Auth is at least as hard as cookie auth.
- mike-cardwell 16y ago
  I use HTTP authentication when I want to password protect a bunch of static files, or a third party web app. Using the PAM auth module with Apache is particularly nice. Just drop a few lines in a .htaccess file and it uses your users system credentials, eg /etc/passwd and /etc/shadow. HTTP Authentication comes in several flavours. I've not done it myself, but I think you can do interesting things to with Kerberos. Good for Intranet systems. HTTP Authentication does have its places.
  - tptacek 16y ago
    In other words, HTTP Authentication is useful in the same sense as FTP is useful: it's outmoded but sometimes convenient.
    - mike-cardwell 16y ago
      HTTP Authentication is sessionless. In any scenario where you want to protect something without establishing and maintaining a session, it's useful. The only large public website that I know of which still uses HTTP Authentication though is http://www.123-reg.co.uk/ http://www.123-reg.co.uk/
      - tptacek 16y ago
        What's the browser app scenario in which having a session is a liability, but having a stored HTTP Auth credential isn't?
        kls 16y ago
        Actually the elimination of server side session reduces distributed application topology significantly. It is far easier to scale a stateless app than it is a statefull app.
    - deleted 16y ago
      [deleted]
- psadauskas 16y ago
  But if your clients include things that aren't browsers, HTTP Auth is the only acceptable choice.
  - tptacek 16y ago
    That's not true either; you can just do what big API apps do and generate access tokens. Amazon Web Services don't rely on HTTP-Auth.
    - psadauskas 16y ago
      Using curl to access AWS is kind of a pain, since you have to hash the body and your keys into a header. For others, you have to set the token in a header, and it (should) change periodically. Compare to: curl --anyauth --user login:password https://example.com/
      - tptacek 16y ago
        It's a "1 line of Python" pain, true, but it's also significantly more secure. From a cost/benefit perspective, it's an API, a building block of a software development project, and optimizing it for curl-ability doesn't seem like a major win. But my point is just: HTTP Auth is not the best-practices answer to non-browser web services auth. Both API-key and signed URLs are both competitive (and probably better) options.
        mjw 16y ago
        What about for SSL-based APIs? it seems a pretty optimal choice for those.
        tptacek 16y ago
        I don't think it is, for two reasons: (1) For most large apps, you're not really SSL in the provider's own network, so there's always the cross-app risk if something horrible happens. (2) It's forcing app-to-app, business-to-business authentication into a username/password mold that doesn't many any real sense; a 128 bit random key (or an SSL client cert) makes more sense anyways. Against those two problems --- which are marginal, I concede --- HTTP Basic offers... exactly what advantage? I don't see it.
deleted 16y ago
[deleted]
ataggart 16y ago
A few problems with basic auth: * Browser specific UI, which leads to: * No place to put password recovery links * No place to put explanatory text * No mechanism for logout
- kls 16y ago
  If the browsers would allow the login box to be styled via CSS like the rest of the UI, I think you would see more use. We finally went to SAML for our REST service authentication and have been pretty happy with it. THe nice part about SAML is an identity server provides the auth endpoint, and your app proxies the token to the identity server for authentication and authorization, it gets your app or container out of the game of authentication and authorization. Further many app servers can plug into the identity server therefore providing container managed security gates.

tptacek 16y ago

Basic auth is only simpler than cookie auth if you (a) aren't using a modern web stack (ie, you aren't using ASP.NET, J2EE, Rails, Django, &c) and (b) have only a few users. If either (a) or (b) do not hold, Basic Auth is at least as hard as cookie auth.

mike-cardwell 16y ago
I use HTTP authentication when I want to password protect a bunch of static files, or a third party web app. Using the PAM auth module with Apache is particularly nice. Just drop a few lines in a .htaccess file and it uses your users system credentials, eg /etc/passwd and /etc/shadow. HTTP Authentication comes in several flavours. I've not done it myself, but I think you can do interesting things to with Kerberos. Good for Intranet systems. HTTP Authentication does have its places.
- tptacek 16y ago
  In other words, HTTP Authentication is useful in the same sense as FTP is useful: it's outmoded but sometimes convenient.
  - mike-cardwell 16y ago
    HTTP Authentication is sessionless. In any scenario where you want to protect something without establishing and maintaining a session, it's useful. The only large public website that I know of which still uses HTTP Authentication though is http://www.123-reg.co.uk/ http://www.123-reg.co.uk/
    - tptacek 16y ago
      What's the browser app scenario in which having a session is a liability, but having a stored HTTP Auth credential isn't?
      - kls 16y ago
        Actually the elimination of server side session reduces distributed application topology significantly. It is far easier to scale a stateless app than it is a statefull app.
  - deleted 16y ago
    [deleted]
psadauskas 16y ago
But if your clients include things that aren't browsers, HTTP Auth is the only acceptable choice.
- tptacek 16y ago
  That's not true either; you can just do what big API apps do and generate access tokens. Amazon Web Services don't rely on HTTP-Auth.
  - psadauskas 16y ago
    Using curl to access AWS is kind of a pain, since you have to hash the body and your keys into a header. For others, you have to set the token in a header, and it (should) change periodically. Compare to: curl --anyauth --user login:password https://example.com/
    - tptacek 16y ago
      It's a "1 line of Python" pain, true, but it's also significantly more secure. From a cost/benefit perspective, it's an API, a building block of a software development project, and optimizing it for curl-ability doesn't seem like a major win. But my point is just: HTTP Auth is not the best-practices answer to non-browser web services auth. Both API-key and signed URLs are both competitive (and probably better) options.
      - mjw 16y ago
        What about for SSL-based APIs? it seems a pretty optimal choice for those.
        tptacek 16y ago
        I don't think it is, for two reasons: (1) For most large apps, you're not really SSL in the provider's own network, so there's always the cross-app risk if something horrible happens. (2) It's forcing app-to-app, business-to-business authentication into a username/password mold that doesn't many any real sense; a 128 bit random key (or an SSL client cert) makes more sense anyways. Against those two problems --- which are marginal, I concede --- HTTP Basic offers... exactly what advantage? I don't see it.

deleted 16y ago

[deleted]

ataggart 16y ago

A few problems with basic auth: * Browser specific UI, which leads to: * No place to put password recovery links * No place to put explanatory text * No mechanism for logout

kls 16y ago
If the browsers would allow the login box to be styled via CSS like the rest of the UI, I think you would see more use. We finally went to SAML for our REST service authentication and have been pretty happy with it. THe nice part about SAML is an identity server provides the auth endpoint, and your app proxies the token to the identity server for authentication and authorization, it gets your app or container out of the game of authentication and authorization. Further many app servers can plug into the identity server therefore providing container managed security gates.