[HN Gopher] Bitwarden PINs can be brute-forced
___________________________________________________________________
Bitwarden PINs can be brute-forced
Author : aborsy
Score : 299 points
Date : 2023-03-19 14:29 UTC (8 hours ago)
(HTM) web link (ambiso.github.io)
(TXT) w3m dump (ambiso.github.io)
| dathinab wrote:
| A rule of thump: Nearly everything which is called PIN can be
| reasonably brute-forced as long as it doesn't get locked after a
| few attempts (and only unlocked through another factor e.g. a
| PUCK).
| throwaway742 wrote:
| What is a PUCK?
| dathinab wrote:
| PIN unlock Key (PUK)
|
| 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
| throwaway742 wrote:
| thank you
| billconan wrote:
| the more I see hacked password vaults (lastpass for example), the
| more I want to build a p2p password vault that only lives on my
| own devices.
| danieldk wrote:
| It doesn't have to be P2P, as long as the vault items are
| encrypted using device-specific secrets that are in a secure
| element (like iCloud Keychain). As long as there is no secure
| element in the loop, the security is limited. Secure elements
| can rate limit requests, require biometric authentication, etc.
| Without such limitations, you are only one upstream compromise
| away from exfiltrating all passwords.
| Diggsey wrote:
| I built my own that does this :) Just working on improving the
| UX now...
|
| 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.
| CMCDragonkai wrote:
| We've been building a p2p password vault called Polykey.
| https://GitHub.com/MatrixAI/Polykey.
| lucb1e wrote:
| > No server is currently available to service your request.
|
| 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.
| krab wrote:
| KeePass plus Dropbox. Or Syncthing for really using only your
| devices.
| neandrake wrote:
| Codebook might be suitable. You can sync to Dropbox or google
| drive, or instead only sync between devices on the lan.
|
| https://www.zetetic.net/codebook/
| IceWreck wrote:
| It already exists: keepass and sync your DB on all your devices
| with syncthing (which is p2p).
|
| Or host vaultwarden on your homeserver and access it only
| through wireguard/nebula self hosted VPN.
| Macha wrote:
| Note the KeePass's resistance to the attack mentioned depends
| on the security of .NET's secure string, which, here's what
| Microsoft has to say about it
| (https://github.com/dotnet/platform-
| compat/blob/master/docs/D...)
|
| As for KeePassXC, last I checked it didn't even bother.
| tete wrote:
| Wouldn't it be enough to use something like Keepassxc and sync
| with whatever you use for syncing?
| lucb1e wrote:
| It would, so long as you're aware that the password has to be
| strong.
|
| 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
| x 12 gpus x (3600x24x31) 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(77764)/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(627)/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).
| badsoftware wrote:
| You can host Bitwarden yourself, look into Vaultwarden.
| Wowfunhappy wrote:
| I like self-hosting things, but for something as sensitive as
| my passwords I trust a professional company much more than I
| trust myself. Yes, companies can and do screw things up all the
| time, but that doesn't mean I would do better, and I'm a single
| person with other responsibilities in my life.
| lucb1e wrote:
| Or you don't host it but just keep it tight to your chest. No
| risk of any server being compromised then.
|
| 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).
| hedora wrote:
| The article and comments don't really answer the most important
| question here: Most modern hardware supports access to secure key
| storage via biometrics or pins that lock after a few attempts.
|
| 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?
| quickthrower2 wrote:
| This is logical right?
|
| 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.
| chiefalchemist wrote:
| The moral of the story here seems to be: if you want convenience
| you'll compromise your security. This is not exclusive to BW.
|
| 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).
| juve1996 wrote:
| Most people have been told that even though you're centralizing
| passwords (meaning if hacked you're in big trouble), the
| benefits gained from being able to generate strong passwords
| overcome this.
|
| Is this no longer true, for most people?
| lucb1e wrote:
| I would say this is definitely true for the common Joe, but
| of course it helps to not run much arbitrary software from
| the web and keep your browser up-to-date to avoid drive-by
| malware. If you've got a habit of pirating games, you may
| want to keep your princess in another castle.
|
| 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/.
| chiefalchemist wrote:
| The idea is...centralize your PWs but "harden" them behind a
| single longer and less brute-forceable master pw. And since
| the PW manager is doing the fill in, those can be longer and
| more random as well.
|
| 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.
| Dalewyn wrote:
| I can count on one hand the number of services that are
| important/crucial enough to warrant unique, strong passwords.
|
| 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.
| SparkyMcUnicorn wrote:
| I think TPM and secure enclave provide the convenience without
| compromising security?
| cryptonector wrote:
| They provide the security without compromising convenience
| (but you do need backup options).
| RyeCombinator wrote:
| Everything can be brutce-forced https://xkcd.com/538/
| qainsights wrote:
| I disabled it for purpose :)
| markstos wrote:
| It's practically game over if an attacker has access to your
| laptop. They can for example install a keylogger and capture your
| master password for any password manager.
| SparkyMcUnicorn wrote:
| 1Password requires a secret key that is rarely (if ever) typed.
|
| And there's documented steps on what to do if you've lost
| physical access to a device.
|
| https://support.1password.com/lost-device/
| ris58h wrote:
| Don't confuse access to working laptop with access to encrypted
| data [upd: that was] stored inside it.
| prophesi wrote:
| To clarify for those that jumped straight to the comments;
| the threat model this article is talking about is extracting
| the encrypted database stored locally on your machine to
| brute-force the PIN.
|
| 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...
| waboremo wrote:
| Using the PIN is outdated anyways when it comes to
| convenience, all reasonable user OS now support biometrics
| and those offer better risk mitigation in comparison.
|
| It is something they should remove entirely in an upcoming
| version after giving users enough warning.
| mt360 wrote:
| I wouldn't put too much faith in biometrics either, a
| real shame considering their convenience.
|
| 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.
| waboremo wrote:
| That's an absurd amount of effort to bypass fingerprint
| biometrics, nice.
|
| 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.
| NoZebra120vClip wrote:
| PINs can be changed. How many fingers ya got?
| waboremo wrote:
| I'm pretty sure you can register the same finger over and
| over again for new "keys". Assuming you go through the
| tedious process of disabling, restarting, etc whatever
| each one of the underlying OS demands. It's an additional
| layer that Bitwarden (and other apps) do not get direct
| access to.
|
| 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.
| renewiltord wrote:
| Ten. I don't get why this is a constraint.
|
| 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.
| yazzku wrote:
| Then why encrypt it in the first place? That's the point
| the author makes (text in bold).
| prophesi wrote:
| It's a choice on the user to weaken the encryption. I
| don't use Bitwarden, but if they communicate that
| properly to the user, it's a valid compromise for
| convenience-versus-security.
| yazzku wrote:
| This doesn't answer the question. Why is there a choice
| to encrypt something when it's completely unnecessary
| (according to their threat model)? No point in building
| unnecessary complexity into software, especially software
| meant for security.
| prophesi wrote:
| The client-side lock of 5 PIN attempts solves the much
| more common threat model the layman is concerned with.
| asmor wrote:
| Different threat model. If someone steals your laptop, your
| hardware is seized or your employer wants their backdoored
| machine (but not backdoored in this specific way) back, you
| probably do not want to leak your password manager contents
| either.
| eviks wrote:
| The name is part of the problem You can have shorter alphanumeric
| password per device for frequent unlocks, it doesn't have to be
| your typical 4 number PIN that jumps to mind It would not offer
| the same protection as your main much longer password, but then
| that longer password protects against a bigger threat than local
| access, and it's still much more convenient (and not much less
| inconvenient vs the 4 digit PIN, like on a full computer keyboard
| typing a longer word is faster than shifting your fingers to the
| top numbers row)
|
| 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
| neilv wrote:
| > _However this 5 guesses limit is enforced completely within the
| client 's logic: it relies on the attacker using the official
| Bitwarden client._
|
| 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?
| Waterluvian wrote:
| On the spectrum of security, I think a PIN is closer to a privacy
| lock than a security lock.
| gowings97 wrote:
| Suddenly getting Error Code 7 (unusual network detected -
| https://bitwarden.com/help/unusual-traffic-error/) when
| attempting to login. Googling and looking on Twitter - people
| have been complaining about this happening to them as well.
|
| - 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.
| ddtaylor wrote:
| > Now, granted, the key derivation function is PBKDF2 with 100000
| iterations
|
| FWIW on a GPU using SHA1 or SHA256 this is not very much time-
| protection.
| sneak wrote:
| Someone should tell them!
|
| https://github.com/bitwarden/jslib/issues/52
| t-writescode wrote:
| The attacks went from LastPass and over to BitWarden.
|
| 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?
| subeadia wrote:
| "Bitwarden does not warn about this risk."
|
| 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
| shiftingleft wrote:
| It looks like this is a popup for a different setting. Did you
| watch the video outlined in the post?
|
| The author is arguing that such a popup should also exist when
| locking a vault with a PIN only.
| IshKebab wrote:
| That's about as unclear as I could imagine. "If you use this
| option please ensure you take the appropriate precautions."
| Wowfunhappy wrote:
| That's not what it says though. How would you phrase it? I
| don't think they do a _great_ job but this is pretty hard to
| explain in two sentences if you 're targeting a non-technical
| person.
| Wowfunhappy wrote:
| I'm pretty sure that comes up only if you disable vault timeout
| entirely, not if you enable a timeout but allow unlock with
| PIN.
| iLoveOncall wrote:
| This posts reads like "Hey guess what, if you store your
| passwords in a file called passwords.txt on your desktop and
| install a virus, people can steal your passwords.".
|
| Water is wet.
| upofadown wrote:
| >If accessing device-local data is outside of the threat model,
| why are we encrypting these data at all? We might as well store
| them in plain text.
|
| 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.
| nabakin wrote:
| Yes, pins can be bruteforced when they are stored locally, on
| device. That should be pretty obvious to those of us who know
| anything about security. However, the average user doesn't know
| about security. They shouldn't be expected to understand the
| nuance of security. So many people in this comments section are
| saying 'well obviously a pin can be cracked' but it's not obvious
| for the average user! Stop blaming the user here when Bitwarden
| should only offer features which are secure or at the very least
| provide a warning when a feature is unsecure.
| hedora wrote:
| Local pins can't be brute-forced on the majority of my
| machines. The exception is a decade+ old intel desktop, and,
| even then, I think it has a wonky tpm slot (or I could buy a
| yubikey. They support locking pins after too many retries,
| right?)
| FfejL wrote:
| "Let's now assume that the user enables the PIN unlock and
| configures Bitwarden so that it doesn't require the master
| password on restart."
|
| 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.
| e12e wrote:
| With a secure enclave of some kind, there could conceivably be
| a three attempt limit before the temporary key associated with
| the pin is deleted, and full pass phrase is required. In such a
| setup pin might make sense.
|
| 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+).
| Eisenstein wrote:
| If the user setup the PIN and uses it every time the chances
| that they know the master password is about 50/50.
| e12e wrote:
| 50/50 chance the pass phrase is secure against keylogger!
| eviks wrote:
| Why did you jump to a 4 digit PIN instead of a 10 letter word?
| (which is still faster than the full 20 letter master password
| with many special symbols)
|
| Is it because of the name PIN? So there is your simple answer
| of what problem Bitwarden needs to fix
| SV_BubbleTime wrote:
| They could make the pin process intentionally slow... maybe
| with some number of iterations... and as computers get faster
| they can just update the number of iterations required...
| nebulous1 wrote:
| It already is intentionally "slow". However, for a 4 digit
| pin there are only 10 thousand combinations. It is not
| practical for it to be so slow that 10000x it is an
| infeasible amount of time. Not only would the user have to
| way too long on each entry, the attacker could just use
| faster hardware.
| pmontra wrote:
| Or multiple machines. There are about 31k seconds in a
| year. 3.1 seconds per iteration seems already slow as a
| response time to unlock a db so it's about one year for
| those 10000 attempts. Split it between 10 machines by first
| digit, it's down to a little more than one month. Split it
| between 100 machines by the first two digits and it's down
| to half a week.
|
| A four digit PIN is poor security. What Bitwarden could do
| is removing that feature.
| warkdarrior wrote:
| Uhm, 31k seconds is about 8.7 hours.
| usefulcat wrote:
| 31.5 _million_ seconds in a year
| chrisandchris wrote:
| Split it to 5000 machines, which will be "quite easy to
| get" for a computation that takes a single line in most
| languages. Then we're talking about 6 seconds and 50%
| success on first try.
| morpheuskafka wrote:
| If the PIN is local, only a secure element type of chip could
| meaningfully enforce this restriction. Otherwise, whatever
| memory or disk stores the secret encrypted only by the
| 4-digit PIN could still be brute forced. Just disabling
| entering a PIN in the UI would not be enough for security.
| [deleted]
| 0xdeafbeef wrote:
| You can use pbdkf2 with 200k iterations or argon2 to derive
| key from pin
| barsonme wrote:
| This has very limited benefit for weak passcodes, like
| PINs.
| gengkev wrote:
| Suppose it takes 2 seconds of 100% cpu usage to compute
| the password hash (you probably wouldn't want to wait
| much longer).
|
| 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.
| chrisandchris wrote:
| Which will still be ... nothing?
|
| > [...] 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/rec
| ommende...
| TJSomething wrote:
| An Nvidia RTX 4090 can crack a 4 digit pin using PBKDF2
| with 200k iterations in less than a quarter of a second.
| Argon2 is definitely the better option, but even at 1
| hash per second, that's less 3 hours.
| 8ytecoder wrote:
| And add other defensive mechanisms like lockout after n
| retries.
| mmis1000 wrote:
| Unless you are using a hardware based pin. Lockout is
| useless. I can just backup the file before lockout and
| restore
|
| Or... I can just stop the software, change computer time.
| And the timeout is over.
| sowbug wrote:
| That's a bit like putting a website password check in the
| client-side JavaScript. Attacker removes lockout, continues
| brute-forcing.
|
| 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.
| cryptonector wrote:
| > 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).
| nabakin wrote:
| You're assuming the average user understands security when that
| is definitely not the case. The job of Bitwarden is to help all
| users (even ones ignorant of security) to secure their data. If
| Bitwarden has no warning explaining that pins are unsecure,
| then the fault 100% lies with Bitwarden.
| abraae wrote:
| Some things fall into the "obvious" category, users should
| just know them, and it's not 100% on Bitwarden to make the
| world a safe place.
|
| 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.
| twblalock wrote:
| > 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.
|
| Most people really don't know that. It is not obvious to a
| normal user.
| brewdad wrote:
| I realize math education in the US sucks but are really
| suggesting most people can't figure out that 0 to 9999 is
| all the possibilities you get from 4 digits?
| waselighis wrote:
| The problem is these password managers are lucrative targets,
| especially being able to gain access to a person's financial
| accounts. Simply disregarding the issue and categorizing it as
| "Attacks requiring physical access to a user's device" isn't good
| enough. Yes, there's only so much Bitwarden can do from the
| software side of things, without hardware support to back it up.
| But Bitwarden should still do what it can to mitigate such
| attacks, such as significantly increasing the number of PBKDF2
| iterations for PINs (at least stored on disk; a key could be
| cached in RAM with fewer iterations because RAM is far less
| likely to be compromised than files on disk), and discouraging
| (or even preventing) users from using short PINs that could be
| quickly brute forced.
| SV_BubbleTime wrote:
| BW is/has switched to Argon2 over PBKDF2, fwiw. Although Argon2
| trades the iterations field for an allocated amount of memory,
| so time will tell if there isn't a "BW accounts with 16MB of
| argon2 allocation are no longer considered secure".
| Operative0198 wrote:
| Glad I transitioned my passwords from Bitwarden to an offline
| password manager that doesn't have a similar "easy PIN password
| mode" feature.
|
| 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.
| stockhorn wrote:
| What issues are you talking about on android? Using e/os/ here
| with native autofill and yes this seems to have some issues :/
| (mainly keyboard not auto-closing I think)
| d-z-m wrote:
| 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.
|
| [0]:
| https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
| LorenPechtel wrote:
| A PIN is a de-facto very weak password. Of course it can be
| brute forced!
| jeron wrote:
| If you limit number of attempts, can it still be brute
| forced?
| KMnO4 wrote:
| How can you enforce a limit when the decryption is done
| client side?
| folmar wrote:
| Using a smart card or compatible, nowadays often a TPM
| chip/SecureZone/Secure Enclave or similar.
| ericpauley wrote:
| Using a TPM:
| https://en.wikipedia.org/wiki/Trusted_Platform_Module
| intelVISA wrote:
| TPM interdiction is readily possible.
| lucb1e wrote:
| 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
| bkettle wrote:
| 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.
| monocasa wrote:
| I read the original comment instead about sniffing the
| data path between the TPM and the user to get the PIN.
| e12e wrote:
| Which is just one way of _circumventing_ the pin
| (keylogger will work on pass phrase too!). But that 's
| not brute forcing the pin.
| cryptonector wrote:
| 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.
| macrolime wrote:
| 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
| cryptonector wrote:
| 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.
| intelVISA wrote:
| Some early/naive attacks in this category would be serial
| bus interposition.
| cryptonector wrote:
| 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.
| sudosysgen wrote:
| Require a backup password when the TPM is offline.
| d-z-m wrote:
| 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.
| poisonborz wrote:
| It's the user's choice.
| mynameisvlad wrote:
| 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?
| d-z-m wrote:
| Currently it is, yes. In this case, I'm arguing that it
| should not be.
| poisonborz wrote:
| 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.
| nicoburns wrote:
| If it's n or convenient then users won't use a password
| manager at all:
| NoZebra120vClip wrote:
| 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.
| generalizations wrote:
| 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.
| kadoban wrote:
| > 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).
| cryptonector wrote:
| 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.
| mynameisvlad wrote:
| Yes.
|
| https://www.dell.com/support/kbdoc/en-us/000142311/tpm-
| failu...
| duxup wrote:
| TIL
|
| Thanks, when windows moved to the PIN I was wondering how
| that worked/ they kept it secure but still easy to login.
| jvdvegt wrote:
| 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.
| sohtym wrote:
| > 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.
| grapesurgeon wrote:
| [dead]
| hnarn wrote:
| > 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.
| tomxor wrote:
| > 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.
| Kwpolska wrote:
| 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.
| Semaphor wrote:
| > including copying the Bitwarden file and using a GPU farm
| to crack the master password.
|
| That should still take essentially forever, or did I miss
| some advances in brute forcing?
| hn_throwaway_99 wrote:
| 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.
| Semaphor wrote:
| 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.
| organsnyder wrote:
| Eh... plenty of people with weak security hygiene also
| have high-value credentials.
| yunwal wrote:
| 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.
| bastawhiz wrote:
| Yet, people stole LastPass vaults. Why bother stealing
| them if you don't plan to actually crack them? At least
| someone saw the potential for some ROI.
| Semaphor wrote:
| LP had an issue with weak encryption for old accounts.
| [deleted]
| macrolime wrote:
| FDE does not protect against malware
| Kwpolska wrote:
| I never said it does. If you've got malware, you should
| consider all your credentials fully compromised.
| nabakin wrote:
| 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.
| surfsvammel wrote:
| If I am not using a PIN code, need I be worried?
| 1attice wrote:
| Well, there goes my trust in another old friend. That's a
| downgrade attack for sure.
| lucb1e wrote:
| > That's a downgrade attack for sure.
|
| "... 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
| 1attice wrote:
| Allowing people to choose an insecure means of securing their
| work just is a stochastic downgrade attack.
|
| Think it through.
| [deleted]
| ThatPlayer wrote:
| Not allowing people the convenience they want means they'll
| switch to a method that does. Worst case: a passwords.txt.
| Wouldn't that be a worse downgrade attack?
| bobleeswagger wrote:
| Convenience is the enemy of good security.
| forty wrote:
| Of course the PIN can be brute forced. It feels like reporting "I
| can walk over the lawn fence". That PIN is probably here to
| prevent your kids from messing with your vault when you grab your
| coffee with your computer unlocked.
|
| 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 a la
| signal using secure enclaves https://signal.org/blog/secure-
| value-recovery/
| ar9av wrote:
| Bitwarden argues that the finding is out of scope because from
| what I can gather the claim that exploiting this requires
| access to the device. If that were the case, I'd agree with
| them. But having access to the Bitwarden database is not the
| same as having access to the device. There are plenty of
| vulnerabilities that give you limited read access. Simply
| selling your hard drive without erasing the data first would be
| a very common scenario.
|
| 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.
| ddulaney wrote:
| I really like the way 1Password and MacOS work together for
| security [0].
|
| 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-...
| KennyBlanken wrote:
| KeepassXC does the same thing. Once you enter your
| password, you can unlock with your fingerprint.
| jeremyjh wrote:
| It's one thing to offer a pin for quick unlocks, and quite
| another to allow that pin to be the only key required to
| unencrypted the files stored on the disk. A pin should only
| secure the master key in memory; it should not even be possible
| to write passwords to disk with such weak encryption.
| nabakin wrote:
| > Of course the PIN can be brute forced.
|
| 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.
| andrewxdiamond wrote:
| The user does not need to be aware of the threat model.
|
| 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
| teekert wrote:
| I always wonder, with a keylogger on my device, I'm probably
| more f-ed using my master password all the time, right? Isn't
| that a large threat? Larger than the one from op?
| mcronce wrote:
| I agree with you. Short PINs are for preventing well-
| intentioned people from accidentally using the wrong account
| (which I do consider quite valuable, for the record) - not for
| keeping bad actors out.
| badrabbit wrote:
| Ugh..no it does not work that way.
|
| 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.
| forty wrote:
| I agree with the mindset and that's why I think it's good the
| data is still encrypted even if, as the author mentioned,
| they might as well have left the data in plaintext.
|
| 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.
| badrabbit wrote:
| If it is not the default behavior then I agree with you.
| flxy wrote:
| This is not the default behaviour and it has to be
| enabled per client/platform. The first unlock after a
| reboot still requires the master password as well.
| aidenn0 wrote:
| I've been using bitwarden for years and didn't know this
| feature existed, so it at least wasn't the default in the
| past.
| femto113 wrote:
| There really needs to be another standard class of
| vulnerability besides "physical access to the device" along
| the lines of "access to a copy of the on disk data". There
| are so many paths to this and some never required physical
| access or even an accidental exposure on the part of the
| user, it could be a breach of a provider (ala LastPass).
| foobiekr wrote:
| FDE doesn't matter at all since a running system is going to
| have the volume mounted.
|
| 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.
| d1lanka wrote:
| Where's my KeePassXC gang at.
| asveikau wrote:
| They could make it take more time to derive a key from a pin.
| That would make it more difficult to brute force.
| IshKebab wrote:
| Consider how long you need to make it before it is infeasible
| to brute force a 4 digit PIN.
| lyu07282 wrote:
| They do that already:
|
| > 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.
| [deleted]
| progbits wrote:
| The pin space is just too small. What's the longest an user
| is willing to wait? 10 seconds?
|
| 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.
| eviks wrote:
| It's not too small, your not limited to just numbers in
| your PIN on a computer
| [deleted]
| Veliladon wrote:
| The silly thing is that Windows already has Windows Hello and its
| accompanying APIs which can be used to guard something like it
| with anti-hammering protections. Ditto for macOS and the Secure
| Enclave. I know it's not 100% of its market but using those two
| features could drastically improve security for the vast majority
| of people who pay no mind to things deep down in the weeds such
| as this.
| fortran77 wrote:
| I think that's why the POC was on Linux.
| cma wrote:
| Weirdly chrome seems to prompt for windows hello pin to view
| passwords but not to auto fill them. Is it using the TPM to
| store them securely in any way?
| jeroenhd wrote:
| Windows Hello and TouchID are supported according to this blog
| post: https://bitwarden.com/blog/introducing-desktop-
| biometrics/
|
| 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.
| kayson wrote:
| Bummer that its not usable on the browser extension though. I
| used to have the desktop app but it ended up being mostly
| useless. 99% of my passwords go into the browser where I want
| autofill, and for the rest I almost always have a browser
| open anyways so I can just as easily copy/paste from the
| extension as the app.
| jeroenhd wrote:
| You can use biometrics in the browser app, but you have to
| run the application and unlock _that_ with biometrics after
| enabling browser integration in the settings. You also can
| 't use the Windows Store version of the Bitwarden app.
|
| https://bitwarden.com/help/biometrics/
| Wowfunhappy wrote:
| > 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.
|
| 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.
| Veliladon wrote:
| >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.
|
| 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.
| jeroenhd wrote:
| I know it has been, but Windows Hello doesn't seem to be
| available for my 7700k after explicitly enabling the fTPM.
| I think it requires TPM 2.0 support, which hasn't been
| supported for all that long.
| waboremo wrote:
| Windows Hello doesn't require 2.0, it works on 1.2.
|
| 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.
| jeroenhd wrote:
| My CPU doesn't support TPM 2.0 with fTPM (and the
| motherboard manufacturer stopped selling TPMs for my
| motherboard years ago) so I'm sticking with Windows 10.
| It told me I could upgrade at some point but that was a
| false positive. Maybe my install is just broken in some
| way.
|
| 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.
| Veliladon wrote:
| You're thinking of HVCI which requires Mode Based
| Execution Control only available on 8th gen Intel or
| later and Zen 2 or later.
| asmor wrote:
| Intel only added PTT - their soft TPM - with Coffee Lake.
| Macha wrote:
| With that said, after a nasty experience with the zen 2
| fTPM repeatedly resetting, I have a hard time trusting the
| reliability of the AMD fTPM.
| cryptonector wrote:
| I'm not sure if fTPMs have endorsement key certificates. I
| should know, but mostly I work with dTPMs and vTPMs. Not
| that an fTPM not having an EK certificate is a big deal --
| if you bootstrap a public key for it early enough in OS
| installation, you can just trust the fTPM.
| capitainenemo wrote:
| I'm not sure what qualifies as "lacking" but fingerprint
| unlock is definitely a thing in Linux. I set it up on my IBM
| laptop over a decade ago.
|
| 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.
| jeroenhd wrote:
| Fingerprints work great in modern Linux distros (I use them
| for sudo and sometimes unlocking my display), but the
| fingerprint hardware and the TPM don't seem to talk to each
| other. Windows Hello (and I presume TouchID) is set up to
| handle authentication and authorization together in one
| well-secured kernel blob with all kinds of TPM trickery to
| ensure security.
|
| 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.
| capitainenemo wrote:
| I had no particular desire to use TPM thus far, but
| you're right, searching briefly on this, it seems the
| tcscd daemon written by IBM provided by the "trousers"
| project does not seem to have any PAM integration. That
| said, presumably you could plug the 2 together (pam and
| tcscd) with some random script, right? Sure, that doesn't
| avoid the brute force scenario, but if it's just to store
| some ridiculously long random key so you don't have to
| type it in, it's not going to get brute forced anyway.
| (although in that case, why bother with the TPM?)
|
| 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...
| jeroenhd wrote:
| I think it could work, but I wouldn't want to protect my
| banking passwords and credit card details behind some
| random script.
|
| 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.
| capitainenemo wrote:
| Yeah, I understand... but follow me here. If I'm using a
| 50 character randomly generated password on a website
| using my typical ({a..k} {m..z} {A..H} {J..N} {P..Z}
| {2..9}) token generation, then they are going to be brute
| forcing 6x1087 combinations right? That's not happening.
| So. Randomly generated passwords for sites, managed by a
| password manager, are much like device bound keys, but
| with the added advantage that I can still type it into
| something that doesn't support the device if I really
| need to... I still like the _idea_ of dongles especially
| to enhance the master password. I just don 't see what it
| wins me over a random site password.
|
| 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?
| waselighis wrote:
| Maybe unrelated to the original article, but I tried Windows
| Hello once. Upon reboot, my PC couldn't connect to the internet
| for some reason, so I wasn't able to login. I got locked out of
| my own PC because it couldn't connect to Microsoft's servers to
| verify my password, and there's absolutely no workaround to
| this problem. It won't use a locally cached password to login,
| it verifies your password with Microsoft's servers. Every.
| Single. Time. There's no way to use another device either. I
| recall, back in the day, you could activate Windows XP without
| internet by calling a number which would give you a long code
| to type in and would activate Windows. But nothing like that
| exists for Windows Hello. No internet? Tough luck.
|
| In the end, I had to reinstall Windows and I'm never touching
| Windows Hello again.
| waboremo wrote:
| I think you're confused. Windows Hello works offline. You
| were probably trying to sign into your Microsoft account,
| which IS online.
|
| Mind you, the forced Microsoft account for new Windows 11
| users is a huge problem. But it's a different one.
| jjeaff wrote:
| I am using my Microsoft account to login to my windows 11
| systems. And they do seem to cache for offline access.
| Because I am still able to login without internet access.
| waboremo wrote:
| Thanks for letting me know, I couldn't find any reputable
| sources on if they cache for offline when used with a
| Microsoft account.
| vel0city wrote:
| I've been using Windows Hello and Microsoft accounts for
| login on devices for a few years. Its worked for offline for
| me literally many thousands of times across several devices.
| GordonS wrote:
| I've never had the problem the GP had, but I have had
| Windows Hello "forget" biometrics were even configured -
| it's happened at least 3 times now, I guess after a Windows
| Update. Each time I go to login with a fingerprint, but it
| gives an error message and insists on the password instead,
| and then I have to setup Windows Hello from scratch.
|
| It's mind-boggling how shit Windows Hello is :-/
| Dalewyn wrote:
| Security enthusiasts will scream bloody murder, but fact of
| the matter is nothing beats a simple password for balancing
| security and practicality.
| SparkyMcUnicorn wrote:
| I remember some of the piracy tools activated windows by
| generating these phone codes.
| willis936 wrote:
| KeepassXC does this on Windows (and is free). Strongbox uses
| secure enclave for master password storage on iOS.
| Wowfunhappy wrote:
| It's a tricky problem, because on devices without biometric
| authentication I _really_ don 't want to type in my long master
| password every time!
|
| 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?
| asmor wrote:
| You don't actually need biometrics, you just need a TPM to
| handle your pin-to-password function with an attempt limit.
| Wowfunhappy wrote:
| Okay, but my laptop doesn't have that either.
| cryptonector wrote:
| How old is your laptop?
___________________________________________________________________
(page generated 2023-03-19 23:00 UTC)