One of the features most voted, 4 years requesting it. Any plan for 2023?
This is a bad security choice
Bitwarden uses AES-CBC 256-bit encryption for your Vault data, and PBKDF2 SHA-256 to derive your encryption key.
1 Like
Hey @l0rdraiden see earlier comments, including Encryption suggestions (including Argon2) - #24 by cscharf for more information.
Yeah, that wasn’t me.
Good call on them for impersonation, though!
On-topic: Until it’s feasible to implement a better password hashing function than PBKDF2, you’re kind of stuck with it. Blame the JavaScript ecosystem.
AES-CBC + HMAC-SHA2 is fine. AES-CBC is only bad if you aren’t authenticating.
(I haven’t audited bitwarden. Maybe I should.)
2 Likes
JavaScript community seems to be quite well regarding Argon 2.
This lib looks very good to me with MIT licencing which from my understanding should be OK for this project.
WASM and WASM+SIMD support, the performances are reasonably good.
No reason to push back anymore 
I said ecosystem, not community.
Try using WASM in iOS in lockdown mode.
My understanding about lockdown mode in iOS.
Disable many performance oriented features to prevent computational exploits. (including JIT and WASM)
Disabling WASM makes hard to use it, sure.
But where are we going?
Performance was the origin of the pushback, now what happen when you prevent performances directly from your browser.
Maybe argon2 is not the best for everyone. But having the option seems reasonable, as it is apparently the state of the art for password derivation.
And technically nothing prevent to have a second lib in pure JS when WASM optimizations are not allowed.
Hi, I have started a fork for implementing additional key derivation functions. I have done a basic version of scrypt for now, which should already be an improvement over plain pbkdf2 (using the audited and fuzzed library noble-hashes), although for a pull request, it still needs some work.
One thing I would like an opinion on: the current PBKDF only needs an Iteration count, and sends this via tha API / stores it. For scrypt we could get by, by setting the work factor N (which influences both computation and memory) and store this in the KDF Iterations (although ideally a user could configure the other parameters too). For other KDFs like argon2 this is definitely not enough anymore though, since memory and time hardness are set separately. So this would need changes to both the storage, and the communication between clients and server, to instead deliver something like a KDFOptions object instead of the current KDFIterations number. Should this change be done first?
About argon2: The wasm implementation that has been previously linked looks good to me but it has not been through an audit or fuzzed, so IDK how I feel about using that.
I have written a lot more about this topic: What We Do in the /etc/shadow – Cryptography with Passwords - Dhole Moments
The problem with KDFs in pure browser JS is that, it will become unacceptably slow for legitimate uses (but attackers still benefit from their optimized implementations). The ideal fix is to push for Argon2id support in crypto.subtle.
Scrypt’s N parameter was the only significant scaling factor in practice, but you could tune the (r, p) as well. It just wasn’t advantageous to do so.
For Argon2, libraries like libsodium accepted two integer arguments (memory, time). The second being the number of iterations, but it was always small in practice (2 for interactive logins, 4 for deriving sensitive keys).
You could probably just pick one reasonable value for the time cost and tune the memory cost (analogous to Scrypt’s N parameter, or PBKDF2’s iteration count).
Feature function
Reference to VeraCrypt, nested algorithms make cryptographic libraries more secure
Related topics + references
Hi,
I first send this to support at Bitwarden , but they advised to put it in the forum, so is just do that
Think a lot of you have seen the lastpass breach and the latest podcast on twit with Steven from GRC.COM and the current hashing method has aged.
Read the below text please.
I where a lastpass user till a week ago.
Had a “strong” master password iterations at 100100 but stepped over to Bitwarden , It was adviced by GRC.COM via twit on youtube.
I viewed a video just now and became aware of the GPU rig capabilities on the hashing algoritms, pbkdf2 has aged , and it wat adviced to leave that and go to argon2 or SCRIPT , because that would need a 60Mbyte data area in memory with randomly connected pointers and GPU’S can not to that , because it can not be threaded , so my request is to implement this in Bitwarden to make it GPU cracking safe.
It was also stated the passphrase is nice but a randomly generated 64 bit bytechunk is better , but no one can remember that , I am not a high profile person , changed the passwords of the most important sites that i have and the most important ones al have MFA , what’s the advice that Bitwarden can give in this earea? , To what length do i need to go to make a super super super safe masterpassword? and also be able to remember it , the password that i now have is challenging enough for me, but GRC said it’s better to do 64 byte fully random and store it somewhere and copy and paste it in to unlock the safe.
If you see the capabilites of bitcoin mining rigs and they are used to brute force the safe, then nothing is safe except for leaving the the hashing algoritm and use a modern one like the 2 mentioned.
I think Bitwarden are getting more of these requests , it was adviced to send a request like this to Bitwarden to upgrade the hasing method.
I think i am safe because all the important fields in the vault are encrypted with bitwarden unlke what Lastpass did.
Learned just now that for some old accounts the iterations in lastpass where set to 1, unbelievable , i set mine in Bitwarden to 1234567 iterations to stay ahead of the moving train called GPU hacking.
The bad actors are going for the accounts with iterations is 1 and the high profile persons first, I use it for convinience , all my passwords are generated and should be safe as long as the vault stays safe, i learned that lastpass is getting sued , because of the mallpractice and people who are getting victimed by this hack.
Regards,
Ronald.
1 Like
Understandable, is there any way to implement argon2 or “script” on supported platforms?
@RobertW I have already made a community pull request for scrypt. for all platforms. It just needs to be reviewed by the Bitwarden team (and possibly revised by me if anything is not ready yet). As for argon2: It is a bit more work compared to scrypt, since it is has to be run as a WASM module. I’ll do some testing on the weekend, and report back, but if someone else wants to look at it feel free.
4 Likes
About running as a pure js library, if you have any significant work time in WASM, then native JS is not feasable. It is about 300x slower. F.e comparing Argon2 in browser and https://argon2id.rabbit-company.com/ with 102400KiB memory, 2 iterations and 3 parallelism takes 408ms on WASM and ~145 seconds in js on my system.
Thank you! Great to know it’s at least getting explored. Hopefully that works out or something similar
Ok, actually it didn’t take until the weekend. Working with webassembly still was a pain but it ended up working:
Argon2 using the WASM module in the browser and desktop, and the native bindings in the CLI. Web extensions are yet untested, they will probably not work at all for now.
Still, this needs quite a lot more work to be in a pull-request ready state. Anyways, here is the link:
7 Likes
Adding my voice here: Bitwarden please implement Argon2 or Scrypt
3 Likes
Great to read this, it will make Bitwarden security a lot stronger and wll get more trust form the audience as well.
3 Likes
Ok, basic implementations for all platforms is working now. I have created a separate thread about argon2 support here:
9 Likes
The Firefox extension Store is still not upgraded to 2023.2.0