6 ms·

Designing an Authentication System: A Dialogue in Four Scenes (1988)

94 points by itsspring 6y ago

danappelxx 6y ago
Interesting, this dialogue is from 1988, and since then we’re really re-invented the wheel with JWT, which by my understanding still allows for some forms of MITM and replay attacks, relying heavily on token expiration. Though I suppose the landscape has changed since most connections are now assumed encrypted.
- ahelwer 6y ago
  It definitely allows replay attacks. If you manage to get someone's JWT you can impersonate them for a couple of hours before it expires, unless the website has additional identity verification measures like known IP addresses and such. As you say, connections are now all encrypted so the old prank methods of stealing peoples' tokens off university wifi networks won't work anymore. I've definitely seen JWTs show up in logs, though.
  - user5994461 6y ago
    "known IP addresses and such" does not work for websites authentication and such. Mobile clients are changing IP all the time as they move between WIFIs and mobile networks. That's one of the many limitations of kerberos. It's really not intended to work outside of a company intranet.
    - cryptonector 6y ago
      Uh, u/ahelwer was talking about JWT, not Kerberos. Kerberos doesn't scale to the Internet as it stands, but used properly it's secure. The problem that u/ahelwer says JWT... Kerberos also has when used in HTTP -- as opposed to other uses of Kerberos that don't have this problem. That problem is that they are used as "bearer tokens" without any "channel binding", so if you use them over HTTP without TLS, you lose to any eavesdroppers, and if you use them over HTTPS using the WebPKI and some CA is being (ab)used to MITM you, then you lose. This isn't specific to JWT (or Kerberos) but generic to all small-b bearer token schemes.
      - user5994461 6y ago
        I thought this was talking about JWT not restricting by IP specifically because Kerberos does. Kerberos has very stringent requirements to onboard and preregister user devices, that works in limited contexts like desktop or server authentication in an intranet. JWT is intended to cover other use cases like web authentication. Their (non) limitations are simply reflections of their use cases.
        cryptonector 6y ago
        Kerberos doesn't restrict by IP address anymore -- it can, but it's optional and most sites avoid it.
- im3w1l 6y ago
  Yeah a lot of the problems and solutions seem really foreign. Nowadays it seems you could get the same security through: Connect to auth server over TLS. Exchange password for tickets for all services. Tickets are signed messages containing (user, service, expiration time). Connect to service over TLS and present ticket.
- cryptonector 6y ago
  Kerberos as used in HTTP is no different, really, and you get no benefit from having a replay cache in that case (or the vast majority of Kerberos use cases). Once we're talking HTTP, you really depend on server certificates for security. Attempts to perform "channel binding" or "token binding" in HTTP to alleviate the dependency on server certificates for security have mostly failed due to complexities having to do with reverse proxies and availability of necessary APIs. Signed JWTs have the benefit of not having to first establish shared secrets with a trusted third party. The relying party need only fetch and cache the JWKs and validate the signatures on incoming JWTs. SAML, OIDC, and such, sometimes can resemble Kerberos too. Their benefit lies in not needing HTTP clients to have any smarts, whereas "Negotiate" (RFC4559) does. SAML and OIDC accomplish this by relying mainly on redirect chasing by the client, though as a trade-off they get to deal with the problem of open redirectors.
