[jerf]

I hope they get over that. It's a blob of data. It's no more special than a TOTP secret or a conventional password, and I am completely uninterested in pretending otherwise because of a slick marketing campaign. It's a "thing I know" whether anybody likes it or not and you can't turn it into a "thing I have" just because you won't let me export it from this particular software. (Proof that it is a "thing I know": It fits into Bitwarden, which is a "thing I know" storage mechanism. Anything that can be stored by BitWarden is a thing-I-know.) As long as it's a thing I know you might as well give me the benefits of being a thing I know, since I'm paying the costs of it anyhow.

I back up at the Vaultwarden backend store level anyhow. Probably shouldn't give me that sort of advantage over the commercial option.

[noman-land]

I see this common refrain from people. How is writing something down so that you don't have to remember it a "thing you know"? You literally don't know it. A "thing you know" never leaves your brain, otherwise it becomes a "thing you have".

[jerf]

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. Passkeys and TOTP tokens "want" to be a thing you have, but in the end they aren't. My little proof in my parent post may be small, but I'm quite serious... if you can store it in a password manager, that is proof that it is a thing you know, not a thing you have.

It turns out making a "thing you have" be a true thing you have is very difficult. It may even be impossible, in some sense. Everything that is a "thing you have" seems to be a thing you know masquerading as a thing you have through some security-through-obscurity.

Between that and the fact that "thing you are" has incredibly poor, if not outright dangerous characteristics if you try to scale it up, I'm actually not on board with the "passwords suck because things-you-know suck and we must replace them immediately!" I think they whole argument stinks of a classic engineering mistake of considering only the pros of one option and only the cons of another. I think when you take a holistic view, "thing you know" is the only practical, scalable option of the three basic options. If passkeys make it easier, fine, I'm up for some improvement, but I'm not on board the "passkeys must be a thing you have" and I fully intend to use them as things I know as much as I can and have no intention of letting anyone make my passkeys into objects.

[unethical_ban]

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.

[lolinder]

Nit: TOTP doesn't include push methods of 2FA, it specifically refers to the algorithm for producing one-time passcodes from the current time and a secret key.

[Spivak]

TOTP is just PAKE with a funny way of writing the password.

We tricked people into using actually secure passwords and password managers by calling it 2FA and devising a scheme where the human does the challenge and the server necessarily must keep that part of the password in plaintext, but in exchange the user doesn't have to type out the long part of the password every time.

[lxgr]

No, TOTP is a weaker version challenge-response authentication (with the challenge being time-based and not provided by the verifying/challenging party).

PAKEs do significantly more; in particular, they are MITM resistant (unlike TOTPs) and provide mutual authentication.

[jerf]

"like a yuibikey, some physical manifestation that can't be easily cloned"

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.

[SAI_Peregrinus]

> there are three fundamental ways to authenticate: a thing you know, a thing you have, a thing you are.

Rather observations of each of those things. A "thing you are" is in practice just a "thing you have". You have a finger, with a fingerprint on it. That gets measured, and that measurement can be faked or your finger can be taken from you.

And of course "things you have" can usually be duplicated with sufficient effort. Even "physically unclonable functions" just rely on process variation in semiconductor manufacturing, with sufficient effort (FIB workstation for manual trimming) it's likely possible to clone even those.

[addicted]

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”?

[noman-land]

  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?

[afiori]

Protocol-wise the difference is that a TYH* requires an interaction by the user.

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

[charcircuit]

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.

[afiori]

I agree with the general sentiment but every non-quantum "thing you have" can be duplicated.

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

[charcircuit]

>but every non-quantum "thing you have" can be duplicated.

Not easily. Extracting keys from hardware keys is very hard to do.

[GoblinSlayer]

Password database is often protected with a master password, so accessing it requires a thing you know.

[Racing0461]

Agreed. unless its stored in a tpm module or on an actual piece of hardware like a yubikey, no amount of software (especially a browser plugin written in javascript let alone low level drivers for an OS) can turn a "thing i know" into a "thing i have".

[SheinhardtWigCo]

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.

[ryan29]

Some snippets from the FAQ [1].

> The public key is stored on the website and the private key is stored on your device or in your passkey provider, e.g. your Bitwarden Vault.

> Passkeys are often able to sync across your devices, however not all platforms support this yet.

So it sounds like it's not stored in hardware. It'll be interesting to see how it works if solutions that use a TPM or similar start to emerge. I have nearly 1000 passwords and many of them are shared with colleagues, parents, siblings, etc.. I can't even imagine a way you could make that work if the private key is owned by a TPM (aka a hardware bound key) and needs to be enrolled somehow prior to becoming usable.

What happens if I have 500 passkeys backed by keys in a TPM and I get a new computer?

1. https://bitwarden.com/resources/passkeys-faq/

[tw04]

> What happens if I have 500 passkeys backed by keys in a TPM and I get a new computer?

In theory the same thing that happens today with a yubikey - you have multiple devices with valid keys.

[Groxx]

A big part of passkeys is that they are (often) not in hardware, so they can be synced.

[SV_BubbleTime]

If it is just a pointer a hardware, even more reason to let you export it.

[m-p-3]

The idea is that the key never, EVER leave the hardware or password manager. What you do is have multiple Passkeys on separate devices per account.

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.

[jopsen]

From: https://bitwarden.com/help/storing-passkeys/

> Saving and using passkeys are a feature of the Bitwarden browser extension. Other Bitwarden clients can be used to view the saved passkey.

So sadly, like TOTP I can't trust bitwarden to only keep my keys in an HSM on the server.

I really wish exporting would be impossible. Today, I need to add my primary and backup passkey devices whenever I signup for a service.

If keys were only stored on the server, then I could use it as a level of indirection.