Bun.password.verify does not work with bCrypt | Bun | Page 1

compact zinc Feb 19, 2024, 8:11 AM

#

console.log(data.password);
const hash = await Bun.password.hash(data.password, {
  algorithm: 'bcrypt',
  cost: 10
});
console.log(hash);
console.log(await Bun.password.verify(data.password, hash, 'bcrypt'));

#

#

it works with Argon2id, but not with bcrypt

#

Running Bun 1.0.27 on latest MacOS

regal stone Feb 19, 2024, 8:34 AM

#

bun is supposed to automatically detect the hash type from the content, so passing in "bcrypt" as the third argument does nothing

#

I'll see if I can reproduce on windows and linux tomorrow

compact zinc Feb 19, 2024, 9:04 AM

#

regal stone bun is supposed to automatically detect the hash type from the content, so passi...

tried without passing bcrypt parameter and didn't work either

#

that's why I tried passing it and it still doesn't work

compact zinc Feb 19, 2024, 9:05 AM

#

regal stone I'll see if I can reproduce on windows and linux tomorrow

Thanks

regal stone Feb 19, 2024, 7:12 PM

#

$ bun run bcrypt_hash.ts
Enter Password: some password
Read: some password
Hash: $2b$10$ut/yHDE/4j67EzTM8X7dc.Po3/V05M4zf2latauaLaU8MiGxsWH6y
Verify result: true

$ cat bcrypt_hash.ts
const pass = prompt("Enter Password:");
console.log(`Read: ${pass}`);

const hash = Bun.password.hashSync(pass, { algorithm: 'bcrypt', cost: 10 });
console.log(`Hash: ${hash}`);

console.log(`Verify result: ${Bun.password.verifySync(pass, hash)}`);

A similar program seems to work fine on linux

#

I'll try the async version of the hash functions

#

$ bun run bcrypt_hash_async.ts
Enter Password: another password
Read: another password
Hash: $2b$10$Y8upaJsW6S0NZCAfzlTqq.jFZUYdqrzcVmUCPlzZLGebzdX37WuNO
Verify result: true

Still failed to reproduce on linux

#

Interesting results on windows

$ bun run bcrypt_hash.ts 
Enter Password: some password
Read: some password
Testing Sync
Hash: $2b$10$e7GoVjhSR6NchzXOswVJFuM2KBKYBXHjUhXVRUzucyroHckirEqbu
Verify result: true
Testing Async
Hash: $2b$10$t4X4HomGuokucmkdlE/Ire.vmq2xLqtlFxenz.QarU5CyQHU4K4by
Verify result: true
Hash from sync and async were equal: false

#

const pass = prompt("Enter Password:");
console.log(`Read: ${pass}`);

console.log(`Testing Sync`);

const hash = Bun.password.hashSync(pass, { algorithm: 'bcrypt', cost: 10 });
console.log(`Hash: ${hash}`);

console.log(`Verify result: ${Bun.password.verifySync(pass, hash)}`);

console.log(`Testing Async`);

const hash2 = await Bun.password.hash(pass, { algorithm: 'bcrypt', cost: 10 });
console.log(`Hash: ${hash2}`);

console.log(`Verify result: ${await Bun.password.verify(pass, hash2)}`);

console.log(`Hash from sync and async were equal: ${hash == hash2}`);

#

The hashes from sync and async were different, but both verified correctly

#

it seems that bun's password hashing automatically adds a salt value - this difference in hash when run multiple times also happens on linux

#

that doesn't explain why verify returned false in your case though

night parrot Feb 19, 2024, 11:22 PM

#

it seems to fail for passwords longer than 72 characters

regal stone Feb 19, 2024, 11:24 PM

#

yep managed to reproduce that on windows

#

~~71 is fine, 72 is not~~

night parrot Feb 19, 2024, 11:24 PM

#

but that bug should be pretty easy to fix

#

hmm, 72 is fine here, but 73 is not.

#

(Linux)

#

maybe prompt is returning \r but dropping the \n?

regal stone Feb 19, 2024, 11:38 PM

#

oh yeah it might

#

printing .length does say there's an extra character

#

so yeah 72 is fine, 73 is not

night parrot Feb 19, 2024, 11:41 PM

#

that matches the code, which does an sha512 if password.length > 72

