SNsneak·Mar 19, 2023
Someone should tell them!
https://github.com/bitwarden/jslib/issues/52
In Bitwarden PINs can be brute-forcedbitwarden
jslib
TypeScript2018–2023
bitwarden / jslib · Archived
jslib
Common code referenced across Bitwarden JavaScript projects.
10Distinct people
14Mentions
0Explicit recommenders
136GitHub stars
What to know before exploring
What it is
Common code referenced across Bitwarden JavaScript projects.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bitwarden/server · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year14 dated mentions
Observed mentions: 2018-11-12 16:52:26 UTC to 2023-03-19 16:31:08 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
14 sourcesSHA256 is a terrible choice for a PBKDF in 2019
1 points · Open discussionConsidering how important security is in a password manager, I don't trust any other than Bitwarden.
It's been audited [0] by external companies multiple times and both the client and the server are fully open source [1].
I know others may say that the encryption is too weak[2], but that's true for all other password managers too [3], since Argon2id is not mature enough to run as a WASM module in the browser yet (especially not on mobile).
[0] https://bitwarden.com/help/article/is-bitwarden-audited/
[1] https://github.com/bitwarden
[2] https://github.com/bitwarden/jslib/issues/52
[3] https://github.com/bitwarden/jslib/issues/52#issuecomment-78...
In Ask HN: What password managers can you recommend?If I'm not mistaken it should be mostly fine as long as you trust the desktop/phone versions of Bitwarden not to send off the (unhashed) key to the server
Edit: Noting that there have been discussions about the default number of iterations.
https://github.com/bitwarden/jslib/issues/52
In Bitwarden_rs: Unofficial Bitwarden compatible server written in RustBy replacing the client code with code that exfiltrates the password the next time you enter it.
Alternately, brute forcing the client password is straightforward due to their use of a too-fast KDF and low iteration count.
https://github.com/bitwarden/jslib/issues/52
https://github.com/bitwarden/server/issues/589
In LastPass Android app has got 7 trackers in itWhy we are still using PBKDF2-SHA256 despite being aware of its limitations
85 points · Open discussionIt wasn't in the scope of this audit, but it's still somewhat concerning... PBKDF2 with SHA-256 (a super fast hash with hardware support) as a key derivation function (which should be slow and difficult and hard to do in hardware)? That doesn't sound right. The answer provided (cross platform compatibility) doesn't sound satisfying.
Was this discussed with the prior audit?
EDIT to add: Here's the 2018 "cryptographically right answer" on password hashing ( https://latacora.singles/2018/04/03/cryptographic-right-answ... ):
Password handling
Percival, 2009: scrypt or PBKDF2.
Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2.
Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2.
You care about this if: you accept passwords from use
Read the rest
rs or, anywhere in your system, have human-intelligible secret keys.
But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, which is much better than PBKDF2. In practice, it mostly matters that you use a real secure password hash, and not as much which one you use.
Don’t build elaborate password-hash-agility schemes.
Avoid: SHA-3, naked SHA-2, SHA-1, MD5.
EDIT to UPDATE:
Bitwarden has commented (about an hour ago) that they'll fix this! Cool.
https://community.bitwarden.com/t/switch-to-argon2/350/23
https://github.com/bitwarden/jslib/issues/52
https://github.com/bitwarden/jslib/issues/52
I am astounded to see this missing from the report. Apparently the report was just their external API configuration or something?
In Bitwarden second security audit reportBitwarden derives its keys using SHA256 on the passphrase and a hilariously low iteration count.
The developer refuses to acknowledge it as a security risk, and actually caps the max iterations you can configure, both on the client and the server.
https://github.com/bitwarden/jslib/issues/52
https://github.com/bitwarden/server/issues/589
“It was audited” is meaningless if the audit missed this, or reported this and the dev dismissed it. Either way, it is unsafe.
In A Dropbox account gave me stomach ulcersI'm also using bitwarden, but palent seemed skeptical about it in the comments. Here's a copy of the comment:
Reply from Wladimir Palant:
Unfortunately, I didn’t make notes last time I looked into this – the issues simply weren’t serious enough for reporting. And I only looked at a small portion of the codebase, so when I look at it now it will probably be some different code paths. So the getDomain() function I see under https://github.com/bitwarden/jslib/blob/dd46d5ecdd51f91dace5... is indeed using URL objects. It also knows that tld.js won’t handle IP addresses correctly, but it will only consider IPv4 addresses in dotted decimal notation and not IPv4 addresses in other notations or IPv6 addresses. All of that appears to be a minor risk but not an actual issue – assuming that URLs are already normalized when they get here (ok, let’s ig
Read the rest
nore the code prefixing URLs with http:// here).
The code at the bottom of this function is quite problematic however. Rather than ignoring non-HTTP URLs, this function will pass them to tld.js. But tld.js isn’t aware that non-HTTP URLs can have different semantics, so it will happily return “example.com” when it is fed something like “data://example.com,asdf/”. Oops, I think that one might even be exploitable…
I think I’m going to stop here. This needs a structured effort, not spending ten minutes every now and then. As I said, the codebase isn’t bad. But there are obvious issues that shouldn’t have been there. As always, spotting the issues is the easy part – proving that they are exploitable is far harder. I’m not going to spend time on that right now, so let’s just file these under “minor quality issues” rather than “security problems.”
It does do this [1], however, it is a little more complex since Bitwarden has to backwards-compat support old data that was AES-CBC encrypted from long ago before auth checks were implemented, while also combating against downgrade attacks. This same discussion was had back in January when you (I assume this is PIE Scott) reported the problem in issue 306171 on HackerOne which was closed out.
[1]: https://github.com/bitwarden/jslib/blob/master/src/services/...
In Bitwarden Completes Third-Party Security AuditThey recently added that:
"Oct 9 - This is in the next release for various apps." [1] the PR is from Oct 6 [2].
It is a very basic implementation as of now. The wordlist is English-only, and it doesn't have a minimum character account so it contains 'words' such as 'aa' and 'aaa'.
[1] https://community.bitwarden.com/t/add-an-ability-to-generate...
[2] https://github.com/bitwarden/jslib/pull/12
In Bitwarden Completes Third-Party Security AuditYes, it's using RSA to encrypt a key, as one would hope. https://github.com/bitwarden/jslib/blob/b4fad203b94da53d3369...
Usually when I see RSA-OAEP in a casual stroll through something's code, I stop there and move onto looking for other issues.
Reason: Very few users of RSA encryption bother to use a secure padding mode. If they're doing that much, the chances of doing something very stupid (a.k.a. "RSA-ECB") is low enough to discount for the purposes of message board discussions.
(Obviously, if I'm being paid to review something, I spend a lot more time on it.)
When I wrote my post above, all I cared about was the modes being used. That's why I vaguely said "some data".
A further analysis (i.e. where rsaEncrypt() is invoked) yields: They're only using RSA for encrypting AES keys, which is a sane design.
Hopefully my lazy word choice di
Read the rest
dn't cause you (or anyone else) any undue alarm.
> Wondering how they will address the current cryptographic scheme though.
The only cryptographic weakness Cure53 identified was that a malicious API server could exfiltrate encryption keys.
Cure53 deemed it a hard problem to solve. I wrote a proposed strategy for mitigating it: https://github.com/bitwarden/core/issues/392
Regarding Bitwarden's cryptographic security, a cursory read through their code yields the following:
* It's using RSA-OAEP to encrypt AES keys (EDIT: formerly "some data") https://github.com/bitwarden/jslib/blob/b4fad203b94da53d3369...
* It's using AES-256-CBC https://github.com/bitwarden/jslib/blob/b4fad203b94da53d3369... + https://github.com/bitwarden/jslib/blob/b4fad203b94da53d3369... + https://github.com/bitwarden/jslib/blob/2045e7047a66599b2c8a...
It doesn't appear to be authenticating the AES-CBC-encrypted cipher
Read the rest
texts in all cases, which makes me suspect padding oracles are still in-scope.
https://robertheaton.com/2013/07/29/padding-oracle-attack/
RSA-OAEP is the better RSA mode. (You don't want PKCS1v1.5)
In closing: As long as you're not for some reason storing unauthenticated AES-CBC ciphertexts in the server, the encryption is really boring.
(Boring is good for encryption.)