17 ms·

Bitwarden design flaw: Server side iterations

• doodlesdev 4y ago
  Other than the low amount of default iterations (at least compared to the OWASP recommendation [0]) the article doesn't explain why the server-side hashing is "useless" and what the design flaw actually is. Am I missing something? [0]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
  • curyous 4y ago
    If I understand correctly, the problem is that the hash created on the client side is used to create the encryption key before the server side hashes are applied. Only the master password uses the extra server side hashes.
  • artjomb 4y ago
    I disagree with the article that server-side iterations in this case are useless. They are used for access control. Bitwarden's API likely doesn't permit anybody to access the encrypted blobs of anybody. You have to authenticate at the server to be able to access your blob. Since the iterations might be low for producing the master key and therefore the master password hash, the server must treat the master password hash as just another password and therefore iterate the hash quite often (100,000x). Assuming no malicious insider or an outside attacker gets their hands on the encrypted blobs this is the most important attack prevention.
  • amarshall 4y ago
    Quoting directly: > the 100,000 PBKDF2 iterations on the server side are only applied to the master password hash, not to the encryption key The attacker doesn’t need to break the master password hash, so it’s irrelevant. This is elaborated in the link directly following the above quote: > But that protection only works if the attackers are stupid enough to verify their master password guesses via the authentication hash.
  • FreakLegion 4y ago
    > the 100,000 PBKDF2 iterations on the server side are only applied to the master password hash, not to the encryption key So only the password hash itself gets the extra iterations. The diagram and the text of the whitepaper seem to be at odds, though. The diagram doesn't show extra iterations for the encryption key, but the whitepaper says: > PBKDF-SHA256 is used to derive the encryption key from your Master Password. Then this key is salted and hashed for authenticating with the Bitwarden servers. The default iteration count used with PBKDF2 is 100,001 iterations on the client (this client-side iteration count is configurable from your account settings), and then an additional 100,000 iterations when stored on our servers (for a total of 200,001 iterations by default).
  • rcxdude 4y ago
    It's useless in most circumunstances: it depends on what the attacker has access to. If the attacker only has the master password hashes the server uses to gate access to the encrypted database, then they would need to go through the full 200,000 iterations. But if they have the encrypted database then they can run 100,000 iterations and just try to decrypt the database (assuming this check is cheaper than the 100,000 iterations, which it likely is). And it's far more likely the attacker has the encrypted database (which can be pulled off of any machine which has been logged in, as well as the same database which contains the master password hash, if bitwarden's servers were to be breached) than the master password hash alone.
• soheil 4y ago
  If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.
  • mhluongo 4y ago
    There's a version of this sort of password manager that is safe. Not saying Bitwarden is it, just that strong, well-implemented cryptography can get us there.
  • ilyt 4y ago
    You can self host bitwarden, using either their implementation or open source vaultwarden
    • siwatanejo 4y ago
      Exactly, BitWarden is not as shit as others like LastPass or 1Password.
      • dmak 4y ago
        Have you seen 1Passwords security design? I am not an expert, but wanted to hear from someone is.
        • knocte 4y ago
          It is not opensource, therefore you cannot self-host it, therefore you depend on a thirdparty.
          • dmak 4y ago
            Can one depend on a third party if it's end-to-end encrypted?
• avsteele 4y ago
  I still haven't seen a clear explanation of how the # of iterations scales in relation to password length. If it is true a few extra characters is as good as having sky-high iterations, the guidance should be on 'forcing' users choose long-enough passwords, not in this nitpicking over the 'right' # of iterations.
  • azeemba 4y ago
    Number of iterations being discussed is how many times the password is hashed. It is a setting the system chooses and is independent of the password length the user chooses. If you are asking if the length of the password by itself be sufficient to create a secure password, then the answer is mostly no. You need many iterations of the hashing process otherwise brute force attacks become trivial given today's hardware.
    • Aeolun 4y ago
      A sufficiently difficult password is unguessable even with a single hash.
    • SAI_Peregrinus 4y ago
      Unless you have a high-entropy long password. 10 Diceware words (words chosen uniformly at random from a list of 7776 words) is over 128 bits of entropy, even a very fast hash would be enough for such a passphrase. Of course at that point you've essentially memorized a cryptographic key, not a traditional low-security password. Good for the master password of a password database, not so usable anywhere else.
      • runnerup 4y ago
        I'm not super practiced in hashing theory. If the 10 words were usually longer than the hash function output (say, starting at an average of 7 words), would adding more characters (words) still increase the entropy or would the entropy get truncated?
        • 4y ago
• ywain 4y ago
  Oof, my Bitwarden account was created a while ago and was set to only 5,000 iterations. You can see and change the number of iterations here: https://vault.bitwarden.com/#/settings/security/security-keys https://vault.bitwarden.com/#/settings/security/security-key... (or if you don't trust links for something like your password manager: log into your web vault, click on the top-right dropdown menu, then Account settings > Security > Keys). I've updated it to 600,000 iterations and so far don't see any noticeable impact on performance, both on desktop (using the Firefox extension) and on mobile (iOS).
  • ajorgensen 4y ago
    oof me too thanks for the nudge to check!
  • mkasberg 4y ago
    I had bumped mine up once before (to 200K) and I just bumped it up again to 600K. But my wife (registered several years ago, like me) was still at 5K, I just bumped hers up too. Wish Bitwarden would force this for anyone still on an old default - particularly given the LastPass compromise we just saw.
  • philliphaydon 4y ago
    Thank you! Mine was also set to 5000, updated to 600k.
    • rstuart4133 4y ago
      A way to think about the difference you just made is, you increased the difficulty of cracking your password by 600000 / 5000 = 120. Making your attacker guess 7 extra bits (well, slightly under) would have the same effect, so that translates to a slightly under 7 bits of entropy. Appending two randomly chosen digits to your password would have about the same effect. Those first 5000 iterations added over 12 bits of entropy. The article is complaining about not adding an extra 100,000 iterations which would double the difficulty, so he's effectively berating them over 1 bit of entropy.
  • zeven7 4y ago
• jchw 4y ago
  While the practice of not updating PBKDF2 iterations is bad, I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts. Because truthfully, the PBKDF2 iterations count issue was relatively unimportant. Some good conjecture about it: https://neilmadden.blog/2023/01/09/on-pbkdf2-iterations/ https://neilmadden.blog/2023/01/09/on-pbkdf2-iterations/ Both Bitwarden and LastPass should improve this situation by making the iteration count automatically increase over time. For LastPass though, there are... A lot of concerns. The breach, how it was handled, persistent issues with the security of their browser extension (many, including an RCE at one point) and of course the fact that not everything in the vault is actually encrypted. KeePass XC or 1password may prove to be better options from a strict security practices standpoint, but from what I've seen I don't suspect Bitwarden has a pattern of bad security practices overall. It does seem like there are opportunities to make it better, though.
  • danenania 4y ago
    We took a similar approach to passphrase stretching in EnvKey v1 [1] (EnvKey is a secrets manager, not a password manager, but uses end-to-end encryption in a similar way). We used PBKDF2 with iterations set a bit higher than the generally recommended levels, as well as Dropbox's zxcvbn [2] lib to try to identify and block weak passphrases. Ultimately, I think it's just not good enough. Even if you're updating iteration counts automatically (which is clearly not a safe assumption, and to be fair not something we did in EnvKey v1 either), and even with safeguards against weak passphrases, using human-generated passphrases as a single line of defense is just fundamentally weak. That's why in EnvKey v2, we switched to using high entropy device-based keys for our root encryption keys. It's a similar model to SSH, except that on Mac and Windows the keys get stored in the OS keychain rather than in the file system. Also like SSH, a passphrase can optionally be added on top of the device key. The downside (or upside, depending how you look at it) is that new devices must be specifically granted access. You can't just log in and decrypt on a new device with only your passphrase. But the security is much stronger, and you also avoid all this song and dance around key stretching iterations. 1 - https://github.com/envkey/envkey https://github.com/envkey/envkey 2 - https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
• fortran77 4y ago
  My biggest problem with LastPass is they didn't encrypt all the data. I use very long master password so I feel protected enough with Bitwarden.
• fomine3 4y ago
  I don't know is it called design flaw. Lesson is that all iterations must be updated without user's explicit action.
• gclawes 4y ago
  Holy shit, firefox is only using 1000 iterations?
  • skippyhammond 4y ago
    Not to excuse the behavior in that bug, but the situation is very different for Firefox than for BitWarden - as the blog post notes, 1000 iterations is only used for the key as it is in-flight via https to Mozilla's production servers, not when it is at rest. An attacker getting access to any encrypted databases would need to deal with scrypt, not these 1000 PBKDF2 iterations.
• pilif 4y ago
  Tangentially related: why would a password manager provide a configurable iteration count? This is a number whose purpose is fairly hard to understand for many people and yet it’s an important corner stone for password security, especially for those who do not grasp the concept of an iteration count. This should absolutely be application managed and gradually increased over time. Also: while I understand that FIPS is the reason why we are stuck with PBKDF2 in the case of the more enterprisy password managers, wouldn’t it still be FIPS compliant to do some scrypt or argon rounds on top as a means of not constantly having to update the PBKDF2 iteration count (assuming that scrypt and argon are more resilient to hardware brute-forcing)?
  • FreakLegion 4y ago
    I don't think "on top" gets explicit guidance, but it's also almost never needed. In this case for example scrypt and yescrypt are fine to use directly. NIST has had a strong leaning toward memory-hard functions for coming up on six years now. See §5.1.1.2 in https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 https://pages.nist.gov/800-63-3/sp800-63b.html#sec5.
    • runnerup 4y ago
      I'm not familiar with FIPS. Is this NIST document part of requirements outlined in the FIPS publication? Which according to 20 seconds on Google, appear to be numbered 140, 180, 186, 197, 198, 199, 200, 201, and 202.
      • FreakLegion 4y ago
        Password hashing is controlled by NIST SP 800-63B, not FIPS, but FIPS supplies the approved primitives. When NIST says: > The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185]. Those options are authorized by FIPS. The main consequence of this is that there are FIPS-validated implementations available, which are what you want if you're selling to the government.
