101–110 of 264 posts
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.
Earlier quoted context omitted.
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 iterat…
That sounds like a good idea. Using device-specific keys sounds a lot like Keybase to my naïve ears. Are there any major differences in your design and theirs?
That said, one area that Keybase compromised on that we haven't is offering a web interface. It's well known among security and encryption people that you can't do serious end-to-end encryption in a web app--an attacker with access to the server can just modify the html/js payload, rendering the encryption pointless.
Of course, web interfaces are convenient and users want them, so many products give in on this for the sake of UX even though it fully undermines the zero-trust model. EnvKey hasn't though. It has a desktop app and a CLI--there's no web interface.
Earlier quoted context omitted.
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 "some…
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, t…
That being said regarding Vaultwarden, as someone who contributes to a self-hosting platform, I interact with a lot of self-hosters. And self-hosters do a lot of really dumb things that aren't secure, and, of course, tend to add a public DNS endpoint to their password manager. :P
People put a lot of investment into the concept of making passwords super secure. For most passwords, that is silly and probably does more to increase risk. I would argue a password you can remember + 2FA is much safer than a password generated by a password manager, and any platform smart enough to support 2FA is also not going to give you unlimited password attempts.
But the biggest issue I have with people's views on password complexity and password managers is the idea that all passwords should be equally secure. (Or even, that you "must use a unique password on every site".) I sign up for a lot of crud. Usually it's because something made me sign in to read or comment or something, or a one-off purchase where I'm not even storing my payment credentials. If we're talking about risk profile, these aren't passwords that need to be heavily secured. But if you treat them like they must be, you'll end up using a password manager, likely for all of your accounts, including making your more important accounts, like your email and bank, less secure.
Understand the risk of an account getting compromised, and set it's password accordingly. Absolutely use bad worthless passwords on one-off sites that can't impact you much. Heck forget those passwords, and reset them if you ever need to come back to the site. Password resets are cheap for things you rarely go to.
Turn 2FA on everywhere, and ensure your important passwords are high quality and unique. If you have a bad memory, create some sort of portable reminder, or if you have to write your passwords down on a card or something... lie on it in a consistent, easy to remember way.
Earlier quoted context omitted.
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 iterat…
That sounds like a good idea. Using device-specific keys sounds a lot like Keybase to my naïve ears. Are there any major differences in your design and theirs?
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/ Both Bitwarden and LastPass should improve this situation by making the iteration…
I still think it's maddening that LastPass's website says that the vault is encrypted, yet in reality that wasn't and may still not be the case, where aspects of the vault as we now know aren't encrypted. Unless I'm missing something, to me that is one of the biggest failures. It is even laid out in their technical and organizational measures document.
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/ Both Bitwarden and LastPass should improve this situation by making the iteration…
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-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…
Earlier quoted context omitted.
And less resilient. If your notebook is destroyed (e.g. dog eats it, fire, water damage, et al) then all your passwords are gone. With most good password managers you can actually backup and store a copy of your vault data locally.
I installed BackBlaze years ago for my 88-year-old mother-in-law. She has a binder besides her computer with a sheet for each account, some with 7 or 8 passwords scratched out and replaced. I really should have her write out a few key passwords and put them in an envelope for me to keep.
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…
keepassxc does this the right way — you're not picking the "iteration count" (which is hard enough to understand even for someone relatively technically inclined), but the time it takes to open the database. The default is 1 second, with the minimum of 100 ms. "Higher values offer more protection, but opening the database will take longer". I highly recommend keepassxc to everyone instead of these password-solutions-…
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.