Hacker News Reader

Comment by LorenPechtel | Hacker News Reader

A PIN is a de-facto very weak password. Of course it can be brute forced!

In the case of Windows Hello, a PIN is very different from a password (such as your live.com password). PINs are encrypted per-device, and are never transmitted from the device. They are resilient against rainbow table brute-forcing, and they generate asymmetric cryptographic key-pairs by using the device TPM.

So forget what you know about ATM PINs; this is a markedly different concept.

TIL

Thanks, when windows moved to the PIN I was wondering how that worked/ they kept it secure but still easy to login.

Indeed! They should have explained this much better when it was introduced.

But of course, Windows PIN was only needed when they made a local login a login to your Microsoft account, so your local password was suddenly transmitted to the internet.

Does the TPM limit retries or something? If it's a 4-6 digit number, you can just count upwards and try them all in a trivial amount of time.

Yes.

https://www.dell.com/support/kbdoc/en-us/000142311/tpm-failu...

> Does the TPM limit retries or something?

Yes.

TPMs have weaknesses, so this probably isn't a 100% guarantee depending on the attacker and the exact hardware, but it's pretty reliable (and very reliable if your attacker is reasonably small).

It can. TPMs have a "dictionary attack" (DA) protection feature.

You can't set the number of bad attempts that trip lockout, or how long to lock out for differently for different objects -- those are global configuration parameters. But you can configure which objects / policies require DA protection and which ones don't.

> So forget what you know about ATM PINs; this is a markedly different concept.

I mean it's actually the same concept (something you have, something you know) with a different implementation.

Indeed, which is why Bitwarden should disallow pin-only access for offline vault data altogether. Admittedly, I'm valuing a safe interface for users much more highly than one that is convenient or ergonomic.

It's the user's choice.

I mean, sure, but if the user isn’t appropriately informed of the risks (such as this attack) how would you expect them to make a good choice?

Currently it is, yes. In this case, I'm arguing that it should not be.

That would go against the nature of such software. Let's treat users as adults. There should be warnings. But this is a feature. Users shouldn't be able to eg. select weak crypto algos, there is no additional functionality in that. But setting whatever pin is a convenience, and users should be able to decide what threat vectors they accept.

If it’s n or convenient then users won’t use a password manager at all:

If you limit number of attempts, can it still be brute forced?

How can you enforce a limit when the decryption is done client side?

Using a TPM: https://en.wikipedia.org/wiki/Trusted_Platform_Module

TPM interdiction is readily possible.

Require a backup password when the TPM is offline.

I web searched it and found a dedicated wikipedia page https://en.wikipedia.org/wiki/Interdiction but I still can't figure out what TPM interdiction is supposed to mean

Anyway if a TPM was trivially bypassable then there would be no point to having them so I'm doubtful of whatever this off-hand comment is supposed to mean

I think they are talking about the definition under the Espionage section, i.e. a hardware supply chain attack:

> The term interdiction is also used by the NSA when an electronics shipment is secretly intercepted by an intelligence agency (domestic or foreign) for the purpose of implanting bugs before they reach their destination.

I read the original comment instead about sniffing the data path between the TPM and the user to get the PIN.

Which is just one way of circumventing the pin (keylogger will work on pass phrase too!). But that's not brute forcing the pin.

You can encrypt sessions to the TPM. To do that you need to securely know a public key for the TPM.

The protocol spoken to a TPM is like a micro-TLS. You get to encrypt, or not. You get to authenticate the TPM (like a server), or not. You get to do ephemeral-static key exchange (unlike TLS 1.3, which wants ephemeral-ephemeral key exchange). And you get to do PSK (password), and you get to do it in ways that are not subject to off-line dictionary attacks by eavesdroppers.

But you don't have to do encryption or authentication of the TPM, and the easiest thing to do is not to do either, which is what much software does. There's been this assumption that if it's on the motherboard, you can't mount active -or even just passive- attacks, but that is very much not true.

I really did not know what to read into the "TPM interdiction" comment in the context of bitwarden, but I've left comments elsewhere in this sub-thread.

You can generally sniff the LPC bus to the TPM. Even with TPM2.0+ that allows optional encryption on the transport layer, Windows dosn't bother using it.

https://pulsesecurity.co.nz/articles/TPM-sniffing

But I was referring more to a malicious software component between the data flow between the user interface and the TPM, even before the TPM's protocol stack is in the loop.

> You can generally sniff the LPC bus to the TPM.

Yes, quite, which is why it's important to use encrypted sessions to the TPM.

> Even with TPM2.0+ that allows optional encryption on the transport layer, Windows dosn't bother using it.

They really really should.

> But I was referring more to a malicious software component between the data flow between the user interface and the TPM, even before the TPM's protocol stack is in the loop.

For something like bitlocker or bitwarden you really need the unlock step to happen so early in boot (or wake) that the only vulnerabilities present are those in the blessed firmwares and kernel that you're running. Once you have the OS fully booted the possibility of executing malicious code that intercepts the UI to the TPM is just too great indeed.

There was a comment on another hacker news thread the other day that a difference between secure element and TPM is that the pin code is entered on the keyboard and passes through memory while with secure enclave, at least the biometric stuff is connected directly to the secure enclave instead. Maybe that's what

Some early/naive attacks in this category would be serial bus interposition.

TPMs are not 'trivially' bypassable. There's attacks on how they're used, naturally, but those wouldn't apply in this case. In this case the main issue is that once you've unlocked your storage keys you get to use them, and since storage keys need to be software keys to perform acceptably, you could even steal them. But if your device is off, a TPM would be more than adequate to protect local storage.

If you have a key object that is not extractable and can only be used and it is password protected, then you can't bypass the TPM. Once the key is unlocked (if you have access to the relevant session, which, you would) you can use it, which is bad enough if the rest of the system is compromised. There's also a concept of restricted keys that can only be used for things like quote signing (for attestation), or credential activation, which means the user doesn't get to specify exactly what to sign or decrypt.

If you couple all of that with running golden/blessed firmwares and OS, and you do secure boot, then you can be pretty certain (early in boot time anyways) that you're not running firmware/software you didn't want to assuming those are not themselves compromised.

Now, for local storage keys you really need those to be in software as a TPM can't perform well enough (not even an fTPM), and even if they did, an attacker could just decrypt local storage w/o having access to the raw keys as long as they can compromise your OS.

So, in a way you're right. But a TPM would still give you something that software-only solutions wouldn't: you get to refuse to enter the password and then the attacker has no choice but to apply rubber hose attacks or mount more expensive attacks on the TPM itself.

Chicken-little argument doesn't improve security.

Needs SecureEnclave, Android, and browser support to be comprehensive.

Using a smart card or compatible, nowadays often a TPM chip/SecureZone/Secure Enclave or similar.

Unless blocking brutes by IP, this creates a DoS to legitimate users.

Reply on news.ycombinator.com