• aarc 4y ago
  Good to have the heads up. I just bumped my KDF iterations from 100000 to 600000. One thing that is also worth mentioning for anyone nervous about their password security is that you can use a physical security key with the paid version of Bitwarden. I need to use a yubikey to log in to any new instance of Bitwarden and it's been working well.
  • 416chad 4y ago
    As I understand it, the OTP factor only protects the login. While this is still good practice, it wouldn't help in the event the vaults are stolen.
    • g_p 4y ago
      Yes, 2FA/MFA only serves as access control, to limit who can retrieve a copy of your encrypted vault from the server (to then decrypt locally). Like in the Lastpass scenario, if someone gets a hold of your vault from a server side backup (or compromise), then your access control is bypassed, and won't make your vault harder to decrypt. Using MFA is definitely good practice though, as in normal circumstances an attacker will be trying to get to your vault without server side access.
• wereallterrrist 4y ago
  tl;dr rant, and not an exaggeration: the amount of time I've spent skimming these (edit to be nicer) exhausting comment threads about password managers has taken 10x the amount of time it took to use a pass-compatible or age-based password manager. Okay, here we go, let me be explicit: there's a Venn diagram I imagine in my head of two circles - first is "password managers that require a web ui and browser integration", second is "password managers written in a language and with an overall complexity that I'm comfortable with". For certainly-informed users, there's ZERO overlap in 2023. what's super fun is that this comment would get entirely different scores in yah, every 2 years for the past decade+ now. (think abour Rust circa 2021, 2019, 2017, I feel confident saying... for well most, opinion has been shifting in a certain direction). luckily recently there is a tool which is, 1. rust-written 2. pass, pass-totp, and pass-tomb compatible 3. hasn't yet broken the CLI UX in nearly every release like another prominent "safe-lang" re-write of pass. that's all I'll say because it turned into a many-paragraph rant otherwise. I'm trying so hard to watch myself here, but it's just not that hard. Let's imagine what needs to break for me to compromise your WV account versus what you'd need to compromise my public-hosted git-repo-backed yubikey-hardended-gpg-encrypted pass accounts. "I'll post mine if you post yours?"
  • runnerup 4y ago
    > luckily recently there is a tool which is, ...and that is???
    • BrightOne 4y ago
      Not GP, but https://github.com/timvisee/prs https://github.com/timvisee/prs seems to fit the bill.
      • timvisee 4y ago
        Thanks for mentioning prs [1], dev here! :) Yeah it definitely meets those requirements, being written in Rust, supporting pass, TOTP, Tombs amongst other things out of the box. Though its CLI is slightly different than classic pass. That is on purpose in fact, to achieve a better UX and less ambiguous commands. [1]: https://github.com/timvisee/prs https://github.com/timvisee/prs
