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.
Bitwarden design flaw: Server side iterations
171–180 of 264 posts
Re: Bitwarden design flaw: Server side iterations
#172I 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…
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.
Re: Bitwarden design flaw: Server side iterations
#173I, 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.
keypass works great! Nobody knows or has your passwords except you, and you still only have to remember one complex password. password managers aren't the problem, it's the idea that other companies should have access to all your stuff.
Re: Bitwarden design flaw: Server side iterations
#174Re: Bitwarden design flaw: Server side iterations
#175Tangentially 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…
> why would a password manager provide a configurable iteration count? Because end user devices vary a lot in speed.
Benchmark it once on each device. Then have a user-friendly slider.
"Do you want your security to be:"
a) "It only secures pr0n from my aunt" (1s for fetching a password) b) "Not great, not terrible": (5s for fetching a password) c) "Pretty Good Protectivity": (10s for fetching a password) d) "The CIA haunts me and my name is Edward: (24 minutes for fetching a password)
Re: Bitwarden design flaw: Server side iterations
#176Earlier quoted context omitted.
Nit: yes, it's true that making the iteration count high could actually make some devices unlock very slowly. BUT: - This only occurs when performing key derivation, i.e. when you're unlocking. It does not matter once the key is in memory. Therefore, it's actually OK if it takes a few seconds. When unlocking with biometrics, the key derivation function is not used, so on mobile devices, this occurs even less often. -…
Bitwarden already takes a couple of instants more than I'd like, each time the vault is unlocked in my phone. It's always one of those moments where I'm doing something that requires a new login, and usually the step of having to derive attention to the password manager is an undesired distraction, agravated by watching an idle screen for at least a couple of seconds while the vault decides to open, and at last I can…
> fuzzy fingerprints due to stuff
lol
Re: Bitwarden design flaw: Server side iterations
#177Tangentially 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…
> why would a password manager provide a configurable iteration count? Because end user devices vary a lot in speed.
and even then there should be no way to offer a completely insecure iteration count to a user because one of their devices is slow because the attacker's devices won't be.
Even on slow devices, password managers can employ techniques to help like only using the full count of rounds for a cold start but then re-encrypting the key for the vault key with fewer rounds but only keep that copy locally.
That way a user of a very slow device only needs to wait for, say, 10s once on first unlock.
While this is a downgrade in security, it's still better because now the key with the small amount of iterations is confined to the one device, not available on the server where an attacker can get bulk access.
Of course, devices where 1M PBKDF2 iterations take so long that it's noticeable are probably also old enough to be full of unpatched (due to EOL) security holes which makes such devices the weakest link anyways, but this would still be a better situation because this way not all users are punished because of one user's slow device.
Re: Bitwarden design flaw: Server side iterations
#178If 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
Re: Bitwarden design flaw: Server side iterations
#179Earlier 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…
What are your expected failure modes? Consider this pretty common scenario: ahe user lost their one and only enrolled device. How can the user reinstate access? I suppose the user must have printed the real root password / secret key / whatever and put the paper somewhere in a safe. That password should allow to reinstate access when all hardware is lost. But it should not be required daily.
Apples solution for this with their new hardware 2fa stuff is to not let you turn it on without registering two hardware keys. So perhaps forcing two enrolled devices might work? (I have all my totp seeds on my iPhone and my iPad, for that reason.)
Re: Bitwarden design flaw: Server side iterations
#180Earlier quoted context omitted.
The current (and very recently updated) OWASP recommendation[1] is a minimum of 600 000 iterations [1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
I read that as a "total of 600 000" iterations, so 300 000 locally and 300 000 on the server. Am I wrong?
According to the OP article, the server side iterations are ineffective for adding security in bitwarden, so you need 600,000 on the client. This would not be the case if the design was correct.
(I'm not a security expert, so I'm going by the article)