121–130 of 816 posts
Wholeheartedly agree, however The Changelog Podcast helped shift my perspective on this. It's really about not having the responsibility of storing and maintaining passwords.
So there are two complaints about this authn scheme that I'm seeing in this thread: 1. It's pretty phishable. I think this is mostly solved, or at least greatly mitigated, by using a Slack-style magic sign-in link instead of a code that you have the user manually enter into the trusted UI. A phisher would have to get the user to copy-paste the URL from the email into their UI, instead of clicking the link or copy-pas…
Two problems I’ve encountered with magic links: * Mobile email clients that open links in an embedded browser. This confuses some people. From their perspective they never stay logged in, because every time they open their regular browser they don’t have a session (because it was created in the embedded browser) and have to request a login link again. * Some people don’t have their email on the device they want to lo…
A passphrase is basically like a password in the sense that I can lose it, but it's not like a password in the sense that I can actually memorise it. (Or rather, all of them)
I prefer my passwordstore workflow.
I remember two passwords, the rest is kept save for me and unlocked when I need them.
It's not perfect, but it's by far the least worse solution of them all.
The attack pattern is: 1) User goes to BAD website and signs up. 2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.” 3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email. 4) GOOD sends a one-time login code email to the user’s email address. 5) The user is very likely to trust…
I don’t like passkeys. Before my process to login was: - open website - if not already logged in, log in to 1Password - autofill password - autofill TOTP Now: - open website - if logged in to 1Password the Use Passkey usually shows up - if not: - log in to 1Password - choose use passkey - this almost always does nothing - choose “use other method” - choose “password” - autofill that - now there is another dialog to c…
Apple Passwords now sufficiently good to replace 1Password for me and I’m slowly transitioning.
I don’t mind subscription models per se but there was something about subscription for your own passwords that made me refuse to jump the fence when 1Password switched to that model.
Would be a bit faffy if you’re a Chrome user.
The attack pattern is: 1) User goes to BAD website and signs up. 2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.” 3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email. 4) GOOD sends a one-time login code email to the user’s email address. 5) The user is very likely to trust…
Passkeys are still a shared secret, aren't they? Asymmetric cryptography would have been amazing. Barring that I would actually recommend Oauth or something like it, to limit the number of parties who manage shared secrets to a smaller set of actors who have more experience doing so.
Earlier quoted context omitted.
At the very least the spec should be painstakingly insistent on not requiring attestation unless implementors have really thought and understood the reasons why they need the security properties provided by attestation in their particular use case. And that it has to be something more meaningful than “be more secure this way” as security is not a rating (even though security ratings exist) but a set of properties, an…
I agree, but unfortunately the spec authors are already going out and dangling possible bans in front of projects who implement Passkeys in more user-friendly ways: https://github.com/keepassxreboot/keepassxc/issues/10407 > To be very honest here, you risk having KeePassXC blocked by relying parties But having a choice about how you store your credentials shouldn't depend on the good faith of service providers or the…
People forget that one of the purposes of authentication is to protect both the end user and the service operator.
Earlier quoted context omitted.
At the very least the spec should be painstakingly insistent on not requiring attestation unless implementors have really thought and understood the reasons why they need the security properties provided by attestation in their particular use case. And that it has to be something more meaningful than “be more secure this way” as security is not a rating (even though security ratings exist) but a set of properties, an…
I agree, but unfortunately the spec authors are already going out and dangling possible bans in front of projects who implement Passkeys in more user-friendly ways: https://github.com/keepassxreboot/keepassxc/issues/10407 > To be very honest here, you risk having KeePassXC blocked by relying parties But having a choice about how you store your credentials shouldn't depend on the good faith of service providers or the…
Earlier quoted context omitted.
You misread the short article. It's about email as single factor auth, which has become very trendy of late. You just enter your email address, no password, and the email you a code. Access to your email is the only authentication.
> It's about email as single factor auth, which has become very trendy of late I must be in the wrong bubble, I have not encountered any site that does this since the 2000s. It was a minor trend around then IIRC.