• ocdtrekkie 4y ago
  Embarrassments will continue until everyone realizes all the "security experts" recommending password managers have marketing deals with them. Password managers are an awful antipattern, I've been saying it for years, and it's absolutely comical to me that people do not get the message. When one falls, it's "oh that one sucked, use this other one instead". An Internet-connected data vault is subject to attack from anyone on the planet. A Post-It stuck to your monitor is only subject to attack from people who can visually look inside your office. Guess which is safer? Once you realize a Post-It is a better choice, and you can think of trivial ways to improve on that... why are people storing their passwords online?
  • plaguepilled 4y ago
    What about offline only managers?
    • ocdtrekkie 4y ago
      Is it stored on a device which connects to the Internet? It's online! I think there's a role to play for things like KeePass when you need to share some secret values with family or team members, but it shouldn't be for high security things. Two-factor authentication is probably our best practical defense right now, and generally the best way to do that is not to have your password saved anywhere: Two-factor is "something you know and something you have". If your passwords are stored somewhere, it's just two things you have. If, like some Bitwarden users, you backup your 2FA tokens in your password manager, 2FA is just one thing you have. An using a password poor enough for you to remember and a two-factor token is better than just two separate apps on your phone.
      • plaguepilled 4y ago
        Ehhhh, I dunno on that one. I think "stored on an end user device" is quite different from "stored on a server with a public address". Firewall rules differ, for one. ISPs are more restrictive on what they flag as suspicious for domestic connections for two. Yes it would be better if the password manager were airgapped but that's a bad trade off in terms of user inefficiency and risk reduction IMO. In the same way, the reduction of attack surface by using post-its seems dulled by the consequent decrease in password complexity caused by people deciding their own passwords (since people subconsciously apply patterns to "random" strings they generate). This isn't to say "post its are bad" or "password managers good" but I am pushing back at the categorical statement of "post its good, managers bad". It seems contingent on risk profile.
