141–150 of 172 posts
Bitwarden is underrated. Passwords run everything in our digital life. I will gladly take a UI compromise here and there for more trustworthiness.
Earlier quoted context omitted.
Any half decent sophisticated user on the internet has not remembered passwords for half a decade at least. Nearly everyone is storing it in password managers. So has that changed passwords into not being “thing you know”?
So has that changed passwords into not being “thing you know”? Yes? If you write your password down on a piece of paper it becomes something you have, no?
An app generating OTP codes is a TYH while the secret used to generate the token is a TYK.
A password manager is a TYH while the passwords inside are TYK
In general every (non-quantum) TYH possess some kind of TYK that can be used to duplicate the TYH.
In the name of security sometimes there are locks around the TYK, sometimes physical other times software.
In the case of passkeys the inability to export them makes them TYH.
* "Thing you have" is too long
Earlier quoted context omitted.
So has that changed passwords into not being “thing you know”? Yes? If you write your password down on a piece of paper it becomes something you have, no?
The server is not checking if you have a piece of paper. It is checking if you can produce a piece of information. If someone steals your paper, copies the password to their phone, and then returns your paper, then the attacker can log in without that piece of paper. In a true "something you have" if you have that something then it is impossible for someone to login to your account.
PS: I suspect that you could make a 2FA protocol capable of detecting duplication of the thing you have by having the app generate signed codes like "this is the n-th code I have generated" and have the server remember the n as a logical clock to detect duplicates and "time travel".
AFAIK only bank-type apps would use something this sophisticated
Earlier quoted context omitted.
> But essentially it's a certificate... I'll put upfront that I'm no expert in any of this, but ... unlike passwords and certificates, attestation is a thing for passkeys. The thing being attested to is "the private key of this cert is being secured by X". X might be YubiKey in the case of a FIDO2 key, or Google or Apple in the case of passkeys. This aspect of passkeys made me uncomfortable with them. If Google is go…
Yep. The end game of this is that web applications will, either through laziness or a sense of 'better security', only accept passkeys attested by Google/Apple/MS and/or those backed by TPM with non-exportable keys. You have to register with the FIDO Alliance to obtain an attestation GUID, and unsurprisingly, only the big guys are on the list: https://github.com/passkeydeveloper/passkey-authenticator-aa... This move…
It also says: "It is not intended to be used for any other purpose and could go away at any time."
Finally it looks like anyone can contribute attached to an implementation according to the Readme
Earlier quoted context omitted.
You're not really vulnerable to phishing if you use a password manager with a browser extension. Cross-platform import/export for passkeys is considered a "nice-to-have" because you can always just add a new device via other established factors (email/SMS). So, what's the point, then? Why can't passkeys just be strings that I can extract via biometric authentication? The answer: everyone pushing this has a significan…
> Why can't passkeys just be strings that I can extract via biometric authentication? As much as that lock-in annoys me personally – I could absolutely see this become a tech support scam attack vector. "Please share your passkey with us for authentication by going to your device's settings and selecting the 'export passkey' option"... > you can always just add a new device via other established factors (email/SMS) T…
Earlier quoted context omitted.
It is special - it should be a reference to an asymmetric key stored in hardware. But it's not clear whether they are actually doing this.
If it is just a pointer a hardware, even more reason to let you export it.
Kind of like how you should generate SSH private keys on the local machine and never leave this particular system, and you then add their public keys to the server you will connect to. You can them revoke access to each machine independently.
Earlier quoted context omitted.
> "Please share your passkey with us for authentication by going to your device's settings and selecting the 'export passkey' option" This doesn't seem materially different from "please go to your emails and find the six-digit code we just sent you". > Exporting a passkey leaves no relying-party-side traces. Not if it's only useful for getting a device-bound session token. Everything you listed is already commonplace…
>This doesn't seem materially different from "please go to your emails and find the six-digit code we just sent you". Exactly, that's the problem lxgr is pointing out. Those six-digit codes can (and often are) phished by e.g. tech support scam attackers. lxgr is pointing out the same exact attack could be done against an exported passkey.
We have to rename and re-enroll your device token so your laptop can still log in.
Click “I registered this credential” when you get the alert about it so your old credential that you added before will still work.
Is harder to pull off than:
Go to your password manager and export the entire database locally stored passwords. Now, print it out and read this 200 character string to me over the phone, or just email the file to me.
Earlier quoted context omitted.
Mobile BW app also wouldn't fill a password for a different domain
Can confirm this. Additionally, the Bitwarden app on mobiles also checks the app name (i.e. the 'com.company.appname' not the 'user friendly' name). It takes an extra step to 'force' Bitwarden to use a username/password if the name/domain does not match the name/domain(s) recorded against the username/password which adds a nice bit of friction.
perhaps a better link? https://bitwarden.com/help/storing-passkeys/ Not sure if passkeys are supported on iOS or Android (only the browser extension is explicitly mentioned) and also they cannot be imported or exported according to the page.
Earlier quoted context omitted.
It comes from the fact there are three fundamental ways to authenticate: a thing you know, a thing you have, a thing you are. You may not "know" a passkey or a TOTP token, but you are using computers in their most fundamental role as bicycles for the mind to "know" them for you. This means they still fit into "thing you know". Clearly a TOTP token is not a thing you are. Less clearly, it is not a thing you have. Pass…
Yep. Thing you have is a passkey that can't be copied at all, like a yuibikey, some physical manifestation that can't be easily cloned. Arguably TOTP is "have" due to being linked to a phone when doing push to a single device.
And this is what I referred to by the "things you have" being just "things you know" wrapped in obscurity in practice. If you know the contents of a yubikey, you could store those in your password manager and use the password manager to emulate it.
Mind you, it can be good, solid obscurity. It's fun and educational to read about all the security in your yubikey, and certainly to me in practice it is a "thing I have" because I'm thousands of dollar's worth of hardware and weeks/months/years short of the requisite skills to penetrate one.
But there is still a sense in which it fails to be the platonic manifestation of a true "thing you have" because underneath the hood it's still a thing you know. At scale this matters.
At scale, biometrics also has the problem of becoming a thing you know. Again, in the platonically perfect world where, I dunno, authentication mechanisms have access to Star Trek transporters and can analyze you down to the atomic level to be sure you are you (though even Star Trek had trouble with the shapeshifters in Deep Space 9!), then, yes, it would be truly a "thing you are". But in the real world, where a biometric auth still involves presenting a sensor with some sort of input that it will agree is you, it still degenerates into a "thing you know" as you try to scale the system up. You can make it more and more difficult to fool the sensor, but then, that raises the price of the sensor and the risk of false negatives, both of which make it hard as you scale up. Which is why I think biometrics authentication is very powerful, but generally should be reserved for very important things and used as a mix of other methods, or, alternatively, used for things that hardly matter at all, but I think it's quite dangerous in the vast middle. I would be very concerned if my bank account could have arbitrary operations done on it just by presenting my fingerprint.
I don't actually mean this as "criticism" of things you know and things you are, because, like I've said in both cases, they do have their uses in the real world. I just think if you want to deeply understand the question of authentication, as they scale up, they all turn into a "thing you know" for a sufficiently motivated attacker, and in the discussions we have on HN we are generally talking about the largest possible scales, so this matters. I think that's an important aspect of understanding these systems, using them for security, understanding the attack surfaces and likelihoods, and properly modeling them. I see a lot of people making bad cost/benefit analyses because, for instance, they don't realize that biometrics are in the end a "thing you know" and that fingerprints can be faked, faces can be faked, etc., and that you can't model them as what you'd really like a platonic "thing you are" to be. They degenerate into "thing you know" at quite practical scales, depending on what goodies you are keeping behind those authentication barriers.