Hi, I have three questions.
I've changed my forum to use bcrypt but I'm concerned about potential denial of service attacks with the extra strain bcrypt adds. After 5 failed logins, a captcha is displayed. I know that if the captcha is incorrect you won't be able to login regardless of if the password is correct. If the captcha isn't correct, is the password still processed and compared to the one on the database, causing unneeded stress? .
This brings me to another issue. Locking people out after x amount of failed login attempts. It's set with a cookie, and removing it allows you to proceed as normal. A script could bypass the lockout by removing the cookie after x tries couldn't it? How could the lockout be enforced server-side, maybe blocking the IP for x amount of time? What edits would be needed to make this change?
Finally, if a captcha (Google noCAPTCHA) is always present, how effective would that be at preventing a brute-force?
Thank you for reading. I'm new to running a user based website and I want to make sure everything is secured properly. Also, forgive me if my terms are incorrect.
I'm not so new.
1) You're overreacting. A DDoS doesn't occur through a user trying to log into a site.
2) You can bet your bottom dollar nobody cares enough about you to try to hack into your account.
In summary:
Quote:I've changed my forum to use bcrypt but I'm concerned about potential denial of service attacks with the extra strain bcrypt adds. After 5 failed logins, a captcha is displayed. I know that if the captcha is incorrect you won't be able to login regardless of if the password is correct. If the captcha isn't correct, is the password still processed and compared to the one on the database, causing unneeded stress? .
No. Denial of Service attacks, in my experience are thousands of requests to a page. No form filling out, nothing just loading the page.
Quote:This brings me to another issue. Locking people out after x amount of failed login attempts. It's set with a cookie, and removing it allows you to proceed as normal. A script could bypass the lockout by removing the cookie after x tries couldn't it? How could the lockout be enforced server-side, maybe blocking the IP for x amount of time? What edits would be needed to make this change?
Bots don't delete cookies.
Quote:Finally, if a captcha (Google noCAPTCHA) is always present, how effective would that be at preventing a brute-force?
Well, you can brute-force any rationally solvable problem. That doesn't mean people *will*.
Yes, I know, but bcrypt is adding more stress on the server every time someone logs in or attempts to log in, significantly more than MD5.
Since the lockout is enforced client-side, it's fairly safe to say there
is a way for it to be bypassed. I haven't tested what happens if you have cookies disabled.
This probably explains it better than I can:
http://security.stackexchange.com/questi...-functions
(2016-08-16, 08:24 AM)James0206 Wrote: [ -> ]Yes, I know, but bcrypt is adding more stress on the server every time someone logs in or attempts to log in, significantly more than MD5.
Since the lockout is enforced client-side, it's fairly safe to say there is a way for it to be bypassed. I haven't tested what happens if you have cookies disabled.
You need to remember that MD5 is from an era where Pentium 4s were used as servers. On a direct comparison, not so much.
A few things:
- MyBB 1.x doesn't support bcrypt, so when you upgrade to 2.0 you might encounter problems. Just something to be aware of.
- The captcha is, I believe, checked before any hashing is done.
- If there's a captcha for every login request it would make bruteforcing extremely difficult, to the point where it wouldn't be worth the effort. Setting the login to email only would be a viable option too.
Quote:No. Denial of Service attacks, in my experience are thousands of requests to a page. No form filling out, nothing just loading the page.
Thousands of POST requests which perform CPU intensive tasks (e.g. password hashing) would be a more effective DoS than thousands of GET requests which perform a few database queries. Even a single request can cause a DoS, depending on the code behind the page.
Quote:Bots don't delete cookies.
Bots can choose which cookies to use. By simply not sending the cookie with the amount of failed attempts, a bot (or human) can bypass it. This is a poor design decision and will likely be improved in 2.0.
Quote:- MyBB 1.x doesn't support bcrypt, so when you upgrade to 2.0 you might encounter problems. Just something to be aware of.
I will personally see to this being handled gracefully, seeing as I'm hoping to advertise an improved version of Tomm's bcrypt hashing plugin soon with a couple of other password-related improvements. People shouldn't be waiting for 2.0 for the hashing improvements if they have a host that supports bcrypt (PHP >5.3.8 min; PHP 5.5 for the language's password hashing API). Seeing as there isn't a hardcoded key/salt used for bcrypt at all, I can't see how this would be all that difficult for us to accommodate.
Quote:Thousands of POST requests which perform CPU intensive tasks (e.g. password hashing) would be a more effective DoS than thousands of GET requests which perform a few database queries. Even a single request can cause a DoS, depending on the code behind the page.
Exactly, and if that happens, then you start log monitoring and rate limiting (and adding iptables rules if you control your server) to drop the requests. Overall, the benefits to hashing passwords in a modern way outweigh this potential threat, which can be mitigated if it arises, IMHO.
Quote:This is a poor design decision and will likely be improved in 2.0.
That's an understatement.
Great points, thanks!
Was curious how that would effect the 2.0 upgrade. I would be more than happy to pay someone (or a donation to mybb) for a fix should any issues arise during the 2.0 upgrade.
That's great to know, I tried to check but I didnt see anything.
I suspected so, glad someone experienced could confirm it. I will definitely consider email only when logging in.
@Josh H
Thank you so much Josh, that's really reassuring to read.
I agree that the benefits outweigh the potential threat. I'll have to keep a watch to see if this is abused and will act accordingly.
Glad to hear that lockout will be improved in 2.0
I'm typing on mobile so forgive my short replies.
Yeah, just make sure you set an appropriate cost that takes only about 0.05 (min) - 0.1 (max) seconds or so to process, and you should be alright. That should allow for a good level of security and a decent number of concurrent login attempts.