The author mentions this finding was marked as out-of-scope when they reported it to Bitwarden. A couple of categories that are considered out-of-scope are listed, namely: attacks requiring physical access to a user's device, and "other side of airtight hatchway"[0] type issues.
The latter seems reasonable, if the assumption is that the device is fully compromised, and ongoing surreptitious monitoring of user activity by an attacker is occurring.
However, users probably have the reasonable expectation that if their laptop is stolen, their device-local vault data(supposedly encrypted on disk) is not compromised as a result. Bitwarden should either disallow weak pins/pin-access altogether, or they should caveat more clearly the weaknesses of pin-only access to device-local vault data.
Exactly. So many people in this comments section are saying 'well obviously a pin can be cracked' but the point is, the average user does not know this. Once they give their information to Bitwarden, they expect it to be safe. They shouldn't have to understand the nuances of security in order to keep their data safe. If the pin can be cracked, Bitwarden should not offer it as an option or at least explain to users how vulnerable they will be before they enable it.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
If you’re using full-disk encryption (and you should be), this is less relevant, since the FDE is protecting you in case of theft. If you aren’t, the attacker can do anything, including copying the Bitwarden file and using a GPU farm to crack the master password.
Lots of people, perhaps the majority, still use master passwords that don't have a ton of entropy. For example, the bad guys that stole the LastPass vaults have definitely cracked a lot of the vaults that were protected with weaker master passwords.
1Password's approach is definitely the right one here, where the master key is basically a combination of the user's master password and a random 128 bit (I think it's 128) value, which does make cracking impossible. The user has to print out this value so that if they need to sign in on a new device that they can enter the value, so it adds a little friction, but 1P has the right idea that humans just can't be relied upon to generate and memorize high entropy strings, in general.
I’d bet (though in all fairness, only a low amount ;)) the intersection between a user that has both a weak master password and attackers willing to spend a ton to rent a GPU farm is pretty low, though.
My guess is that most people who have high value passwords also have weak passwords. CEOs and CFOs can probably authorize huge financial transactions with little oversight and tend to be security illiterate.
> However, users probably have the reasonable expectation that if their laptop is stolen, their device-local vault data(supposedly encrypted on disk) is not compromised as a result.
If you’re using a four-number pin to encrypt your data with no additional “padding” around that PIN, that is not a reasonable expectation.
However, I also don’t think that it’s reasonable that Bitwarden allows weak passphrases to begin with.
> users probably have the reasonable expectation that if their laptop is stolen
Yes, there is a significant difference between compromising a device with physical access and stealing the device. Disk encryption for example is very effective against the latter, but useless against the former. Having devices stolen is also far more common than targeted physical attacks.
The latter seems reasonable, if the assumption is that the device is fully compromised, and ongoing surreptitious monitoring of user activity by an attacker is occurring.
However, users probably have the reasonable expectation that if their laptop is stolen, their device-local vault data(supposedly encrypted on disk) is not compromised as a result. Bitwarden should either disallow weak pins/pin-access altogether, or they should caveat more clearly the weaknesses of pin-only access to device-local vault data.
[0]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...