[nananana9]

Requiring "tokens" stored in "trusted modules" and 7-factor-auth for everything is not progress, it's theater. The biggest achievement of the security orthodoxy was locking me out of my email, by requiring me to read a code sent to my email to log into my email.

I -- literally -- do not care about a single "account" in any "service" I use aside from my email and bank account. Most people would add a few social media accounts to that list.

You don't need a "place to put secrets". Your iPhone app does not do anything important enough to require a "trusted chain" of cryptographic bullshit, just use a password and Google/Apple login.

[miki123211]

Your accounts are valuable, even if they're not valuable to you.

An old account with typical activity patterns can be extended some level of trust. If you sign up for an email address and immediately send a message with 100 recipients in CC, you're probably a spammer, so you get blocked. If you've used the account for years, ehh it's probably invitations to your high-school reunion or a donation drive for your Church, let's let this one through.

You can only extend this level of trust if you prevent your gullible users from constantly getting hacked; 2FA is one way to do that.

[EtienneK]

Passkeys are better passwords. They need a TPM.

[adev_]

> Passkeys are better passwords. They need a TPM.

Passkeys absolutely do not need TPM.

You can get passkey support in any browser with a simple 1password plugin without any TPM hardware.

The same way you could get a TOTP app on your phone without any TPM.

TPMs are just an extra security layer for most usages.

They are mainly a necessity for some shady business like DRMs.

[loup-vaillant]

> Passkeys absolutely do not need TPM.

They do not, but how does the service you’re using know your passkey is secure? For all they know you’re just some gullible user that clicks through every fishing email you get. You’re dumb, weak, helpless, they gotta protect you from this scary world out there, and maybe yourself as well.

They can’t do that if they allow your passkey to be stored anywhere you control. KeepassXC? The second you type in your master password the keylogger will snatch it, and your entire database with it!

Okay, maybe you’re some hot shot cryptographer, you’re using a TKey (think Yubikey, except you have full control), and there’s no way your secret key leaves it even if your main computer is fully compromised. Well, the service doesn’t know that. All they see is your public key and a matching signature.

So, sorry Mr. Security Researcher, we’re gonna have to be safe, and require you to use approved hardware only. Too many (wo)men children out there must be protected, we have no way to tell you’re not one of them, so it’s remote attestation or you’re out. What’ online buying worth for anyway, when you can just cross the ocean?

---

Just so we’re clear, I agree with you here. But don’t forget there are two kinds of passkeys out there: with or without the evil remote attestation. And many companies will push for the remotely attested kind, using the exact argument I used above, except with a straight face.

Or they will just present a false dichotomy: remotely attested passkeys on the one hand, short easy to guess reused everywhere passwords on the other.

[Ajedi32]

> how does the service you’re using know your passkey is secure

That's my business, not theirs. If my password gets stolen, that's my problem, not my bank's. Same deal if my passkey gets stolen. They're welcome to try to educate me on good security hygiene if they want, but what hardware I use to secure my credentials is not something they should get to decide.

[loup-vaillant]

On principle I agree with you. And for me I totally want that, in part because I know how to take care of myself and avoid phishing (I got pwned once, but thankfully it was my company’s honey pot, not actual phishing).

Many people aren’t like us. Give them freedom to chose their password without mandating 2FA, and some will lose money to a password database leak & offline guessing. The policy maker knows this, at which point they have a choice: stricter annoying rules with fewer victims, or looser rules with more victims?

Yes, we can mitigate much of this with education, as can we limit vendor lock-in by mandating that the bank does not require any particular device they do not themselves distribute, for free, to their users. (My bank for instance gave me a little device that has a camera, a small screen and a key pad. Upon payment I use the device to scan some QR-code, the device gives me a one-time code that I type, and done.) My point is, some kind of tradeoff remains.

Also banks kinda have to deal with fraud, which presumably costs them money. Stolen passwords mean more fraud, increased costs… that may be incentive enough to enforce stricter rules. And to be honest I’m okay with that, as long as it is accessible. Which in my case means no phone app of any kind.

Come to think of it, there is one law I would pass: for important stuff like banks, no amount of security justifies a lack of accessibility. If I don’t have a smartphone, I should still be able to do online payments. Same if I’m blind. Or both. When I hear all around me about people being utterly unable to do banking, or worse, accessing government online services, without a locked down Android or iOS phone, I’m horrified.

[Ajedi32]

> they have a choice: stricter annoying rules with fewer victims, or looser rules with more victims?

Yep, there's a reason freedom vs safety (or libertarianism vs authoritarianism) is an axis on many political spectrum charts. This is a very common source of tension in politics. As you can probably guess, I usually find myself on the libertarian side of such debates. Freedom is worth the price.

> Give them freedom to chose their password without mandating 2FA, and some will lose money to a password database leak & offline guessing

To be clear, I have no issue with secure defaults. There's only an issue when you start trying to make it impossible for users to compromise their own security, because accomplishing that requires you to take away their freedom to make choices, which I don't think is an acceptable thing to do to mentally sound adults.

There's plenty of competition in the banking space, so normally I'd be fine letting banks and their customers sort this out on their own. But there's not a lot of competition in the OS space, and allowing banks to limit your choice of OS exacerbates that problem.

The fix I've been floating in my head for some time now for a lot of these types of problems in the digital space is some sort of software freedom law guaranteeing users the right to modify software running on devices they own. It would fix so many issues with the software industry, including probably this one, since many common uses of hardware attestation would probably fall afoul of such a law.