• ChrisSD 4y ago
  > Even if you configure your account with 1,000,000 iterations, a compromised Bitwarden server can always tell the client to apply merely 5,000 PBKDF2 iterations to the master password before sending it to the server. The client has to rely on the server to tell it the correct value, and as long as low settings like 5,000 iterations are supported this issue will remain. This seems like a serious flaw that completely undermines setting a custom value, no? If an attacker gets temporary control of a bitwarden server then they can get your password in a more easily crackable form no matter what you set.
  • runnerup 4y ago
    The only way around this would be to require a human to set the # of iterations independently on all client devices. Because if you change the # of iterations using your laptop, the server wouldn't be able to tell your phone that the # of iterations has changed. Instead you just wouldn't be able to log in until you ALSO manually changed that setting on your phone to match the new server configuration that you set with your laptop. That would be pretty poor UX. So yes, it's a flaw. But I don't see an acceptable mitigation for it, as all clients will have to be compatible with passwords for accounts that were last logged into 10 years ago when [super_low_iteration_number] was still considered an acceptable value. And the server will have to be able to tell the client "This account was last logged into 10 years ago. We're going to increase the number of iterations right after this, but just one last time, send me the password after hashing it 5,000 times."
    • aflag 4y ago
      Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?
      • silverwind 4y ago
        Clients could dynamically determine a value based on performance. That way, the encyption gets more secure the better the hardware gets.
• avinassh 4y ago
  Why is the iteration needed if I choose sufficiently strong passphrase? Think 40 characters
  • zeroonetwothree 4y ago
    It's not really needed if your password has a lot of entropy. 40 random characters is like 256 bits or something so that's crazy overkill and would be safe regardless of how many iterations.
  • masklinn 4y ago
    If your password is very long and randomly generated and not used anywhere else then probably not. But it doesn’t hurt. The iterations count regulates how fast an attacker can check a guess of the clear text.
