Bitwarden PINs can be brute-forced
ambiso.github.io
ambiso.github.io
Protecting from an attacker with your laptop locked should be done at the OS level with FDE and secure boot. Protecting from a real attacker with access to your unlocked computer is a bit hopeless (as someone mentioned, they probably can install some key logger and steal the master password and everything else later).
It never hurts to be clear on the threat model (And they should probably go with the option 1. suggested by the author), but I feel in that case the behavior matches reasonable expectations and the author is a bit of bad faith.
For solution 2. if you want to check a pin server side without trivial access to the PIN from the server you can do it à la signal using secure enclaves https://signal.org/blog/secure-value-recovery/
This is obvious to those that know anything about security, but it is not obvious to the average user. It is Bitwarden's job to keep the user safe within their platform and if they provide a pin option, the average user knows no better than to use it. If Bitwarden does not explain how insecure pins are, then the fault 100% lies with them. Blaming the user is rarely ever an effective or useful argument.
OPs point was the pin isn’t protecting much at all because it doesn’t really need to. The user isn’t making a risky decision, because if the attacker gets as far as _being able to put the pin in_, the whole thing is toast regardless of guessing the pin or not
If Bitwarden could somehow implement the PIN attempt counter in secure hardware or on their server, they could achieve something more resistant against local offline brute force attacks.
A Yubikey could do the trick, theoretically (but unfortunately the FIDO API does not really lend itself to encryption, as it was designed only for authentication).
And it's not like there is much reason for any extra effort either, because that user will for sure be logged in to the webmail that they use for mail-2fa so all logins can be password reset anyway.
Still, I think that software in general, and security software in particular, should follow the principle of least surprise.
In the case of PINs, this is, in my view, an implicit contract to rate-limit invalid PIN attempts somewhere, regardless of all other security measures.
> We can use one, you or we when we are making generalisations and not referring to any one person in particular. When used like this, one, you and we can include the speaker or writer
https://dictionary.cambridge.org/grammar/british-grammar/pro...
Though that also begs the question, if I can get a keylogger onto your device, why wouldn’t I try to implant something slightly more capable?
How? I mean how can keylogger get the secret from which TOTPs are being generated?
And why wouldn't some other malware won't be able to read whatever data hardware token inputs? I'm myself yubikey user and would like to know in what ways it is more secure than TOTP, even in the scenario when my workstation gets compromised.
I assumed if someone can install something on my computer, I'm toast.
Since it’s time based with a 30 second window, you don’t need to know the secret, you just need to be able to repeat the code as it is typed. It takes more effort because it has to be done in real time, but 30-ish seconds is pretty doable.
> And why wouldn't some other malware won't be able to read whatever data hardware token inputs? I'm myself yubikey user and would like to know in what ways it is more secure than TOTP, even in the scenario when my workstation gets compromised.
The way (most) hardware tokens work, including the Yubikey, the private key is generated on the key and it never leaves the key. When the FIDO challenge/response happens, you relay the server’s challenge to the Yubikeu, it does the private key operation with the onboard chip, and sends back the response for you to relay back to the server. Done this way, your computer never needs to know the private key, but you can still prove you physically own it, which is what the server is trying to verify.
That said, just because they can’t steal your Yubikey’s private key, doesn’t mean they can’t take the bearer token from your computer. In general if your device is compromised it’s game over anyway.
When I press button on yubikey, it pastes some jibberish - way more than 6 chars, but can't THAT token be re-used?
Okay, browsers have some integrations with this stuff so it is not always some kind of a web form where that goes into, so could be a bit more secure.
I'm no security expert, I'm just thinking out loud and hoping someone educate me :)
Yeah, the end result (whatever header value or cookie in browser) is still readable by malware.
Just to be clear, that's not related to FIDO which I was originally talking about. That's one of the extra OTP features that most Yubikeys come with, but it's unrelated to the Yubikey's FIDO capability.
Every time some site ridiculously insists I "use a more secure password", I sigh and add "A1!$" to the end of my 32-character alphanumeric random string.
Never (only) encrypt things with a PIN.
Secure boot also doesn't matter because the boot time root kits are a rarity and trojaned downloaded SW (npm, homebrew, etc. nearly completely unprotected from malicious actors beyond the bare minimum) or the massive browser attack surface are what are actually used.
What would be nice is proper layered sandboxing at the OS level, always on, but obviously the kernel-userland ABI is not actually very secure in practice, and has been the source of recurring escapes. But at least it would be something.
Consider this: as it is, sophisticated users on, say, the MacOS platform, who download SW such as homebrew, youtube-dl, whatever, or do local development with npm and other package managers, are actually in a much worse place than unsophisticated users who run with "only from the app store" enabled.
This is not a good place to be.
There’s no “of course” about it. Every place I can think of having used a PIN in the last decade has not been susceptible to brute-force attacks, due to the PIN being stored off-site (e.g. payment card) or in a TPM (e.g. Windows Hello), and a few incorrect attempts triggering blocking of the payment card or PIN or whatever.
If you think carefully about the description of this specific feature, and where and how it’s running, then yes, you’ll probably realise that the PIN will be brute-forceable. But people are probably used to the idea that PINs actually aren’t susceptible to this kind of attack.
https://learn.microsoft.com/en-us/windows/security/identity-...
This is entirely non-obvious: there's several ways to implement a PIN unlock in a secure way (see e.g. what you mentioned about Signal and other comments about e.g. Windows Hello). Bitwarden chose an insecure one and to not warn about its risk in the clients (unlike some other features, where you get a big modal warning when enabling them; see the end of this comment).
> Protecting from a real attacker with access to your unlocked computer is a bit hopeless (as someone mentioned, they probably can install some key logger and steal the master password and everything else later).
This is a different attack scenario. If I throw away my computer, or you steal it in its powered off state, a keylogger won't help you since I won't be entering my password again.
> Protecting from an attacker with your laptop locked should be done at the OS level with FDE and secure boot.
Definitely, FDE and secure boot would mitigate the attack (if your computer is off). However it's still not enabled by default on most systems and Bitwarden recognizes that since they give you a big modal warning that your encryption key will be stored in plain, if you set the lock option to "Never": https://imgur.com/a/jj9FveF
> This brute-force will very likely be successful, since PINs are usually very low-entropy. Now, granted, the key derivation function is PBKDF2 with 100000 iterations (+ HKDF), but that won't help with a 4 digit pin.
It would be better to not have that feature at all, that convenience feature goes a bit too far. But nice to see that's the only thing they found, I'm sure they looked for more severe issues but found none.
Times 10k that is just 27 hours. Spend a couple of bucks on a few beefy EC2 instances and you crack that in an hour or two.
A Personal Identification Number typically has 10k (or less frequently a million) possible values. Hashing buys you a few seconds of brute force resistance here at most, which is completely useless.
If you dial up the hashing complexity enough to make a dent, even legitimate logins will start having an unacceptable UX and battery life impact. You're just on the wrong side of the e function with PINs.
> be more clear that users should use letters as well
The entire point of the feature is that the PIN, whether letters or numbers, is shorter and/or easier to type than your passphrase. If you require users to use something of equivalent security to their passphrase, you might as well remove the feature.
Your last point is also misleading - no, you don't require the equivalent to master password, and yes, it still makes sense in that case. "Shorter/easier" can still mean enough entropy for the smaller threat model of local compromise (with even more entropy required in the master password for the bigger threat of cloud compromise). It's when it drops down to the level of literal 4-number PIN, then it becomes useless against this threat and only useful for an even smaller threat
You could do that, but you should definitely also design this in a way that does not fail catastrophically if the server-side enclave fails, which at least Intel's version seems to have a habit of doing every couple of months or years.
A nice way would be to use a modern PAKE that can recover a client-side secret securely after a successful authentcation, such as OPAQUE: https://eprint.iacr.org/2018/163.pdf
Conceptually, you do a PAKE, and upon successful authentication deliver server-side stored entropy to the client (either through the PAKE, if it supports the feature natively such as OPAQUE, or explicitly over an encrypted channel secured under the PAKE-derived session key), which then combines it with client-side stored entropy to decrypt the database. That way, the server can rate-limit the client's PIN entry attempts, but does not have access to the vault itself even if it learns/brute forces the PIN.
Facebook uses a combination of this and the HSM/enclave approach for encrypted WhatsApp backups (although without the client-side stored secret, since the use case is recovering from a lost device, not protecting data on a compromised device): https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee...
You are thinking in hypotheticals like many developers do.
Most infostealer malware just exfiltratr your data and disappear before being detected do they can hit a lot of targets before commom av starts detecting them. People also accidentally disclose data, back it up on a usb drive and lose that drive, have their pc stolen,etc...
If you have keepass2 with a memory argon2 and a password/passphrase none of that is a concern.
Yes, the malware could also be a keylogger/RAT and you'd be screwed then. One the most important security mindsets to have is "perfection is the enemy of good", specific security controls exist to address specific threats/risk not to address arbitrary and and an unbounded number of possible threats.
Sure entering a passphrase each time is better for security. But if the user chooses to set up a PIN instead, I feel the current behavior is reasonable.
Which is why my bank card is blocked after three failed attempts.
That's why SSH keys or GPG keys are typically protected by a pass phrase. Not a PIN, not a password, a pass phrase. At least that's the wording that OpenSSH uses, and Bitwarden should do the same. Secure your database with a pass phrase, not a PIN, or else you might be vulnerable. That's how it should be communicated to the user. These details matter.
Even if my laptop is unlocked, each 1Password interaction needs my fingerprint. That unlocks a secret stored in the Secure Enclave, which I trust. (Security is hard and flaws are possible, but Apple has done a reasonably good job here from what I can tell.) I only have to mess around with typing a long string of nonsense in when I'm registering a new device, rather than every time I want to use my SSH or GPG key (or trusting an agent to hold it in memory, which... I'll do it, but I won't like it).
I wish I could rely on similar things from Linux, but the user experience just isn't there on the desktop. A previous employer issued laptops that had both a fingerprint reader and some kind of HSM, so the hardware was there, but I remember both of them missing drivers at the time, and even with drivers the userland software support would've been very hacky.
[0]: https://support.1password.com/touch-id-apple-watch-security-...
When you enable the PIN, you deliberately weaken your security for convenience. However, when the database unloads, your database is still protected by your pass phrase.
This is not the case if you disable the "lock with master password on restart" option. In that case only your PIN is guarding access the the vault data.
Using a PIN shouldn't have to mean weakening the security, since there's several secure implementation options of a PIN. (See other comments about Windows Hello for example)
If the user has setup Bitwarden so the master password is not required, then the user gets what they asked for, namely a password database secured by a 4 digit PIN. Not clear to me why this is a problem Bitwarden needs to fix.
Is it a good idea to leave your password on a piece of paper under your keyboard? No, and you shouldn't need Bitwarden to tell you that.
Is it a good idea to use your name and date of birth as a password? No, and this should be obvious, not something Bitwarden needs to educate you about.
Is it safe to rely on a 4 digit PIN? Obviously not, when there are only 10000 possible combinations. You shouldn't need Bitwarden to tell you that though.
Are there people out there who do need this education? Of course. But that's a job for someone with infinite patience and understanding. Not some words on a web page from a supplier.
Case in point, my step dad belonged to a "computers for elders" group and one day he learned about antivirus software. Next time I watched him, he was googling for anti virus software and downloading any he could find, from anywhere on the internet. He ended up with 6 different AV packages, some very dubious looking indeed. I tried to explain the dangers but he couldn't understand how antivirus could actually harm his computer. And he was a practicing doctor of medicine before retirement. It really highlighted the challenges of protecting some people in the brave new digital world.
Most people really don’t know that. It is not obvious to a normal user.
I'm confident your average person would understand that a PIN is insecure if it was explained to them.
But think about other things in life that use a PIN -- debit cards, customer support shortcuts, etc. These are things that can't or typically won't be brute forced and are deemed as "secure enough" in our world.
Your average person has no idea how a 2FA token is generated, but they know it's just a few numbers that they have to enter on various websites and apps, and those numbers resemble a PIN. Yet another reinforcement that just a few numbers keeps things secure.
If you walk a user through software setup, and at some point they need to provide a complex master password, they would never automatically assume that being presented with an option to use a PIN would remove the security provided by a complex master password.
Only if they were to think it through, or have someone who thinks analytically, would they understand that in this scenario, given that it's Internet-accessible software, a PIN could be brute forced in no time unlike their debit card or any other PIN they may need to use in the course of their day to day life.
Yes it is, if your threat model excludes physical access; and in that case, it's probably more secure than anything software can do.
It‘s 100% their job to make passwords a safer system.
As an advanced user, I can look up whether the PIN is tangled to a server-side limit or a TPM (or equivalent) for maximum attempts enforcement.
Most users don‘t even know these things exist or how to look for them. That‘s arguably nothing they should have to worry about, though.
Normal users see that Bitwarden blocks you after 5 guesses, therefore an attacker will never get past all 10000 guesses. They won't realize that this block is easily evadable.
As it is - I'm not sure if pin makes sense even if there's user demand? Then again I do use biometric unlock - and that's not really great either.
At least the bitwarden installs are behind fde (macOS) - and possibly (?) file based encryption (Android 13+).
A 4 digit PIN would be safe if Bitwarden securely enforced an attempt limit on the PIN. There's several options to implement this securely (see e.g. other comments about Windows Hello or use of a TPM).
Is it because of the name PIN? So there is your simple answer of what problem Bitwarden needs to fix
Similarly with your first point - I don't think the master password has many special symbols, I'm just asking a question that illustrates the issue with the original faulty assumption
Then brute forcing a 4 digit PIN will take 20000 seconds ≈ 6 hours maximum. There's no way around that, no matter what hash function you use.
> [...] As a comparison baseline, a 2.4 GHz Core2 CPU can perform about 2.3 millions of elementary SHA-256 computations per second (with a single core), so this would imply, on that CPU, about 20000 rounds to achieve the "8 milliseconds" goal.
So you'll need something that takes at least as long as entering your full password, at which point you basically could enter the full password (from a UX perspective). They PIN is here to make it faster and it will always be security vs. ease-of-use.
[1] https://security.stackexchange.com/questions/3959/recommende...
A four digit PIN is poor security. What Bitwarden could do is removing that feature.
Or… I can just stop the software, change computer time. And the timeout is over.
There really isn't a solution if the entropy is low and the enforcement mechanisms are in the hands of the attacker. Even a TPM or secure element is just a financial obstacle to a sufficiently motivated attacker.
For sure, but currently it's a fairly big step function for an attacker to have to teardown a TPM (or find a vulnerability in its firmware).
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...
So forget what you know about ATM PINs; this is a markedly different concept.
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).
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.
I mean it's actually the same concept (something you have, something you know) with a different implementation.
Thanks, when windows moved to the PIN I was wondering how that worked/ they kept it secure but still easy to login.
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.
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
> 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.
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.
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.
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.
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.
That should still take essentially forever, or did I miss some advances in brute forcing?
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.
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.
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.
Personally, I'd agree with Bitwarden on this that it's an attack that requires physical access to a user's device, or worse, remote admin privileges.
> Using a PIN can weaken the level of encryption that protects your application's local vault database.
> If you are worried about attack vectors that involve your device's local data being compromised,
> you may want to reconsider the convenience of using a PIN.
https://bitwarden.com/help/unlock-with-pin/#enable-unlock-wi...
It is something they should remove entirely in an upcoming version after giving users enough warning.
https://blog.kraken.com/post/11905/your-fingerprint-can-be-h...
Personally I advocate using BitWarden for commonly used logins that, if they were compromised, would not be catastrophic; perhaps in some cases because 2FA provides another, tautologically, factor, and KeePass secured with a FIDO2 device in challenge response mode, a passphrase, and possibly setting a higher key stretching work factor to further blunt any brute force attempt, in which more important data is held.
However, it's important to note here that biometrics isn't just about fingerprints and every OS handles their available biometrics options differently. For example, I would recommend face authentication on apple devices, however I would avoid using face for windows, and instead recommend a windows hello PIN (yes, it's handled differently than the PIN in the above article).
Ultimately, you're just trying to create a balance between the layers of protection and reasonable attacks. There's only so much you can protect against, nobody can withstand someone who is cloning fingerprints, stealing devices, has access to your separate device 2FA, etc. without severely affecting their lifestyle.
If they're rubberhosing me, I'll just give them the master pass. They won't have to take my finger.
If they get my fingerprint some other way, I can just switch to my next finger. And when I'm done, I can use PINs.
I don't think it's mutability that matters. It's just that I leave fingerprints everywhere.
So no excuse if you value convenience, PINs are not good. Short easy to remember and enter PINs are also the reason Apple is under fire due to how easily you can avoid biometrics and just use the 6 digit PIN.
And there's documented steps on what to do if you've lost physical access to a device.
There are/were some highly-sophisticated attacks using peripheral bus exploits (firewire, thunderbolt, etc.), but that's a very unlikely threat to most people.
Not every device has the necessary hardware, though; most desktops don't have it, so they would need to rely on external hardware such as USB keys. Furthermore, the demonstration video is clearly running on some kind of Linux/BSD system, where support for trust hardware is distinctly lacking.
I don't know why you would bother with a PIN on your password manager. My guess is that it's a feature designed for mobile devices, where access to the underlying key store is near impossible so brute-forcing is much less of a risk. Biometrics are usually available there as well, but if you don't trust them with your most secure passwords (you probably shouldn't) or if you want a backup, a PIN would be an excellent defence mechanism for when you've left your phone unlocked and a stranger is trying to steal your passwords.
These days, the interface even appears to have improved somewhat, to the point where there's nice GUIs and everything.
https://help.ubuntu.com/stable/ubuntu-help/session-fingerpri...
Also, dongle support is pretty good for things like java PIV cards and yubikeys. I've successfully used a java chip card with website authentication in Firefox, and with VMWare view client. This has also worked for at least a decade or more - my main issue was with process in Firefox being a little convoluted and VMWare using out of date libraries and having a set of installer instructions that actually require explicit symlinking of the a system library. But that's not really linux's fault.
The Linux version of this process, at least as far as I could find so far, consists of identifying and authorizing the user alright, but the TPM's secret management seems to be handled by an entirely different system.
This means that brute-forcing or other attempts at access don't need to go through the biometric system on Linux whereas Windows Hello is more tightly protected against malware like that.
Dongles do work great! With WebAuthn/FIDO(2) we can hopefully soon start to let go of password managers completely. Passwords are useful but passwordless authentication is just better for most single factor authentication mechanisms in my opinion.
As for eliminating passwords, while I love the idea of hardware dongles, I'm always going to want to have a password on it.. I assume you mean eliminating having a ton of passwords as opposed to one good strong password on the dongle. But then, that's the same situation I'm in with the password managers anyway. It's not like I actually type my password into most websites anymore...
What I mean is eliminating passwords on most services at all. For everything but real important stuff (banks, email, business accounts, that kind of stuff), I reckon my devices are protected enough that if someone can gain access to my devices unlocked enough, 2FA wouldn't prevent any threads anyway. Passwords are easy to brute force, but device-bound keys aren't.
Using the security chips inside my devices for authentication as a single factor is more than enough for most of my purposes. Today, most websites offer FIDO2/WebAuthn/U2F as a second factor, but I'd rather see them as a first factor with an optional password as a second factor.
My password manager protects me against nothing more than brute forcing and password reuse. Switching to TPM-first moves the protected bastion from a piece of software running in userland to either a kernel level-protected component or a dedicated piece of hardware. There's only so much you can do as a desktop application to protect your users' keys, after all.
I wouldn't want to force anyone into this system, but I do think with the hype FIDO2 was released with, I imagine browsers are going to push more for using FIDO2 as a primary factor where available.
And, I'm absolutely going to have a password on my dongle or laptop in case of loss. I don't really trust biometrics in that scenario either really. Especially fingerprints that would be all over the laptop. Biometrics are just a convenience that I recognise offers some modicum of security. That's why hooking it up to TPM seems to not add much.
... I do get hardening where the passwords are stored though... although, if the disc is encrypted using TPM (which linux definitely supports), I guess the main attack you'd be concerned about would be the OS being compromised while running, but aren't we just back to loggers then?
Note that on desktop Bitwarden allows PINs to be alphanumeric, and any length. I use a PIN because my master password is more than 20 characters and I don't want to type it every time I restart my browser. My PIN is a decently strong password in its own right, but shorter than my actual master password.
How?!? There's been an fTPM built into CPUs since Haswell on the Intel side and on the AMD side since before Ryzen. If you OEM it's enabled automatically if you bought a machine after July 28, 2016. If you DIY you literally have to flick one switch in the BIOS if it's not enabled automatically.
There is something interesting regarding the 7700k though on windows (especially 11), users have been claiming windows reports it as supporting TPM 2.0 but they still can't upgrade to windows 11 due to failing requirements. So I wonder if something else is happening there that also seems to be affecting windows hello for you, because on paper at least for windows 10 you should be able to use Hello no problem.
However, I do know that I had to manually enable the fTPM functionality on my motherboard and I highly doubt the average consumer is going to enable such features in their BIOS. I don't know when manufacturers started enabling fTPM support by default, but it's definitely not enabled by default in most 7th gen Intel boards and I doubt 8th gen changed much in that sense.
In the end, I had to reinstall Windows and I'm never touching Windows Hello again.
It's mind-boggling how shit Windows Hello is :-/
Mind you, the forced Microsoft account for new Windows 11 users is a huge problem. But it's a different one.
This is wrong. The Bitwarden client very clearly warns about storing your encryption key locally via a mandatory popup window, as seen here: https://i.imgur.com/BzXJmos.png
The author is arguing that such a popup should also exist when locking a vault with a PIN only.
if you mistyped the PIN to often the thing is locked until the PUK is entered, often followed by resetting the PIN to a new potentially different value.
most often know from SIM cards
I think I'd appreciate an option such that:
1. If I'm online, I can unlock with a pin. Some critical piece of information would be kept server-side, and the server would limit unlock attempts.
2. If I'm offline and need access to my vault—which happens but not too often—I need to use my full master password.
I think this should be doable? Could you retain enough end-to-end encryption such that if Bitwarden itself is hacked, my vault couldn't be decrypted via only my pin?
Pity that the only reasonable option is rejected.
I think the system I suggested above would work a lot better. What I have now isn't so bad as my passcode is moderately strong, it just could be better.
>Bitwarden does not warn about this risk…… Bitwarden takes little effort in communicating the risks of choosing a short low-entropy PIN. Currently there is very little information to be found about the PIN in Bitwarden documentation
Bitwarden's help docs on using PINs: https://bitwarden.com/help/unlock-with-pin/.
>Warning: Using a PIN can weaken the level of encryption that protects your application's local vault database. If you are worried about attack vectors that involve your device's local data being compromised, you may want to reconsider the convenience of using a PIN.
Water is wet.
The PIN is still potentially useful in that it prevents anyone with access to the device from getting access to the secret information without having to perform an overt act. The difference between leaving a piece of paper with the passwords laying about and locking it in a drawer.
Is the issue that bitwarden fails to use these properly (e.g., by storing a short pin in the touch id enclave), or that the person reporting the bug is using a machine without such an enclave, and enabled pins anyway?
It's not so easy. Bitwarden runs in a browser on PC's. As far as I know, browsers don't provide a javascript API to the TPM. They probably supply a javascript API to their password store which may even be backed by a TPM (Firefox on Windows is I think), but they also allow you to browse their passwords while the browser is running so I wouldn't be keen on that.
Bitwarden also runs on Android. I haven't seen an Android TPM API. Instead Android supplies a "Keystore". It stores secrets that can be unlocked using phone managed secrets - like a PIN, fingerprint and so on. Yes, they have limited retries - but they come with the limitation that if you can unlock the phone, you can unlock Bitwarden. Not ideal - in fact pretty much the same situation as a browser, now I think about it.
So I suspect that while it's true "most modern hardware supports secure storage", the issue is Bitwarden doesn't run directly on the hardware. Instead it runs on platforms like Anroid or a browser that don't expose the hardware's secure storage directly.
I used to use Bitwarden with this feature though, just that I recently came to the conclusion that the product probably isn't the most secure offering and it has some issues on Android with native autofill when you aren't using Google Services.
1. You can access the passwords if you know the PIN.
2. All state is local.
All you need to do is guess the PIN and restore state, and repeat. Any code in Bitwarden to prevent (obscure) you from doing this is just a cat and mouse game.
Perhaps a way around this is to not have all state local. Have the PIN + separate authenticating private key go to their server. You get 3 attempts before you need the full password.
I don't use BW's PIN. Using a loong passphrase.
If others want convenience with 12345, it's all them.
Or if you want a moral of the story specific to the article: Don't use the PIN feature in BW. And perhaps, instead of a PIN use a physical key (e.g., YubiKey).
Is this no longer true, for most people?
My mom doesn't have any reason to download and run untrusted software ever, and she'd call me if she needs something, so for her it's definitely better to have secure passwords with the risk of having all eggs in one basket. The risk of her being tricked into running software that steals the vault is lower than the guessable and reused passwords that she used before.
If you are more like me and regularly download software to try it out, pull random github repos to toy with them, etc., then it might be wise to keep the password database on an Android/iOS device which have app isolation. You can download all the malware you want, but if you don't grant it root, it won't be able to access the database stored in /data/data/com.example.keepass/database/.
Perfect? No. 100x better than what most people do? Yes!!!
Moi? For the important stuff? I add in a YubiKey. Perfect? Again, no. But closer than no YK at all.
As a side note: I do contract web dev work for various agencies. Generally, talk about a lazy approach to clients' PWs. They think 1PW makes things secure. Meanwhile I generally have access to all vaults, even projects I'm not working on. Good sec is bases on less trust, not too much blind trust.
All the rest I just reuse simple passwords because they simply aren't important and aren't worth the time to care. Someone wants my Discord? Go for it, I don't care. My Reddit goes with it? Sure, I don't care. My HN account too? Daring today, aren't we.
So no, personally I haven't felt a need nor desire for a password manager. Arguably it will cause me more grief than convenience.
And it would be nice if password managers explains the much much bigger risk of these very short numbers-only poorly named PINs so that users can make an informed decision
Yes, exactly. I feel a lot of these tools are doing this. And it’s okay if it explicits that the data is plain text. However why annoying users with a PIN in the first place?
I am sorry bitwarden didn’t fake this seriously.
Let me know if you are looking for a job. We have several positions open. Feel free to shoot me an email julien -at—serpapi.com
FWIW on a GPU using SHA1 or SHA256 this is not very much time-protection.
- https://www.reddit.com/r/Bitwarden/comments/110gpkt/traffic_...
-https://www.reddit.com/r/Bitwarden/comments/11vplwv/network_...
- https://twitter.com/lazminutes/status/1624946344564781056
Locking me out of 2FA because of you don't like my network traffic? Yeah, I will be immediately leaving your service, bye. That's Google like bro, lol. Clown stuff. Insane that they would even think of doing this.
After the attacks and smear campaigns, shall the people unwilling to use KeyPass and other high-lift/high-risk pieces of software move on to using tiered password strategies for their hundreds of sites again?
Pin is obviously less secure (however this could be mitigated by using a TPM as other commenters said) but it's not the default.
Their help page on pin even warns about the security risk, they should have the warning in the application.
I'll still use bitwarden (without pin).
I'd guess a software engineer working on that part of a security system would probably consider that, while the implementation approach for that part was being decided.
If so, why did it happen anyway? Did they communicate the weakness to users?
Or host vaultwarden on your homeserver and access it only through wireguard/nebula self hosted VPN.
As for KeePassXC, last I checked it didn't even bother.
Professional companies that care about security (I do IT security consulting so that's the group I deal with the most) are not perfectly secure. I'd argue that it's less likely that a password database is abused when hosted on a random average-security system (assuming the person is not being targeted, like if you're not a public figure or have a stalker) than if you've got it hosted with some bigcorp that has a huge target painted on their back. Some are really good at security and others a bit less, but none are perfect, and scale dictates compromises between security and usability. Not everyone in the firm will be a security expert, and much as you try to isolate the vaults / source code / other security-relevant systems from them, they're how ransomware and other groups gain a foothold to work with.
I wouldn't trust my mom to set up a server secure enough for a password manager to be hosted on, but if you are comfortable around servers at all and follow normal guidelines, or use normal syncing software that is only encrypted to the server (so you pick and rely on a strong password for your vault file), you're more secure than when you use a third party and type that password into their website (even if, on a good day, the key stays local in your browser).
Let's quantify that. The default KDF that keepassx uses is iirc ~50ms seconds of computation on modern hardware. It might dynamically determine the KDF rounds based on your system, but it never updates it (hmm, is that a vuln as well?) so it'll be old either way. A GPU gets a ~thousand-fold speed-up compared to CPU for pbkdf2, so let's say 20k guesses per second per GPU (note: this is just a ballpark number). An attacker might have a dozen GPUs available and care to spend a month on your vault (does that sound like a fair upper bound? Tweak it for your personal threat model), which means they run through some log(20e3 guesses_per_second × 12 gpus × (3600×24×31) seconds)/log(2) ≃ 40 bits of entropy.
If you pick random words from a diceware-sized dictionary (7776 words), you need 4 random words to be secure (because log(7776⁴)/log(2)>40). If you pick random characters from a-z,A-Z,0-9, you need a 7-character randomly generated password (because log(62⁷)/log(2)>40).
Edit: it looks like KeepassX has stopped development and says to use KeepassXC now. Their source code has some mentions of Argon2id so this may be outdated advice! Your password/-phrase may be able to be shorter than this, but it'll be hard to quantify because all Argon2 crackers suck ("For Argon2, the fastest cracking software that I can find is a CPU implementation." I wrote two years ago in https://security.stackexchange.com/a/249384/10863).
It has some cool features too, like not injecting anything into pages until you activate it (so no performance cost or risk of breaking sites) being less reliant on perfect detection of fields when it is activated, etc.
Found the SPOF! But also, "AI"? And "we've been building" doesn't sound like it's production-ready yet. I don't know, lots of red flags here to me.
"... is a form of cryptographic attack on a computer system or communications protocol that makes it abandon a high-quality mode of operation (e.g. an encrypted connection) in favor of an older, lower-quality mode of operation (e.g. cleartext) that is typically provided for backward compatibility with older systems." from https://en.wikipedia.org/wiki/Downgrade_attack
Guessing a 4-digit number with unlimited attempts available is not a downgrade attack but a brute-force attack https://en.wikipedia.org/wiki/Brute-force_attack
Think it through.
As a fair to middling organic language model, I cannot tell you how to keep your keys safe; I myself am blessed with a good memory and 160wpm typing speed so I use that.
Presumably, a better implementation would be fine.
You are free to keep using Bitwarden's PIN implementation, but it will still be open to: downgrade attack.
This is because Bitwarden's security, as described in this article, is open to: downgrade attack.
This is not an emotional term. It is no more laden with implication than observing that #F00 is 'red'. You are free to keep using #F00, just don't call it blue.
Donwgrade attacks are relatively straightforward, and ease-of-use features, such as PINs, are a traditional place to look for them.
I have no opinion on this matter other than that it implies that Bitwarden can be configured in a manner which is insecure, and the specific form of insecurity is: openness to downgrade attack.