Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passwords are stripped after an ASCII NUL character #774

Closed
fef1312 opened this issue Jan 13, 2020 · 2 comments
Closed

Passwords are stripped after an ASCII NUL character #774

fef1312 opened this issue Jan 13, 2020 · 2 comments

Comments

@fef1312
Copy link

@fef1312 fef1312 commented Jan 13, 2020

What went wrong?

When hashing a password containing an ASCII NUL character, that character acts as the string terminator. Any following characters are ignored.

What did you expect to happen?

Strings should be handled exactly like in JavaScript, where NUL characters can occur at any position without affecting their length. I realize this is kind of an odd case, but since this is a security-relevant module, it should always behave exactly the way it is supposed to.

Which version of nodejs and OS?

node v12.13.1 on Fedora 31 x86_64

If you find a bug, please write a failing test.

const bcrypt = require('bcrypt');
const assert = require('assert');

const actualPasswd = 'Passw\0rd123';
const badPasswd = 'Passw\0 you can literally write anything after the NUL character';

async function test() {
    const hash = await bcrypt.hash(actualPasswd, 12);

    const resultWithActualPasswd = await bcrypt.compare(actualPasswd, hash);
    const resultWithBadPasswd = await bcrypt.compare(badPasswd, hash);

    assert.strictEqual(resultWithActualPasswd, true, 'Should return true with the actual password');
    assert.strictEqual(resultWithBadPasswd, false, 'Should return false with a bad password');
}

test()
    .then(() => console.log('Test passed'))
    .catch(console.error);
@recrsn
Copy link
Collaborator

@recrsn recrsn commented Jan 13, 2020

Passwords with null characters should not be passed to bcrypt (or any crypt(3) compatible algorithm). Far too many bugs are due to libC using \0.

Popular python bcrypt implementations, Ruby bcrypt and PHP do not allow it. Some silently pass the \0 (PHP) and some, however, show an error. We probably should start doing that as well.

Loading

@techhead
Copy link
Contributor

@techhead techhead commented Jun 1, 2020

@sandtler @agathver Bcrypt already includes the final NUL termination character when calculating the hash. I believe that also Including those caught in the middle is a reasonable default that will help to prevent a possible class of errors. And it's a simple fix.

I have a pull request pending that also closes a long-standing vulnerability (re)discovered in #776 .

Loading

@recrsn recrsn closed this in #807 Jun 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants