What algorhythm is used for encrypting user passwords?

julian

@PitaJ is correct, bcrypt_rounds can be set anywhere that nconf reads configs from, so mainly config.json but also via env var, or passed into the nodebb executable as an argument.

But it's optional, so it usually just falls back to the default of 12 rounds. As computation power increases, we increase this number to compensate. A login attempt should block for some noticible amount of time (perhaps a second or two).

@pyc4 said:

Well I don't exactly need to know the depths of such algorithms,

Correct, and neither do we. We implicitly trust in the security of the bcrypt library because rolling our own crypto is almost always a bad idea

That said the sha-wrapping is outside of the bcrypt lib, so I honestly couldn't say whether there are bugs in that implementation.

pyc4

@julian @Pitaj @gotwf

Thanks for your replies, it was useful and I'm making some progress here. Please stay with me a bit more so I can finish this, help's appreciated here very much

Right now I'm struggling with SHA512 hashing, here's the code that I took from password.js to do hashing:

    passwordSHA512 = crypto.createHash('sha512').update(passwordSHA512).digest('hex');
    console.log(passwordSHA512);    // 4ffcc3cce9a56025aa0126c2fe7ec247e8a6e5ee6fdd5e854bb3761b66e5c5c4909189ad054e44a473cc29fd461fccf1965aebe5b17dfbaac9b994112c5a33a3
    const salt = bcrypt.genSaltSync(12);
    const hash = bcrypt.hashSync(passwordSHA512, salt);
    console.log(salt); // $2a$12$ZDFzbDOVrZSZ.L.RFWQiqe
    console.log(hash); // $2a$12$ZDFzbDOVrZSZ.L.RFWQiqej/ed5M6b/C06Hz/mRCuOd1fMVpzVF/.

So it's used in completely the same way as in password.js, but what I finally get is some other hash string, which is not the same as hash string generated by NodeBB which is saved in its database.

As I've previously said, the length of hash I get after SHA512 is applied looks suspicious to me, and it's 128 chars long hex value which I don't know how it's supposed to be supplied to bcrypt because of 72 chars limit. Probably that HEX value is somehow converted to shorter string? But if it's somehow automatic, it's supposed to work, but what I get is completely some other value than I need to get.

PitaJ

@pyc4 if you have older user passwords, it's likely those were hashed without the sha step

pyc4

@PitaJ I'm playing with NodeBB from version 1.19.1, so I guess it was always that SHA512 was enabled? ... I imported users through Write API, and within every user stored object I have password:shaWrapped property set to 1.

julian

@pyc4 if the salt is different between NodeBB and your app, the resulting hash will of course be different.

The salt is randomly generated for each password, so it can't be shared.

But the salt itself is prepended to the hash, so the real test is whether running .compare() on your app shows that the password matches.

pyc4

@julian

OK, just let me be clear on the step really I'm not fully sure it's ok?

user-entered password is put through
crypto.createHash('sha512').update(password).digest('hex');
then I use that as the first argument for bcrypt.compare() function, and the second argument is password fetched from NodeBB database, and if true is returned entered password is matched against stored password.

Still I don't understand how is it possible to compare if I don't have original salt, but if it could work like how I described it, it's good enough for me.

pyc4

I just tried what I described and it's not working

pyc4

I'm definitely stuck, anybody care to provide professional help? I'm willing to pay to overcome this hurdle.

PitaJ

@pyc4 share your code please

pyc4

@PitaJ

    passwordSHA512 = "b33bcf64f2744712deb66354b1d6a6d0";
    passwordSHA512 = crypto.createHash('sha512').update(passwordSHA512).digest('hex');
    console.log(passwordSHA512); // 455800380a39d8c49b976eb4bc31b98710ceb5beecd88c823c50ca2bdfd7cf1a581d92d9f64df5cfb2f9e50dfc3b2240e119b5ceffc99e584b310838f999aebc
    const match = bcrypt.compareSync(passwordSHA512, "$2a$12$56c7LRlpF9Mt47eeXDBgBuIBsuf3NPU4hAFzQRyxM7pZWMwhz3EOG");
    console.log(match); // false

match should be true, not false.

PitaJ

@pyc4 and you got the password hash+salt directly from the database?

pyc4

@PitaJ No, just got hash, not a salt. How can I get the salt if salt is always random?... Probably I do missing something here...

<baris>

I tested this and Im getting the expected result.

router.get('/test', async (req, res) => {
	const crypto = require('crypto');
	const bcrypt = require('bcryptjs');

	const rounds = 12;
	const mypassword = '123456';
	const shaPassword = crypto.createHash('sha512').update(mypassword).digest('hex');
	const salt = await bcrypt.genSalt(parseInt(rounds, 10));
	const hashedPassword = await bcrypt.hash(shaPassword, salt);
	console.log('hashedPassword', hashedPassword);

	// testing
	const mypasswordtry = '123456'; 
	const shaPasswordtry = crypto.createHash('sha512').update(mypasswordtry).digest('hex');

	res.json({
		'should be true': bcrypt.compareSync(shaPasswordtry, hashedPassword),
		'should be false': bcrypt.compareSync('asdasdasa', hashedPassword),
	});
});

Prints out

{
    "should be true": true,
    "should be false": false
}

PitaJ

@pyc4 salt is included in the password hash and stored in the same string in the database, which is why compare is passed only two things.

pyc4

It worked out with this code:

const shaPassword = crypto.createHash('sha512').update(password).digest('hex');
console.log("true or false: ");
console.log(await bcrypt.compare(shaPassword, "$2a$12$56c7LRlpF9Mt47eeXDBgBuIBsuf3NPU4hAFzQRyxM7pZWMwhz3EOG"));

Compare's second argument is fetched from database and that's it... Honestly I don't really know how it complicated this much for me, there's something that I did wrong, now it's ok. Thanks a lot!

pyc4

@Pitaj @baris Just to be completely clear, bcrypt.compare is this the only possible way for checking password?

I was thinking it is possible to generate hash from given password that is exactly the same as the hash written to database. Then I could just search the database for that hash , and if it exist that whatever user that has that password is logged in - I wouldn't have to find user first and load saved hash in database to supply to compare function.

Huh, I'm hope I'm being clear.

julian

@pyc4 said:

I was thinking it is possible to generate hash from given password that is exactly the same as the hash written to database.

Only if you use the same salt, but you don't have the salt, so therein lies the problem