• sacnoradhq 4y ago
  - PBKDF1 (1.0 ?, 1.5 1993) - PBKDF2 (2.0 2007 RFC 2898, 2.1 2017 RFC 8018) <- This is here, although it was revised in 2017. - bcrypt (1999) - scrypt (2009) - argon2id (2015) <- Have we not yet evolved to address threats here? What about minimum resource complexity (mem-/CPU-/GPU-/FPGA-/ASIC-hard) guarantees on the client (assumed trusted, as much as one can trust)? Picking one number out of the sky for today that doesn't evolve with technology doesn't make sense. Plus, it isn't necessarily something a human shouldn't be choosing for every use-case without a risk assessment. There should be a sanity-check lower bound that evolves with best-case performance coupled with a specific threat environment. Calculator website with: 1. "Which algorithm?" (some choices) 2. "What type of data is it?" (Level 1 - 6 with familiar descriptions) 3. "How long does it need to be protected?" (1...100 years in almost log progression) 4. "How much is the data worth?" (some choices, or 1e2 ... 1e11 USD / other currencies) 5. "What would be the consequences of its disclosure?" (with familiar descriptions) 6. "What model of device will slower users have?" (some choices of new to old laptops and touch devices) 7. "Funding amount of highest reasonable threat actor?" (some choices, or 1e5 ... 1e12 USD / other currencies) 8.-11. "What is a(n) {un,}reasonable {un,}lock delay?" (ms) And then output parameters (n, salt/nonce sizes, factors) and password complexity requirements valid for implementation now. It would also be nice to output an algorithm generated to forecast values needed X years in the future with similar guarantees.
• sMarsIntruder 4y ago
  So just FUD? An entire article for saying that they should increase the default number of interactions? You can do better if you have to do FUD.
• roflulz 4y ago
  is apple keychain safer than all these 3rd party options now?...
• karlkloss 4y ago
  I, personally, think that password managers contradict the idea of passwords. A password is something that YOU know. You and nobody else. Ideally not even the system you access. If you write it down, give it to somebody else, put it in the cloud, etc., the password isn't safe anymore. If you can't remember your passwords, then use something else.
  • crumpled 4y ago
    Offline password managers.
  • daveoc64 4y ago
    > I, personally, think that password managers contradict the idea of passwords. A password is something that YOU know. You and nobody else. Ideally not even the system you access. That's the theory of passwords, but it has been demonstrated that most people simply can't manage their passwords. I have about 600 passwords stored in my password manager. Without a password manager, I'd have to reuse passwords (either partially or fully) to manage all of that. A much better option is to get my password manager to generate a random password for each of those sites. My Hacker News password, for example, is 60 characters long and contains upper and lower case letters, numbers, and symbols.
    • tatersolid 4y ago
      Not that it matters much in practice, but a 60-character uniformly random password is overkill. Given that a 128 bit key is considered secure and one may occasionally need to type a password due to technical constraints, 21 randomly selected characters from a 72-character alphabet is enough. Double it if you want to target 256-bit security, but the threat model here doesn’t really support that. Are you expecting a large-scale quantum computer attack on the HN password hash database?
  • pscho 4y ago
    > Ideally not even the system you access. But you really can't know if the system handles passwords correctly or just stores them as plain text into a database. And memorizing a unique password for each system you want to access seems like a hard task.