regal stone Feb 19, 2024, 11:42 PM

#

interesting

#

so is verify going down a different code path than hash

night parrot Feb 19, 2024, 11:42 PM

#

yep, I've fixed it locally and will open a PR

regal stone Feb 19, 2024, 11:43 PM

#

👍

night parrot Feb 19, 2024, 11:58 PM

#

test("bcrypt longer than 72 characters is the SHA-512", async () => {
const boop = Buffer.from("hey".repeat(100));
const hashed = await password.hash(boop, "bcrypt");
expect(await password.verify(Bun.SHA512.hash(boop), hashed, "bcrypt")).toBeTrue();
});

#

that doesn't make much sense to me

compact zinc Feb 20, 2024, 6:51 AM

#

so it seems you guys were able to reproduce the problem?

night parrot Feb 20, 2024, 7:01 AM

#

were you using passwords longer than 72 characters?

#

er, bytes.

regal stone Feb 20, 2024, 7:03 AM

#

it looks like it

#

it's the second line in the screenshot

night parrot Feb 20, 2024, 7:04 AM

#

oh, sorry, missed that

subtle kestrel Feb 20, 2024, 7:05 AM

#

Bcrypt supposedly has a 72 char length limit so passwords beyond that size are sha256d so they are 64 chars

night parrot Feb 20, 2024, 7:05 AM

#

https://github.com/oven-sh/bun/pull/9010

GitHub

fix: modify bcrypt to be able to verify passwords directly by argos...

Fixes #9009
What does this PR do?
Make the "bcrypt" algorithm (actually a variation of it) easier to use by using analogous code paths for hashing and verification.
This would break compa...

#

sha512 (and used as raw input), but yeah 🙂

subtle kestrel Feb 20, 2024, 7:07 AM

#

Oh you figured it out nice

night parrot Feb 20, 2024, 7:11 AM

#

yeah, just not sure whether it's already too late to break compatibility 😕

regal stone Feb 20, 2024, 7:14 AM

#

I think it makes sense to have verify be able to verify hashed passwords

night parrot Feb 20, 2024, 7:24 AM

#

I think it's certainly too much to expect of the user to count bytes (not characters), compare to 72, and use a different function in that case, but if people are already doing it...

subtle kestrel Feb 20, 2024, 7:47 AM

#

It would probably have been reported by then

compact zinc Feb 20, 2024, 4:55 PM

#

night parrot were you using passwords longer than 72 characters?

Yeah Blake2b generated hash

#

So should I just use Argon2id?

#

But this should probably be fixed at least for verify

night parrot Feb 21, 2024, 7:35 PM

#

I need to figure out how to print a deprecation warning for "bcrypt" when no strategy is specified for passwords > 72 bytes, that seems best to me.

compact zinc Feb 22, 2024, 6:23 AM

#

the one that uses bcrypt for Bun.password.hash and Bun.password.verify, with passwords longer than 72 bytes wouldn't work for them either, so I'm not sure if deprecation warning is even needed here

#

Just a fix

#

or will hashes also be different for passwords smaller than 72 bytes and verify wouldn't work anymore for them after the fix?

night parrot Feb 22, 2024, 7:02 AM

#

can you try now? the simple fix as you describe it was merged

compact zinc Feb 23, 2024, 3:05 PM

#

Will check thanks

#

Personally I prefer Argon2id over bcrypt as well, but for self-hosters, it would be a lot easier to choose the cost for bcrypt as it only includes one parameter that needs to be changed

#

and if you increase it, it would take longer to hash

#

so you can as well make a simple function that loops thru cost and use the one that needs at least 350ms to hash as an example

#

so the "best" cost would be used automatically depending on the server performance

#

with Argon2id there is just too much parameters

#

and it would confuse everyone

#

also parallelism is not supported in Argon2id?

#

or hash length

#

for front-end, I have compiled a WASM file from Argon2id Rust implementation and use WebWorkers for parallelism. https://argon2id.rabbit-company.com/

#

but on back-end with Bun I can't increase parallelism or change hash length

night parrot Feb 23, 2024, 3:28 PM

#

doesn't argon2id Just Work with the default configuration?

compact zinc Feb 23, 2024, 3:29 PM

#

for example if I want to generate hash on FE and BE

