5 ms·

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 MI

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.

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.