One cannot remove all long-term credentials. The process of establishing a session is one of identifying a stable entity (such as a user account) and giving that entity temporary access to the resource servers. In simplest form, this is providing the username (entity) and password (secret that authenticates the username), and receiving a session cookie (temporary credentials) for accessing the service.
Somewhere at the root of trust must be a long-term credential. Otherwise, if all temporary credentials have expired, how is the user authenticated in order to generate a new one? What would stop anyone else from going through the same process for the user?
An individual service can outsource user authentication: they can email a code, use SMS or a voice call, or integrate with a third party service like Okta or any OAuth provider. In those cases, the long-term exists, but the actual location of the key store is externalized. Then the service is at the mercy of the security of that key store. Email is probably low risk for normal people, who have an account with multi-factor authentication at a large provider who’s going to notice ‘unusual’ logins, but my quirky personal email isn’t like that.
The other problem with outsourcing is that if the provider changes their mind about account requirements, users can get locked out of both their email and their service account at the same time. (Ask someone how hard it is to maintain a secondary Google account.)
Everything else is a long-term credential stored by the service. Passwords need their hash to be checked against. Passkeys, authenticator app codes, and client certificates are also linked to a user account, so must be stored with it. The service cannot accept any of these things for the wrong user.
No comments:
Post a Comment