• crumpled 4y ago
  I once leaned heavily upon Google Chrome as my password manager, but then I discovered that you could view the passwords in Chrome for Windows by knowing my Windows login password, instead of my Google password. This feels off topic a little, but in all the discussion of password managers lately, I seldom hear people talk about the web browser being a good/bad idea. It almost feels like they are slipping through the cracks of the conversation. For the record, I no longer use that platform for important passwords or secrets, ("driver carries no cash")
  • amelius 4y ago
    I personally use Firefox Sync (it's built in the browser) and am very happy with it.
    • Someone1234 4y ago
      The article talks about a security weakness with Firefox Sync in the same vain.
      • amelius 4y ago
        Good point.
  • mk_stjames 4y ago
    I noticed this as well, I used to do the same and so did everyone I know. I stopped used any Chrome based solution after seeing that if my Chrome was sync'd to my phone, and my phone was unlocked, someone could open Chrome on my phone and, with only my phone's PIN to unlock the vault, view all my passwords. This seemed super weak. So I switched to a different method of storing and generating passwords. But as far as I know, most people I know just use Chrome's password manager. And you know... I haven't ever heard of a Google breach where vault databases have been breached...
  • kibwen 4y ago
    Note that if you have autofill enabled on website login pages, then password-protecting the browser's password store doesn't do anything. Anyone with your Windows password can just go to any website, autofill the password, and then copy the password out of the page itself. Try it on HN, go to the login page and run `document.getElementsByName("pw")[0].value`. To say nothing of the fact that, if they used some method to divine your Windows password, then they've probably already done the same for your password manager's password. And even if they only had your Windows password somehow, they could just install a keylogger to get your master password anyway. And even if you 2FA your password manager, the keylogger can still intercept any other password and take over any non-2FA'd accounts.
• shp0ngle 4y ago
  > This means that you need a strong master password. And the only real way to get there is generating your password randomly. Hm but how will I remember that? Maybe I’ll use a different password manager… :)
  • tlamponi 4y ago
    > Maybe I’ll use a different password manager I do that. I use pass <https://www.passwordstore.org/ https://www.passwordstore.org/> to store and get my BitWarden master PW. Pass is encrypted by a PGP key residing on my HW token/smart card and encrypted with a good but (for me) memorable PW. In my case it's not really due to paranoia, but as I already had pass in use for critical and very important credentials before, and as I 1) was only evaluating BitWarden first and 2) did not want to remember two master passwords, so I went for this approach, and it works out quite well for how I use BitWarden (basically only on my workstation where I require my HW token anyway).
    • iLoveOncall 4y ago
      I'm always surprised that people disclose so easily their whole security pipeline on HN, especially when their account has their real information.
      • tlamponi 4y ago
        Yeah, a developer owning a YubiKey and using a password manager, that's really revealing... Unless you're in for the criminal acts (and their repercussion), i.e., stealing my token and my keys to wherever my workstation stands and then torturing out both, my workstations and key's PW from my mind, it won't really help you... Or what did I really reveal with what actual real world implication that can compromise the security of (which?) systems I can access? IMO, if your "security pipeline" can be compromised due to documenting it (not the credentials used to access it!), even publicly, it wasn't that good of a "security pipeline" in the first place.
• Aicy 4y ago
  I self-host bitwarden and you should too! You get the premium features for free when you self host This is an excellent step by step tutorial that tells you how to self host it: https://www.youtube.com/watch?v=eCJA1F72izc https://www.youtube.com/watch?v=eCJA1F72izc
  • MrGilbert 4y ago
    No, you don’t get the premium features "for free": https://bitwarden.com/help/licensing-on-premise/ https://bitwarden.com/help/licensing-on-premise/ What you are referring to is essentially a compatible server implementation called "Vaultwarden" (formerly Bitwarden_rs), where the original company will see no money whatsoever.
  • dns_snek 4y ago
    This is extremely irresponsible advice for anyone who isn't already skilled in securing their systems and keeping their software up to date. Skimming through that video, there's no thought given to securing the OS, "pi" account is effectively given root access (through "docker" group) with a default password of "raspberry", network access is unrestricted, there's no thought given to secure remote access (e.g. a VPN), there are no auto-updates for either the OS or vaultwarden, leaving you exposed in case of future vulnerabilities.
  • 22289d 4y ago
    I've given up trying to self host stuff like that, it's always a nightmare compared to paying for the service. Plausible Analytics being a prime example. Bitwarden can have my $10 a year.
    • XCSme 4y ago
      > Plausible Analytics being a prime example. I would say that in the case of analytics, there are more things to consider than price and ease of installation when considering self-hosting. By not self-hosting you are sending your users data to a 3rd party, which might have impact on their privacy or on the law compliance.
• Havoc 4y ago
  Leaning towards self hosting at this stage. Sure my security skills are no match vs Bitwarden engineers…but I also don’t have a giant state actor sized bullseye painted on my back
  • simooooo 4y ago
    I’m waiting for the bitwarden unified release. Then I might give it a go
• dns_snek 4y ago
  > Testing the guesses against the master password hash would be fairly slow: 200,001 PBKDF2 iterations here. But the attackers wouldn’t waste time doing that of course. Instead, for each guess they would derive an encryption key (100,000 PBKDF2 iterations) and check whether this one can decrypt the data. I don't understand. As far as I know the key space of PBKDF2-SHA256 is 256 bits and the vaults are encrypted with 256 bit AES. Is the author arguing that Bitwarden is insecure because the attacker could (in a roundabout way) bruteforce 256 bit AES? edit: I think I understand, the text didn't make it immediately obvious but I believe the author is talking about (configurable) 100k client-side iterations which are then used to obtain the "stretched master key" (from the diagram). This would render the 100k iterations done on the server pointless if an attacker already has a copy of the data, they only protect (slow down) the normal authentication flow.