night parrot Feb 23, 2024, 3:29 PM

#

(why is the back end hashing passwords at all?)

compact zinc Feb 23, 2024, 3:29 PM

#

and verify on both sides

night parrot Feb 23, 2024, 3:29 PM

#

oh, verify 🙂

compact zinc Feb 23, 2024, 3:29 PM

#

yeah

#

this could also reduce server side load and make client suffer with hashing

#

client resources are free anyways

#

also by hashing on FE and sending hashed password on BE, this would prevent server ever knowing user password in plain text

#

as most users use 1 password for everything

night parrot Feb 23, 2024, 3:34 PM

#

as I said, crypto is subtle and it's easy to get wrong. I'm not sure what I think about the whole idea of expensive password hashes

compact zinc Feb 23, 2024, 3:35 PM

#

what do you usually use to hash user passwords?

night parrot Feb 23, 2024, 3:36 PM

#

IMHO it's probably better to use deliberately cheap hashes, then run a large dictionary against all substrings of the password to find out whether it's weak

#

I've not had to make that decision for a live site in ages. I honestly would excuse myself to do more research to see whether my ideas still make sense 🙂

compact zinc Feb 23, 2024, 3:37 PM

#

both bcrypt as well as argon2id includes salt, so this would prevent dictionary attacks.

night parrot Feb 23, 2024, 3:37 PM

#

well, it makes dictionary attacks more expensive, yes.

compact zinc Feb 23, 2024, 3:38 PM

#

yeah they would need to hash every try again

night parrot Feb 23, 2024, 3:38 PM

#

argon is what I use for disk encryption passwords, but that's a different scenario since any attacker can get an encrypted disk image.

compact zinc Feb 23, 2024, 3:39 PM

#

I have actually never used Argon2id for server-side password hashing. Only bcrypt.

#

but I'm using Argon2id for a password manager

night parrot Feb 23, 2024, 3:40 PM

#

I also think it would make sense to automatically try typo-fixing passwords that don't match, as it's a lot easier to type a seventy-character password with one or two typos than to type a 30-character password correctly consistently...

compact zinc Feb 23, 2024, 3:41 PM

#

I usually just make a requirement for password entropy to score at least 75. https://passwordentropy.rabbit-company.com

#

I'm not checking if their password is already located in any password dictionary...

#

so basically as long as their password is brute-force "resistant" it is good.

night parrot Feb 23, 2024, 3:43 PM

#

my current impression is expensive hashing only helps with medium-strength passwords. weak passwords are weak, strong passwords are strong even with cheap hashing

compact zinc Feb 23, 2024, 3:45 PM

#

so are you using something like sha256, sha512... for cheap password hashing?

#

or even cheaper algo

night parrot Feb 23, 2024, 3:46 PM

#

nothing cheaper than sha512 🙂

compact zinc Feb 23, 2024, 3:46 PM

#

cool

night parrot Feb 23, 2024, 3:46 PM

#

I think at this point I have a Pavlovian reaction to even typing the characters "m", "d", "5"

compact zinc Feb 23, 2024, 3:47 PM

#

I usually use sha512 for bearer tokens

night parrot Feb 23, 2024, 3:48 PM

#

anyway, if your default settings for argon2id aren't good or can't be changed as easily as they should be, please file an issue! It's important not to fall behind the security users are expecting, even if they're wrong to do so 😉

compact zinc Feb 23, 2024, 3:49 PM

#

not long time ago, I have been migrating a PHP website from version 5 to 8. The company did used md5 for password hashing Laughing_Facepalm

compact zinc Feb 23, 2024, 3:49 PM

#

night parrot anyway, if your default settings for argon2id aren't good or can't be changed as...

thanks will do

night parrot Feb 23, 2024, 3:52 PM

#

soon it'll all be replaced by passkeys, whether we want that or not.

compact zinc Feb 23, 2024, 3:59 PM

#

It would probably take another decade or more

#

as it is a lot faster for each programmer to implement passwords than passkeys

#

This is the best way in my opinion:

Something only you know (passwords)
Something only you have (Yubikey, fingerprint, mobile phone?...)

#

With passkeys people want to switch from (Something only you know - passwords) to (Something only you have - passkeys)

#Bun.password.verify does not work with bCrypt