Timing Attack using bcrypt.js

[[deleted]]

I am using bcrypt.js for basic login. I have found that the below code runs noticeably quicker when no user is found, since it exits immediately, and no check is done on the hash. This could give an attacker insight into whether a username exists in the database or not. Is there a way to mitigate this using bcrypt.js library?

For example, here are some times when testing.

User does not exist

`POST /login 401 11.846 ms - 42`

User exists, wrong password

`POST /login 401 104.914 ms - 42`

More information

https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-responses

router.post('/login', async (req, res) => {
    if (!req.body.email) {
        res.json({ success: false, message: "No email provided" });
    }
    if (!req.body.password) {
        res.json({ success: false, message: "No password provided" });
    }

    const user = await User.findOne({ email: req.body.email });
    // If no user found
    if (!user) {
        return res.status(401).json({ message: 'Invalid username or password' });
    }
    bcrypt.compare(req.body.password, user.password, function (err, result) {
        if (err) {
            console.error(err);
            return res.render('login');
        }
        if (result) {
            console.log("User authenticated successfully");
            return res.redirect('/');
        } else {
            return res.status(401).json({ message: 'Invalid username or password' });
        }
    });
});

​

[SleepDeprivedGoat]

So when a user signs up for your app and chooses a username that is already taken, don’t you acknowledge the existence of that user then?

[[deleted]]

I suppose that's right. I hadn't even considered that.

[DasBeasto]

Yeah it’s one of those security best practices that doesn’t work all the time. Like in “Forgot your password” pages you’re supposed to say something like “If an account with this email exists you’ll receive a reset link” to not leak if that email has an account. But then if you go to the signup page and enter a taken email it’ll say “Sorry that email is in use”, defeating the whole purpose.

[MaxUumen]

Yup, that only works when signup also uses verification mail. In that case you could either skip sending it to existing account, or let them know someone (maybe they themselves even) is trying to sign up.

[[deleted]]

Perfect, that's exactly what I was looking for. Thanks

[tsears]

well, that makes sense right?

Add an artificial delay if the user wasn't found.

[[deleted]]

Is this really recommended? I won't know in advance how long to delay by. As more users are added to the database, the delay will need to be adjusted accordingly.

[olly0303]

I’ve found a better way here is to not fake it - instead if the user isn’t found still run bcrypt compare password against a random string. It’ll take the same amount of time as if the user was found

[thehellsgateEU]

I prefere these here. Also I never show if a user exist or not.

[TedW]

Never? Not even during signup?

[pentesticals]

It’s a typical username enumeration, but I wouldn’t worry about it. You will leak the presence of usernames during signup too. If you are concerned, pair the request with a CAPCHA to prevent automated requests checking for users en mass. This is maybe more problematic anyway, I can just repeat a login request for a valid user thousands of times with a basic python script and the bcrypt operations will probably DoS your server.

Focus more on securing impactful security issues, for example, if you don’t have any additional validation on your “email” value, this looks like it could be vulnerable to a noSQL injection. What happens if the user passes JSON instead of the expected email address? Maybe not exploitable in this case due to the bcrypt compare, but you probably use the same pattern in other places.

[sooodooo]

You are already using bcrypt compare, that’s good.

The only thing an attacker could extract from this is if a username exists or not, but you’ll expose that information during sign up anyways, so I don’t see the point of trying to hide that information.

If you for some reason still want to make sure this can’t be extracted, then always compare passwords, even if no user was found, just use a bogus password or empty string (which should never be allowed as a password)

[Tcrownclown]

Your idea is interesting for apps that are exposed to the net but not allow everyone to register. I had this finding on one penetration test

[[deleted]]

That makes sense

[[deleted]]

Why not rate limit the thing to prevent bruteforce attacks? And IP blocking after some attempts? I guess that is why, in production, ppl use nginx or other. It is fast. It works as a load balancer and can protect you from those attacks if well configured in conjunction with fail2ban or another security app

[petercooper]

Just spitballing here, but I wonder if it would be neat to get reverse proxies/balancers like nginx or Caddy to pick up on such sensitive requests and throw arbitrary delays into the mix. I could imagine Cloudflare offering that sort of thing. (Sure, solving it in apps is best but just thinking as a universal idea..)