You Shall Not Password: Modern Authentication for Web Apps - Eli Holderness - Copenhagen DevFest
Vložit
- čas přidán 27. 08. 2024
- This talk was recorded at NDC's Copenhagen Developer's Festival. #cphdevfest #ndcconferences #security #web #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences...
cphdevfest.com/
Subscribe to our CZcams channel and learn every day:
/@NDC
In the good old days, your users would log into a web app with a username and password. But now people expect an alphabet soup of SSO, 2FA, OAuth, OIDC, SAML, FIDO2, OTP... What do they all mean - and why do they matter? Why is central authentication useful? What does two-factor authentication really protect us from, and what's still wide open? Learn how to keep your users safe as we discuss the good, the bad and the ugly of modern authentication mechanisms for the Web.
This talk is aimed at anyone passingly familiar with web development, with an interest in security, or who simply wants to know what’s really going on when you ‘sign in with Google’.
SAML sounds like the authentication version of SOAP 😅
At 34:00, you don't need to go to the introspection endpoint with a JWT at all. The JWKs for the IdP are available at a discovery document URL that all applications can parse and then verify the signature of the JWT with, and the expiration time it's in the token itself as well.
The introspection endpoint is usually used when a token is opaque (as in, a random string and not JWT) or when the IdP allows token revocation.
The easiest solution is already out there for years: public key auth like done in ssh.
Browsers could assist for example with a wizzard on first start to "create or import an identity" which then can be used to login to services and can be easily exported to other devices.
There is no need to hide the key from the user or sync it to public clouds.
Sure its not as comfortable as passkeys but I consider every key which is stored outside of my systems as compromised.
starts at @2:15
yeah, the passkey stuff isn't quite right. Passkeys only need a user-verifying (PIN, biometrics, etc) platform authenticator, no account with an IDP or cloud connection required. That said: the platform authenticators for iOS/macOS and Android devices (Windows coming Soon™) have the ability to sync passkeys through the OS developer's account system. It's not required, but it means that losing the device doesn't mean you lose your keys.
thanks for the correction! I should be much clearer in the talk - the UX part I was trying to differentiate was precisely what you mention in that hardware loss =/= account access loss when syncing with cloud, but local-only passkeys are still worthwhile for other reasons
Great explanation
Passkey is kinda like SQRL, but much worse.
Even long and random passwords are not necessarily secure. The problem is that they are always sent in clear text to the server with the web app, so if an attacker manages to compromise the web app itself, the passwords can be collected during the login process.
https prevents passwords from being sent in plaintext
Nobody is sending passwords in clear text nowadays, it's not only stupid but also forbidden by legislation like the GDPR. But even before GDPR and even before TLS 1.3 was used widely, we didn't send plain text passwords. We hashed the passwords on the client with a custom challenge coming from the server, then the client sent the resulting hash back. If a cryptographically secure hashing algorithm is used, there's no realistic way to reverse the calculations and get the plain text passwords back. Alternatively, you can do key exchanges like diffie-hellman, which are designed to be safe even when an MITM reads everything.
Where ever you got your information from is very likely 2 or more decades behind.
@@_DATA_EXPUNGED_ big +1 for diffie-hellman. It's so simple and yet it works, I love it
+Plus