[jcgl]

> For all they know you’re just some gullible user that clicks through every fishing email you get.

Passkeys are non-phishable. That's part of their schtick. I'm not a huge passkey fan myself, but this is a real benefit.

[loup-vaillant]

Yes, but that’s not the threat model I was alluding to. The threat model was, you get tricked into executing malware, that will steal your passkey (and your entire password database in fact), and log your master password as soon as you use it.

When the passkey is protected behind an HSM (TPM, Yubikey, Tkey…), even a compromise of your main computer can’t steal it. Attackers can still temporarily log in on your behalf, but they can’t do anything with your passkey as long as your computer is turned off. Which means you can un-pwn yourself out of this situation by reinstalling everything (but do keep your HSM!).

Overall, we have several levels of security here:

- Weak password, (potentially reused everywhere). Fished once, pwned everywhere. Not to mention password database leaks.

- Very strong unique password from your password vault (KeepassXC). Note that with automatic login, password managers may provide good phishing resistance. Manual copy pasta is still vulnerable, but at least you only compromise that one account.

- Passkey stored in your password database. Phishing proof as you say, but falls to a keylogger.

- Passkey sorted in a hardware security module. Can’t be stolen ever, save for a vulnerability in the HSM itself, or, if you haven’t set up a password for your HSM, theft.

Clearly that last option is the most secure. Clearly it would be nice if everyone could do that, though we do need a way to recover from the loss or destruction of the HSM (which in the case of the TPM may mean something as mundane as changing your graphics card). Yet often, other ways are more convenient.

Still, I strongly believe companies should not force people into one method or another. Okay, I could maybe tolerate passkeys being forced on me, but not the remote attestation part. Let me manage my own security, with my own tools (preferably open source), thank you very much. There is one use case for which I may approve of remote attestation: work accounts. Because at this point it’s not about the safety of the customer, it’s about the safety of the company itself. It makes sense then that the company (or government agency) impose whatever stringent restrictions on how to access their network. They do have to provide any required tool (company laptop, company palmtop, company dongle…), same way many companies are required to provide individual safety equipment to any of their employees working in hazardous environments.

[jcgl]

Yes, I agree that device-bound credentials (DBC?) are a really big deal here. Just wanted to get the story straight.

When it comes to the notion of requiring DBCs without also requiring remote attestation, how do you deal with solving the problem of virtualized credential devices, e.g. swtpm? If some application wants to leverage DBCs, it will make some DBC API call, e.g. call out to a TPM. However, without some sort of attestation scheme, there's no way to verify who/what is on the other end of that API call.

Maybe it's not important for applications to be able to require DBCs without attestation. But at first blush it seems like a valid thing to want.

[miki123211]

TPMS give you the convenience of short passwords (or no passwords) and the security of long keys.

A chip which you can write to and interact with but can't read is valuable; it lets you enforce conditions which you otherwise couldn't. For example, you can protect your sensitive data with a 6-digit pin, secure in the knowledge that the chip will erase the encryption key after 10 failed attempts. If you had full access to the TPM storage, you could brute force that PIN in seconds.

[vbezhenar]

Run vaultwarden locally. Install bitwarden. Now you have software-only implementation of passkey. Dig into vaultwarden sqlite database and you'll find passkey data there. Extract and save it on disk and you have exportable passkey. See, it's all security theater without remote attestation.

I had an idea to create blatantly insecure passkey browser extension. Maybe I should do that.

[JambalayaJimbo]

What about Apple Wallet?

The reality is that there is software dependent on the user being unable to modify it. This safeguards the server against fraudulent users.

[well_ackshually]

The one that's so incredibly broken that Apple and Visa keep blaming eachother when they get a report that you can steal any amount by making yourself pass as a transit card ? Cool security theater. https://hackernoon.com/veritasium-stole-$10000-from-mkbhds-l...

[JambalayaJimbo]

This just sounds like a bug. Haven’t delved too deep into it technically though.

Anyway flawed implementation doesn’t mean that hardware attestation is a fundamentally useless primitive. Apple Wallet is responsible for millions of transactions a day.

[customguy]

Never trust user input. The users already can't modify the server.

And what actual applications did you have in mind that warrant throwing everybody under the bus? (by that I mean some applications (allegedly) need it, so it gets forced on everyone)

[JambalayaJimbo]

My banking app already trusts Face ID right now!

[customguy]

And how is that necessary? It's a convenience feature, nothing more. You might as well trust your bank with your biometric data directly, and leave me and others out of it either way. Even IF there was a real need for a mobile device with which general computing is not possible, that would not justify killing it everywhere just so people who do need it can "just use their phone".

That the laziest of us don't mind and the worst of us want something is not a respectable argument for anything, ever.

[JambalayaJimbo]

So first of all, usability features are security features. There is the classic example of an uncrackable 18 character random password string that only results in frequent password reset attempts and the bank’s support staff getting totally overwhelmed.

We can have a discussion about FaceID specifically, but “convenience” is not considered trivial within the security sphere.

Second, I work for a (very large) bank, and you actually do not want to trust them with your biometric data directly. You can be absolutely assured of the privacy of your biometric data with the bank, better than with a Silicon Valley tech company. But I would not trust the bank’s data scientists to come up with a model that will not have an extremely high rate of false positives and negatives.

The reality is, if such an initiative was started at a bank, it would be shuttered after years of delays.