andyjpb 6y ago
Kerberos is an underrated and underused authorization protocol. (Last time I used it) V5 was reasonably safe to use on the open Internet. It integrates well with MacOS, Linux, BSD and other Unix auth systems and also with SSH. I never really understood why we don't see more of it in "Cloud" models, especially given how decoupled a Kerberos Principal is from the underlying Unix UID. Rather than using SSH keys everywhere and thus having to manage .authorized_keys files all over an estate, the users can `kinit` in a terminal (even on a stock MacOS) and they're away. The credentials are managed centrally. It has service/user and delegation properties similar to oAuth and friends. I've not looked at it with a modern and critical cryptographic eye but, for example, there is (configurable) support for not giving out the initial set of tickets (which is encrypted with the user's password) until the client has proven it knows the user's password. Many browsers (especially on the MS platform, but definitely also Firefox on all platforms as well) can be configured to use the tickets for HTTP authentication (like BASIC or DIGEST, but using a different scheme) at configured domains. Lots of web servers and web apps are easily configurable to put the correct things in the correct environment variables or HTTP headers so integration with random web services is straightforward. Once you've got SSH and Browsing covered with a single credential, you're well on your way to a really versatile SSO scheme.
- NovemberWhiskey 6y ago
  >Kerberos is an underrated and underused authorization protocol. Are you kidding? Every Active Directory deployment uses Kerberos; in the enterprise context, it's probably the most used authentication protocol around.
  - p_l 6y ago
    Unfortunately, even when you have AD, a lot of services deployed don't use it - even when using it could be very simple (ASP.Net deployed on IIS) :-(
- amaccuish 6y ago
  You can also run Kerberos over HTTPS using MS-KKDCP. It's supported on Windows and MIT Kerberos, so your client<->KDC traffic is protected by TLS.
deleted 6y ago
[deleted]
dang 6y ago
Posted quite a few times but a small thread from 2018 has the only previous comments: https://news.ycombinator.com/item?id=17829319 https://news.ycombinator.com/item?id=17829319
cryptonector 6y ago
Using Kerberos as originally intended, meaning that you exchange AP messages (or GSS-API security context tokens) to authenticate and set up session keys, which you then use for session protection using KRB messages (or GSS-API per-message tokens), then it turns out the vast majority of applications don't even need replay caches. The reason is simple: most application protocols follow up the exchange with data that is not sensitive to replays. Relatively few application protocols actually use Kerberos as originally intended though. Many SASL apps run over TLS and don't use Kerberos for session protection, for example, in which case you have to make sure that the server certificate PKI is as good as Kerberos (this is not a big deal in corporate networks). And HTTP/Negotiate uses Kerberos as a bearer token. There are some extensions to do channel binding of Negotiate tokens to TLS, but those are not universally easy to use because of complications to do with reverse proxies and less-than-universal client support. Anyways the "dialogue" exposition is pretty neat and stands the test of time.

94 points by itsspring 6y ago

Interesting, this dialogue is from 1988, and since then we’re really re-invented the wheel with JWT, which by my understanding still allows for some forms of MITM and replay attacks, relying heavily on token expiration. Though I suppose the landscape has changed since most connections are now assumed encrypted.

ahelwer 6y ago
It definitely allows replay attacks. If you manage to get someone's JWT you can impersonate them for a couple of hours before it expires, unless the website has additional identity verification measures like known IP addresses and such. As you say, connections are now all encrypted so the old prank methods of stealing peoples' tokens off university wifi networks won't work anymore. I've definitely seen JWTs show up in logs, though.
- user5994461 6y ago
  "known IP addresses and such" does not work for websites authentication and such. Mobile clients are changing IP all the time as they move between WIFIs and mobile networks. That's one of the many limitations of kerberos. It's really not intended to work outside of a company intranet.
  - cryptonector 6y ago
    Uh, u/ahelwer was talking about JWT, not Kerberos. Kerberos doesn't scale to the Internet as it stands, but used properly it's secure. The problem that u/ahelwer says JWT... Kerberos also has when used in HTTP -- as opposed to other uses of Kerberos that don't have this problem. That problem is that they are used as "bearer tokens" without any "channel binding", so if you use them over HTTP without TLS, you lose to any eavesdroppers, and if you use them over HTTPS using the WebPKI and some CA is being (ab)used to MITM you, then you lose. This isn't specific to JWT (or Kerberos) but generic to all small-b bearer token schemes.
    - user5994461 6y ago
      I thought this was talking about JWT not restricting by IP specifically because Kerberos does. Kerberos has very stringent requirements to onboard and preregister user devices, that works in limited contexts like desktop or server authentication in an intranet. JWT is intended to cover other use cases like web authentication. Their (non) limitations are simply reflections of their use cases.
      - cryptonector 6y ago
        Kerberos doesn't restrict by IP address anymore -- it can, but it's optional and most sites avoid it.
