The Site > DSLReports.com > Site Feature Requests > please increase maximum password length

please increase maximum password length

This is only an online forum. It isn't fort Knox.

Completely true.

But since the entire site password mechanism is being reviewed and revised right now, it seems the opportune time to make this request. I further assume this is just some parameter in some configuration file, so changing it now should be easy.

I've made this request of other sites too, ranging from forums up to banking services. Pass-phrases are easier for humans to remember and eliminate the need to use utilities (OS or 3rd party) of questionable security to keep track of cryptic and meaningless 8-12 character strings.

Peace.

reply to gust334
If password will be kept on a hash format, not in plain text (as it is right now), there will be no limit for password length. Until it will be changed I guess it's impossible due to specific limit on data field in DB.

BTW, current problem was not related to the strength of passwords. The problem was/is - passwords are kept in plain text... It means, no matter if you use 20 characters, very strong password or just a weak like "pass" (4 characters only), if DB is compromised - the result is the same...
--
Keep it simple, it'll become complex by itself...

reply to gust334
*object* - not necessary.

reply to gust334
* Sign *

reply to gust334
*signed*

It is necessary because passwords should not be stored in plaintext. Once passwords are hashed, the site should be able to support arbitrary length passwords. Therefore, requesting longer password support is equivalent to requesting hashed passwords.

Character set and length restrictions on passwords are almost sure signs that the password storage implementation is bad.

Hashed and unhashed passwords can live together in the database just fine. Once the stored copy is retrieved, if it's in a hash format then hash the password before comparing; if it's not, then compare it as if it's a plaintext password. If the stored version is ambiguous, try all possibilities. That's what many web apps do to allow importing of users from other databases that are hashed in various ways: md5, sha1, sha1+salt, etc.

Bcrypt (»php.net/manual/en/function.crypt.php for php) is widely considered the best countermeasure to protect against password compromise of okay-but-not-great passwords in a leaked password database. It's also nice because it uses the crypt() salt+password format, which provides for upgradability to new hashing schemes if they become necessary, while maintaining backward compatibility. If a different, ambiguous format is used, the password checking function has to try all the possible hashing functions.

If cpu efficiency is a pressing concern, the bcrypt work factor can be lowered, but in most cases the cputime of the web app validating the password will eclipse the cputime required to do bcrypt hashing for a modest work factor.

reply to removed
If users all adhered to good security practices, using (pseudo)random passwords for each site, then I would agree, it wouldn't matter much if sites stored them in plaintext.

Most users unfortunately do not do that. Plaintext or poorly-hashed password storage puts many site members at risk, even if it does not put *you* at risk.

reply to anoxia

I think you misinterpreted. I agree with what you wrote.

If a site doesn't allow punctuation or long passwords, that suggests the site is not hashing passwords at all. Failing to hash passwords before storing them is horrible. Failing to salt passwords before hashing them is very bad. Failing to hash passwords using a many-round hash scheme is bad.

However, password strength is not everything. The hash method matters a lot, too. Bcrypt with work factor 12, or pbkdf2, won't protect someone with password "password", but it will save someone with the password "Fuzzybear5" (note: not my password).

This is about BBR's password scheme. BBR has a pw length restriction. Therefore they are not hashing passwords, because length doesn't matter when you do hashing. Therefore BBR's password storage is very insecure, and needs to be fixed. Preferably with pbkdf2 (multi-round sha512) or bcrypt.

(edit: pbkdf2 seems to be better than bcrypt because the latter only hashes the first 55 characters of the password.)

--
"From the information I have and to answer your questions, SkyNet did not have anything to do with the [Amazon Web] service[s] [outage] event at this time." --Luke@AWS

how about bcrypt with a 55 character limit?

There is already a limit. A webserver or a dynamic language like php should restrict the size of any POST/GET parameters. No further restriction is necessary.

Even though bcrypt only hashes 55 characters, there's no reason to artificially reject longer passwords in the password checking/setting functions.
--
"From the information I have and to answer your questions, SkyNet did not have anything to do with the [Amazon Web] service[s] [outage] event at this time." --Luke@AWS

reply to gust334
*SIGN*

reply to gust334
*SIGN*

Main reason is while this is not a banking site, there are accounts here with access to potentially revealing/personal information (think: ISP VIP users and their direct support forums or other industry forums).

The purpose of securing a site like this shouldn't be to only evaluate the common-most situations (general users), but to evaluate the higher thresholds (premium, ISP VIPs, moderators, other staff and administrators) and adjust accordingly.

Keeping security to the "lowest needed" is an incorrect approach.
--
--Kradorex Xeron
[an error occurred while processing this signature]

then I propose 2 step verification with a token challenge-response