What’s annoying and completely unnecessary is aggressively short session times on resources that are already behind a VPN and multiple layers of security, such as an RDP session, making you constantly re-authenticate throughout the day if you happen to turn your attention away from it for a few minutes. In fact, having to re-authenticate for multiple services throughout my workday day really adds up.
Short session expiration does not help security
361–370 of 434 posts
Re: Short session expiration does not help security
#362Earlier quoted context omitted.
> Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode. I think this is a good authentication model, but it costs money. There is the upfront cost of the physical card, and then the higher cost of lost account recovery. I think that's the turn-off to most banks; they will have to staff a call center that can verify your ID, issue a new card, and then de…
In Norway, Latvia, Belgium and probably others, the card is issued by the government. So there is no cost to the bank to re-issue a lost card.
Ah, that's the key. We'd never get a national ID in the US, instead ironically forcing the costly KYC onto each individual bank. (And Twitter now apparently.)
Re: Short session expiration does not help security
#363If the account is for accessing employer's system then sessions have to be kept short, and users have to re-login every day. Otherwise employees who have left the company would continue to access the system. The reason Google never expires your session is because they want to track your activity and connect your activity to your account. This is not a good system to copy.
This seems like a non issue... Can't you just invalidate existing sessions/tokens immediately when an account is suspended?
If you're using your own password-based auth then you can. But that has its own issues (such as user has to remember to delete account on your system). If you're using single-sign-on then you have a token from an identity provider such as Microsoft or Google, and then you don't get immediate notification that the user account has been suspended.
Re: Short session expiration does not help security
#364If the account is for accessing employer's system then sessions have to be kept short, and users have to re-login every day. Otherwise employees who have left the company would continue to access the system. The reason Google never expires your session is because they want to track your activity and connect your activity to your account. This is not a good system to copy.
Surely you can revoke a session before it expires?
No you can't because you don't immediately know that the user's account has been suspended (assuming you're using an identity provider).
Re: Short session expiration does not help security
#365Earlier quoted context omitted.
I’m so envious of the Baltic’s use of technology at the institutional level. It seems literally infeasible for the United States to have state-issued PKI. It’s a meta-partisan issue: no side trusts the other to manage crypto or computer systems. So for example instead of a public many-to-many digital publishing platform we are stuck with the whims of grown men who want to fist fight each other in the Colosseum and al…
If the government wants to do something they should publish open source code that implements a sane authentication system, and then have no part of operating it whatsoever. If it's good and free people will use it voluntarily. If it isn't then you certainly don't want the same people implementing anything mandatory.
The best part is that the US Government already did this -- it runs the second largest PKI. Second only to the Internet. It has issued more than 20 million certificates to individuals.
Re: Short session expiration does not help security
#366The main place I see short session expirations is on banking and financial apps, which seems defensible to me for a couple of reasons: 1) They're used by a wide variety of people, including people who may not own a computer or mobile device, or who may not have a backup device to use when their personal device breaks. This group is probably shrinking—more and more people have smartphones and the remaining people who…
To be honest I feel like biometric app unlock has largely made the need for the short tokens banking experience obsolete. I don’t want to change my credential ever 15 minutes, I just want my bank app to verify my biometrics on sensitive operations. The only real reason for short lived bearer “tokens” these days is so you can deploy them in scenarios without revocation lists.
This is how the banking app my team built works -- on Android/iOS devices a hardware-backed keypair is generated and when a login is needed, the keychain is unlocked using local biometrics to perform a signing operation which authenticates the user.
There's a bit more to it than that because we support remote attestation, and you only get a read-only token until you've performed remote attestation (which generally happens quickly).
edit: The authentication results in a short-lived token (5m), a refresh token (20m), but can be re-authenticated with the keypair challenge at any time.
Re: Short session expiration does not help security
#367Earlier quoted context omitted.
If the government wants to do something they should publish open source code that implements a sane authentication system, and then have no part of operating it whatsoever. If it's good and free people will use it voluntarily. If it isn't then you certainly don't want the same people implementing anything mandatory.
The best part is that the US Government already did this -- it runs the second largest PKI. Second only to the Internet. It has issued more than 20 million certificates to individuals.
For those curious:
https://public.cyber.mil/pki-pke/interoperability/
Or in visual form:
https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/img/fed_...
Re: Short session expiration does not help security
#368In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions (following a credential change, user being deleted, etc). The short session expiry is used as a workaround to force the third-party service to regularly check-in with the identity provider, thus placin…
The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation, although it is still pull-based instead of push-based. The scheme is simple:
1. Use short-lived access tokens (forcing clients to refresh often)
2. Check for revocation on every token refresh
There is even an OAuth 2.0 RFC for a token revocation API[1], and an Open ID Connect extension for backchannel logout[2]. Unfortunately, many OAuth 2 implementations (especially these were refresh tokens are JWT-based) do not support revocation of refresh tokens at all.
The other big problem is that refresh tokens are too often misunderstood. I've consulted quite a lot of development teams who implemented OAuth 2.0 (both as a client and an AS/RS), and most of the developers did not initially understand what the refresh token is meant to do. This resulted in a lot of wrong implementations.
If I blame the standards for something, I'd blame them for being too complex and flexible. This goes without saying for SAML - nobody should be using that if they have any choice. But even simple OAuth 2.0 needs care. There are many RFCs out there, and if you just read the original RFC or one of the many low-quality guides on the interwebs, you probably would miss the point about how to properly use a refresh token. RFC 6749 subtly hints at this strategy I mentioned above, but never fleshes it out as a recommendation, let alone mandates it.
OpenID Connect is even worse. It introduces a new type of token (ID Token) that has unclear purpose and security, encourages JWT use without setting up a standard for revocation, reinforces the insecure implicit flow and introduces a whole new similarly-insecure flow that serves no purpose (the hybrid flow) which serves no purpose except for making sure there are more vulnerable apps out there.
Both OAuth 2.0 and OIDC can be implemented securely, but the base standards are not guiding you on how to do this, and - in the case of OIDC - contain way too many footguns. I think the OAuth 2.1[3] is a step in the right direction. GNAP[4] (a.k.a. "OAuth 3.0", "XYZ", "TxAuth") looks to me like a step in the wrong direction (even more complexity), but perhaps it's too early to tell.
[1] https://oauth.net/2/token-revocation/
[2] https://openid.net/specs/openid-connect-backchannel-1_0.html
Re: Short session expiration does not help security
#369Earlier quoted context omitted.
My main bank uses username + password + (random subset of ‘memorable word but actually unencrypted password’ driven by select boxes), then 2FA on top, and it literally feels like they just slapped a bunch of things together to add extra barriers to auth in sequence. This is the UK. Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode. Same as chip & pin…
I’m so envious of the Baltic’s use of technology at the institutional level. It seems literally infeasible for the United States to have state-issued PKI. It’s a meta-partisan issue: no side trusts the other to manage crypto or computer systems. So for example instead of a public many-to-many digital publishing platform we are stuck with the whims of grown men who want to fist fight each other in the Colosseum and al…
> no side trusts the other to manage crypto or computer systems
Nor should they. Too much power for governments to have. Every so often some news gets posted here about some government official who just does not give a shit about people's rights, you can actually feel the contempt when you read what they say.
Government solutions are non-solutions. We should solve these problems with ubiquitous technology or not solve them at all.
Re: Short session expiration does not help security
#370Earlier quoted context omitted.
If the government wants to do something they should publish open source code that implements a sane authentication system, and then have no part of operating it whatsoever. If it's good and free people will use it voluntarily. If it isn't then you certainly don't want the same people implementing anything mandatory.
The best part is that the US Government already did this -- it runs the second largest PKI. Second only to the Internet. It has issued more than 20 million certificates to individuals.
That's the part you don't want them to do though. Centralized PKI is bad for privacy and creates a single point of compromise. You don't want this, but for the whole population:
https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
What you want is some well-reviewed code that a bank or utility company can "apt install" onto their server and get secure decentralized web authentication working in five minutes instead of leaving them to create some custom in-house contraption designed by a rotating committee of middle managers.
And they should really endeavor to break that PKI thing into smaller, independent, less centralized pieces. It's way too big as it is. There appears to be something called "Symantec" between "Federal Bridge" and "US Senate" and then another "Symantec" between "Federal Bridge" and "Naval Reactors" -- that doesn't seem great.