im3w1l 6y ago
Yeah a lot of the problems and solutions seem really foreign. Nowadays it seems you could get the same security through: Connect to auth server over TLS. Exchange password for tickets for all services. Tickets are signed messages containing (user, service, expiration time). Connect to service over TLS and present ticket.
cryptonector 6y ago
Kerberos as used in HTTP is no different, really, and you get no benefit from having a replay cache in that case (or the vast majority of Kerberos use cases). Once we're talking HTTP, you really depend on server certificates for security. Attempts to perform "channel binding" or "token binding" in HTTP to alleviate the dependency on server certificates for security have mostly failed due to complexities having to do with reverse proxies and availability of necessary APIs. Signed JWTs have the benefit of not having to first establish shared secrets with a trusted third party. The relying party need only fetch and cache the JWKs and validate the signatures on incoming JWTs. SAML, OIDC, and such, sometimes can resemble Kerberos too. Their benefit lies in not needing HTTP clients to have any smarts, whereas "Negotiate" (RFC4559) does. SAML and OIDC accomplish this by relying mainly on redirect chasing by the client, though as a trade-off they get to deal with the problem of open redirectors.

andyjpb 6y ago

Kerberos is an underrated and underused authorization protocol. (Last time I used it) V5 was reasonably safe to use on the open Internet. It integrates well with MacOS, Linux, BSD and other Unix auth systems and also with SSH. I never really understood why we don't see more of it in "Cloud" models, especially given how decoupled a Kerberos Principal is from the underlying Unix UID. Rather than using SSH keys everywhere and thus having to manage .authorized_keys files all over an estate, the users can `kinit` in a terminal (even on a stock MacOS) and they're away. The credentials are managed centrally. It has service/user and delegation properties similar to oAuth and friends. I've not looked at it with a modern and critical cryptographic eye but, for example, there is (configurable) support for not giving out the initial set of tickets (which is encrypted with the user's password) until the client has proven it knows the user's password. Many browsers (especially on the MS platform, but definitely also Firefox on all platforms as well) can be configured to use the tickets for HTTP authentication (like BASIC or DIGEST, but using a different scheme) at configured domains. Lots of web servers and web apps are easily configurable to put the correct things in the correct environment variables or HTTP headers so integration with random web services is straightforward. Once you've got SSH and Browsing covered with a single credential, you're well on your way to a really versatile SSO scheme.

NovemberWhiskey 6y ago
>Kerberos is an underrated and underused authorization protocol. Are you kidding? Every Active Directory deployment uses Kerberos; in the enterprise context, it's probably the most used authentication protocol around.
- p_l 6y ago
  Unfortunately, even when you have AD, a lot of services deployed don't use it - even when using it could be very simple (ASP.Net deployed on IIS) :-(
amaccuish 6y ago
You can also run Kerberos over HTTPS using MS-KKDCP. It's supported on Windows and MIT Kerberos, so your client<->KDC traffic is protected by TLS.

deleted 6y ago

[deleted]

dang 6y ago

Posted quite a few times but a small thread from 2018 has the only previous comments: https://news.ycombinator.com/item?id=17829319 https://news.ycombinator.com/item?id=17829319

cryptonector 6y ago

Using Kerberos as originally intended, meaning that you exchange AP messages (or GSS-API security context tokens) to authenticate and set up session keys, which you then use for session protection using KRB messages (or GSS-API per-message tokens), then it turns out the vast majority of applications don't even need replay caches. The reason is simple: most application protocols follow up the exchange with data that is not sensitive to replays. Relatively few application protocols actually use Kerberos as originally intended though. Many SASL apps run over TLS and don't use Kerberos for session protection, for example, in which case you have to make sure that the server certificate PKI is as good as Kerberos (this is not a big deal in corporate networks). And HTTP/Negotiate uses Kerberos as a bearer token. There are some extensions to do channel binding of Negotiate tokens to TLS, but those are not universally easy to use because of complications to do with reverse proxies and less-than-universal client support. Anyways the "dialogue" exposition is pretty neat and stands the test of time.