• ianpurton 4y ago
  PBKDF2 iterations is the last in what should be a chain of defence in depth best practices. It gives limited protection against a database breach. Your password service should have as a minimum the following extra defences. - Hardware encryption of the master password hashes. - Breach detection such as poison records. - Database access controls that limit the blast radius of an attack. - All admins should require a hardware key to access the database. I'm sure there are many more. You can defend yourself with the following... - by having a very random master password. - 2fa everywhere - password horcruxing - see https://kaizoku.dev/double-blind-passwords-aka-horcruxing https://kaizoku.dev/double-blind-passwords-aka-horcruxing
• andmarios 4y ago
  I am not sure I get the flaw. The author says that the problem is an attacker only needs 100,000 iterations to get the master password hash, instead of doing the 100,000+100,000 iterations to get the master password and the master password hash. Wouldn't though the master password hash be so long, that 100,000 iterations would be really hard to brute-force?
  • rcxdude 4y ago
    The point is it goes master password -> encryption key -> master password hash. The master password hash is only important if you want to download the database from bitwardan's server, the real valuable part is the encryption key, and the attacker is extremely unlikely to have the master password hash but not the encrypted database which they can use to check the encryption key.
    • andmarios 4y ago
      Ah, that makes it clear. Thank you for the explanation. :)
• autoexec 4y ago
  More confirmation that Keypass was a good choice vs popular alternatives. It lets you choose how may iterations you want in the settings and even that won't matter unless someone has access to your offline database.
• chickahoona 4y ago
  If one is looking for an alternative, may I propose Psono? (I am the main developer behind Psono) It doesn't suffer from some of the reported issues and as such uses for example scrypt instead of pbkdf2 for the hashing of the masterpassword and the urls are for example also encrypted. Noteworthy its open source so everyone can take a look at the source code or ask questions in our discord channel. https://discord.gg/RuSvEjj https://discord.gg/RuSvEjj
• macrolime 4y ago
  One way that I've many people using is to have a long random password stored on a yubikey that will be entered on long press, then you have a shorter password that you remember and type in. So when you enter your masterpassword, you first type the part of the password you remember, then long press the yubikey to get it to enter the long static password.
  • KomoD 4y ago
    How would you do that?
    • STRML 4y ago
      https://docs.yubico.com/yesdk/users-manual/application-otp/static-password.html https://docs.yubico.com/yesdk/users-manual/application-otp/s... It's a nice option, but of course you need to back up this static pw somewhere or program a bunch of keys with it.
• zoenolan 4y ago
  A Bitwarden author replied over on Reddit https://old.reddit.com/r/Bitwarden/comments/10jj6fk/bitwarden_design_flaw_server_side_iterations/j5mjqbx/ https://old.reddit.com/r/Bitwarden/comments/10jj6fk/bitwarde...
• KaiserPro 4y ago
  I defer to better people about the strength of the encryption. But the reason why I moved away from lastpass was because the only thing that was encrypted was the password, rather than the whole lot.
• fluidcruft 4y ago
  I have been thinking about this and one way to resolve it is if the encryption data and the login cannot be linked without going through the server iterations. The reason this matters is because the salt for the hashing is the email address. Attacking the encryption key directly requires knowing the corresponding email. So denying attackers that knowledge adds to their burden. If the customer/vault records can only be linked via the server side encryption the attackers with the vaulrs and list of user emails will have to test every email as salt (also reqires some care to ensure logs can't be used to correlate vaults and emails, but all the scenarios I've played out make me think this is possible). In fact I think they could physically separate the customer and vault databases entirely to different servers or datacenters. Initially I thought this might be what Bitwarden does (it seemed pretty clever), but the database schema on github does indeed directly/explicitly link customers and vaults. If the customer and vault datasets were independent, Bitwarden could further complicate attacks by filling the customer and vault databases with convincingly fake entries since the basic database attack surface would scale as the product of customers and vaults.
• gonehome 4y ago
  1Password is excellent. More people would benefit from just paying for it. Their secret key mentioned in the article appears like it was worth the UX tradeoff. They also stand out for other reasons too.
• neonsunset 4y ago
  The website author appears to own a browser extension that competes with Bitwarden. Looks like conflict of interest given the article contents.
• hendersoon 4y ago
  I switched to Bitwarden in early 2018. Just checked and my PBKDF2 iterations were 300k, so everything was fine. I increased them to 600k just for the heck of it.
