Minimum password length - Too short?

[Makoto]

The minimum required length for passwords when processing a registration on IP.Board is currently 3 characters. Meaning a password such as "abc" is completely valid.

Wouldn't you say this is a little too short and insecure? What about raising the minimum to 5 characters?

This is a really minor suggestion, but I just happened to notice this and thought I make make a suggestion on raising it a couple characters. I don't think there's any justifiable reason anyone should ever be using a password 3 characters in length.

[Makoto]

Bumping with the suggestion of maybe allowing the administrator to define their own security standards for user passwords?

Along with defining the minimum password length, adding an option for administrators to require members use passwords with a combination of uppercase, lowercase, and numeric characters might be useful for some.

[skizzerz]

I wholeheartedly agree that minimum password length should be raised and/or be configurable. I also like the ability to configure requirements, as some corporate environments may have certain policies that need to be followed. However, I strongly urge that any such requirements be disabled by default. There is a relevant XKCD on the topic as well.

[texterted]

I asked for this ages ago as I think proper ACP password control should be included.

[skizzerz]

I also just noticed there is a maximum length of 32 characters. You should not be enforcing any maximum password lengths (since you're hashing it, which stores it in a fixed-length string in the database anyway), but if you do the maximum should be far higher than 32, like 256 characters (so very few users would legitimately want a password longer than that, but low enough still that hash collisions or issues with request size do not occur).

[joyboy2001]

I think this is a valid request. The coders should definately integrate this.

[bfarber]

Password hashing will be revisited with 4.0. :)

[Makoto]

On this subject, what about adding some basic password checks?

Don't let the user use their username for their password and allow the option to reject registrations using a list of common passwords, for example.

There is especially no reason any sane person in the world should ever, ever use their username as their password. There is seriously no sensible reason for that. It defeats the entire purpose of having a password. But it's allowed.

[bfarber]

On this subject, what about adding some basic password checks?

Don't let the user use their username for their password and allow the option to reject registrations using a list of common passwords, for example.

There is especially no reason any sane person in the world should ever, ever use their username as their password. There is seriously no sensible reason for that. It defeats the entire purpose of having a password. But it's allowed.

Very often I'm quickly testing something, perhaps registration, and I use test/test as username/password. I then delete the account right after.

[AndyF]

I too use a simple name / pass combo for localhost tests simply as there's no point having anything even vaguely complicated for those plus it means I can simply setup various test accounts without struggling to remember their passwords. ie tester / tester1 / admin / admin1 etc etc

I can see the value in adding a check for this though, perhaps a sensible compromise for this could be:

We could have some text appear on the registration form (as we do now for a mismatched pass) to warn against setting the same password as name or if its less than say 5 or 6 characters maybe ?

If it was set so you could not have the same name as pass I'd like a power setting to disable that though.

[Makoto]

Very often I'm quickly testing something, perhaps registration, and I use test/test as username/password. I then delete the account right after.

When you create accounts through the ACP, have it automatically bypass these checks.

But you're saying because being unable to use highly insecure passwords is an inconvenience for your non-public development board, it shouldn't be considered as a feature for live production sites? That doesn't really make sense at all. You likely do a lot of things on development boards that you should never do on a live production site.

You're essentially allowing some insensible user to register on your forum actually using the username and password "test", only to leave and never use the account again. Since this user appeared legitimate, any spam checks you made on him wouldn't flag him as a potential threat or anything of the sort. However, now don't we just open up the possibility for brute force scripts to come along and try and spam a common list of username/password combinations in an attempt to hijack accounts and use them for a malicious purposes?

Worse yet, what's stopping brute force scripts from simply pulling your active member list and attempting to actively brute force every member of your community nonstop now? Anything?

Accounts will eventually be temporarily locked out, but that doesn't really matter when you're going off a list of the top 100 used passwords off a list of thousands even tens or hundreds of thousands of members.

This potential headache could be easily avoided by simply telling your members, "No, you cannot use 'password' as your password. Please try again."

Instead we allow registrations using three lowercase letters with a login screen that seemingly does nothing but temporarily lock accounts (by default) when a set number of failed login attempts are made. Simply telling a brute forcing script to move on to the next member on the list and come back later.

Could there maybe at least be an option to display a captcha screen or something after the account is locked a set number of times? The next time the legitimate user tries to log in, they'll just be redirected to the login screen with an error explaining that someone has attempted to access their account too many times.

[Makoto]

I know this all probably sounds paranoid, and I probably came off a little too hostile in that last post, sorry if I seem rude.

But is there any protection to prevent a bot from scraping your member list and trying to dictionary attack all your users one by one?

[Michael]

Yes, account locking. And separate log in names.

[Makoto]

Yes, account locking. And separate log in names.

Right, I forgot about separate log in names, but assuming the user doesn't have one..

Say a bot scrapes a list of 1,000 members. He's using an attack attempting the 100 most commonly used passwords as of 2012.

He fails to successfully brute force account number 1 after 5 attempts. The account is now locked for 20 minutes. He moves on to account number 2, after 5 attempts, he fails. The account is now locked for 20 minutes. He moves on to account number 3... and this process can endlessly loop until all 1,000 accounts have been attempted 100 times. I'm not aware of there being anything to stop this. That's my point. The goal of the attack would be to hope to eventually come across members that use stupid passwords such as "password" or "test".

On another note, let's assume a member does not keep his account logged in on his computer. Let's say I don't like Wolfie.

I don't want to see him on here any more, and I have my own personal VPS that's up and running 24/7. I think I'll write up a script to brute force his account with random logins 24/7 just to keep his account endlessly locked. He won't be able to do anything until he manually e-mails an administrator and hopes the administrator receives his message and investigates the issue, likely banning my IP. I remember this actually being a popular skiddie trick with MSN back in the days. People actually did this to keep peoples accounts locked.

This can be partially mitigated by requiring a captcha input after an account has been locked out so many times.

[bfarber]

Brute force locking is tied to IP address for that very reason you posited in your last scenario (you don't like Wolfie so you lock his account - by tying the locking to IP address you can't do that ;) ).

Let me ask you this - are you facing some sort of issue now, or is this all theoretical? Are you having spammers brute force your member list, find someone with a weak password, and then use that account for something nefarious (seems like spam on your site is about the worst the user could do, unless your moderators/admins have weak passwords)? Or are you just thinking of a situation where this could be a potential issue?

[Makoto]

Brute force locking is tied to IP address for that very reason you posited in your last scenario (you don't like Wolfie so you lock his account - by tying the locking to IP address you can't do that ;) ).

Ah! And that I did not know. That's pretty crafty. Thanks for correcting me :tongue:

Let me ask you this - are you facing some sort of issue now, or is this all theoretical? Are you having spammers brute force your member list, find someone with a weak password, and then use that account for something nefarious (seems like spam on your site is about the worst the user could do, unless your moderators/admins have weak passwords)? Or are you just thinking of a situation where this could be a potential issue?

This is all just me thinking of situations where there could be potential issues. I'm not having any problems right now, and I'm probably just being delusionally paranoid.