151–160 of 182 posts
https://blog.millerti.me/2023/01/22/encrypting-data-in-the-b...
Earlier quoted context omitted.
Interesting take on 2FA. The user not being able to screw up is of course important, but the second factor (something you have) works primarily because it is tied to something physical and therefore local to the user, which is not subject to remote attacks.
The average user is not typically subject to remote attacks. There are exceptions of course. However we should design the default security experience for the threats the average user faces. Most users aren't being targeted by the NSA, etc. Unless you mean the webserver they use being attacked, but that is just as vulnerable for 2fa. The only difference is the user cannot screw up and use the same credential on multip…
Earlier quoted context omitted.
Don’t most people that this this “correctly” use a password manager which stores passwords on the same device as stores the totp token and generates the one time code? Doesn’t this effectively turn your password into a device that you have, effectively turning the first factor ( something you know ) into something you have , while the second factor ( something you have ) is the same thing you have from the first fact…
I'm not sure about "most people", but I for one never stored 2FA tokens on the same device as my passwords. My password manager is only on my desktop/laptop, and my 2FA tokens only live on my smartphone/Yubikey. Storing both on one device sounds like a pretty stupid thing to do. Sure, it's convenient, but you are putting a looooot of trust into the assumption that your single device will never be compromised.
My guess as someone who's been in a position to implement it a few times but haven't gotten to: - "Upstream" Support, For various combinations of stacks I've worked on, there has always been one component that didn't support it cleanly, (Flutter x Ory was my last attempt for example). If it was as easy as "just" enabling it I'm sure it'd be more popular, but when your provider or tech stack doesn't support it out of…
What was the issue with Flutter and Ory?
Ory provides a javascript bundle you load to do webauthn, which (again IIRC) didn't work inside the browser inside the app, and although we figured out some workarounds, would have conflicted with how we implemented the native auth.
Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. Now that there's something a little bit looser, there's some small hope WebAuthn starts to become interesting & viable. https://developer.chrome.com/blog/webauthn-conditi…
So instead of having a physical device you own act as a second factor, you are now vendor-locked to a proprietary authentication solution for the entire login process. No thank you! The entire point of two-factor authentication is to have, well, two factors: something you know and something you have . Using the PC itself as token was already problematic enough as it has a massive code base and runs all sorts of untru…
If I could make a backup of those keys, I would have been happy with physical devices.
But every time I make an account somewhere, I have to go add devices in triplicate? Ugh it was such an abysmal terrible experience. Physical devices are just too unreliable & too constrained as systems.
Passkeys, to my knowledge, are an extension of FIDO Alliance standards. My hope is that one can bring your own provider. This would avoid the vendor lock that has you quaking.
Earlier quoted context omitted.
So instead of having a physical device you own act as a second factor, you are now vendor-locked to a proprietary authentication solution for the entire login process. No thank you! The entire point of two-factor authentication is to have, well, two factors: something you know and something you have . Using the PC itself as token was already problematic enough as it has a massive code base and runs all sorts of untru…
Not only that. It defeats the purpose of using a dedicated device.
Earlier quoted context omitted.
That’s the trade off being made for convenience. It’s still somewhat multifactor though (I’ve seen people call it 1.5FA); authentication codes have the benefit of being resilient to replay. So, you’re not pwned even if someone steals your password somehow. Even if someone steals your phone, you should have a passcode. If they know or guess your passcode, well… someone could steal your house/car keys too, and we still…
If we are assuming that the password manager is on the same device used to login, a replay attack is bordering on rediculous. In this scenario, you are assuming that the client is not compromised (since otherwise they would just steal it before you use it) the server is not compromised (otherwise what is the point), you do not have an active mitm (otherwise they could use the token directly instead of replaying). All…
Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. Now that there's something a little bit looser, there's some small hope WebAuthn starts to become interesting & viable. https://developer.chrome.com/blog/webauthn-conditi…
Also now your Windows Hello PIN and your screen unlock PIN on Android will be your master password to all websites. That's a huge new risk for real people. On Windows they don't even bother making a password option which could at least imply that a longer PIN is possible. Windows also asks for the same everytime which strongly encourages making it short. Although I suppose nobody cares because isn't your PIN already…
It's an intelligent trade-off, of course, in threat models that involve access to the physical device for threat models that involve remote access of websites and other resources. Yes, if everything uses the same PIN on a device then that adds to the risk of someone snooping your PIN, stealing your device, and accessing many things in the process. If that is the threat model that most concerns you, then yes, this makes things worse. But PINs can't be used remotely at all and never transfer across a wire. They can't be brute forced remotely over the internet. Having someone's PIN but not the specific device that the PIN unlocks doesn't unlock anything (because you still don't have access to any of the private keys on the device without the device). Websites only know your device's public keys. If you use entirely WebAuthn, breached websites only leak public keys. If your threat model involves concerns about internet hackers or the daily breaches we see in services like haveibeenpwned, device-specific PINs are a massive improvement.
Earlier quoted context omitted.
You also won't have access to the TOTP backup of emergency codes.. If you get hit on the head or have the trauma of your life you might not have a password. These are tradeoffs that people use to balance security. Many people will lose to a sim swap despite not needing access to their life savings while on vacation with absolutely no proof of identity and a fallible memory.
> TOTP backup of emergency codes These are encrypted in my password manager that is sync'd to the cloud. I only have 1 password and 1 backup code I need to memorize.
Earlier quoted context omitted.
Firefox syncs passwords, not keys. Passwords can be reused, stolen, or leaked, all of which cannot be done to WebAuthn keys.
If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked. Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.
Some vendors may also add "recovery" public keys to those synced keychains so that you can "Forget Password" your way out of a lost device or locked account or bootstrap new devices, and you have to trust your chosen vendor's security for how they manage that private key for any "recovery" keys.
But my impression is that there isn't anything that Passkeys is doing that you couldn't do by also collecting Yubikey public keys by hand and making your own keychains if you are sufficiently motivated.