• nebulous1 4y ago
  > In case you are wondering whether it is even possible to implement server-side iterations mechanism correctly: yes, it is. One example is the onepw protocol Mozilla introduced for Firefox Sync in 2014. While the description is fairly complicated, the important part is: the password hash received by the server is not used for anything before it passes through additional scrypt hashing. > Firefox Sync has a different flaw: its client-side password hashing uses merely 1,000 PBKDF2 iterations, a ridiculously low setting. So if someone compromises the production servers rather than merely the stored data, they will be able to intercept password hashes that are barely protected. The corresponding bug report has been open for the past six years and is still unresolved. Is this not always going to be a flaw with server-side iterations? And therefore knocks down the first paragraph's contention that it's possible to do server-side iterations correctly?
  • moughxyz 4y ago
    It is largely unsolvable if you rely fully on the server. I describe here how we handle this at Standard Notes where the client can reject weak parameters from the server: https://news.ycombinator.com/item?id=34506062 https://news.ycombinator.com/item?id=34506062
• moughxyz 4y ago
  The way we solve server-side iterations with Standard Notes (which uses Argon2 and not PBKDF2) is to tie the derivation parameters (iterations, bytes, etc) to a hard-coded protocol version number. Accounts which register today for example have a protocol version of 004, which corresponds to specific, immutable derivation parameters. For a given user, the client then receives from the server not key derivation parameters, but the version of the account. The client then maps that version to the precompiled derivation parameters. Of course a server can then misreport a user's account version to something lower than it actually is. There are two solutions we implement here: 1. Deprecate older versions as quickly as possible after new protocol version rollouts. Older versions begin to get rejected by clients and clients will not allow sign in to proceed. 2. Allow an optional sign-in flag users can check called "Strict sign in" that forces the client to reject any server provided version that is not specifically the latest version. This means that if a user checks this option and the server reports a version != 004, the sign in will be rejected and the client will not perform any sort of handshake with the server. More here: https://standardnotes.com/help/security/encryption https://standardnotes.com/help/security/encryption
• aftbit 4y ago
  Why do they use PBKDF2 at all instead of more modern scrypt or bcrypt?
• hendersoon 4y ago
  The real vulnerability with password managers is autoupdating browser extensions. That's the disaster on the horizon. They update on their own, all the time. You can turn updates completely off but otherwise cannot control this behavior. Eventually, a password manager's development environment will be compromised and bad actors will sneak a trojaned extension in, submitting it to Google and Mozilla and Microsoft and the rest. Your browser will update to that extension and the bad guys will get everything. Self-hosting won't help, your homelab running vaultwarden in a docker container not exposed to the internet is no protection from this at all. 2FA won't help either when the extension itself is your enemy, it'll simply upload your entire unencrypted vault off to the bad guy on IRC or discord or whatever. (2FA will help on individual sites supporting it, assuming you don't use your password manager to store 2FA tokens too. They all support that functionality, but you don't do that, right?) The only way to avoid this outcome, which again is inevitable, it WILL happen eventually, is to laboriously copy/paste passwords from a separate password vault program that is not configured to autoupdate. The thought of actually doing that makes me cringe, so I'm still using Bitwarden. I know it's coming, and hope it hits another more popular password vault first so everybody gets wise and figures out some solution to this problem. I also use Firefox which seems to have humans reviewing extensions, at least sometimes, and is less popular than Chrome.
• simon04 4y ago
  vaultwarden (an unofficial Bitwarden compatible server written in Rust) has been updated two hours ago via https://github.com/dani-garcia/vaultwarden/commit/2d8c8e18f74726303f7789af9731e8a80ce05610 https://github.com/dani-garcia/vaultwarden/commit/2d8c8e18f7... – - Change default Password Hash KDF Storage from 100_000 to 600_000 iterations - Update Password Hash when the default iteration value is different - Validate password_iterations - Validate client-side KDF to prevent it from being set lower than 100_000
• lazyeye 4y ago
  Question: Would there be any benefit, not just to increasing the number of hash iterations but also changing it to a random non-round number? I would have thought if you were brute-forcing the hashing key it would be worth limiting it to round numbers (e.g increments of 10,000 or 50,000) to increase the efficiency.
• m-p-3 4y ago
  At least I know, so I manually increased the iterations on my account above 600,000 as a safeguard. I'll have to keep in mind to update it in the future.
• Alifatisk 4y ago
  So, as a user, what should I do now?