Increase the default max password length

Details

Type: Improvement

Status: Closed

Priority: Major

Resolution:
Fixed

Affects Version/s:
None

Fix Version/s:
None

Component/s:
None

Labels:

None

Number of attachments :

0

Description

Getting a message "You must provide a password between 1 and 8 characters in length" with a password that looks like "aaaaaa###" (where "a" is a letter and "#" is a number)..
The passwords should not be limited in length.

Brill Pappin
added a comment - 15/Dec/06 8:16 PM I took a quick look at the code after I entered this and issue MRM-225 .
It looks like password length and complexity is a function of Plexus but I'm not sure.
If it is a Plexus thing, it important enough to write a custom component and leave plexus out of the loop.

Joakim Erdfelt
added a comment - 17/Jun/07 8:26 PM Closing as "Wont Fix"
Agreement on "default values" cannot be met. (Everyone has a different view on what is considered default. Having the restrictions in place lets people know that are restrictions.)
Documentation on how to change the defaults exist at http://maven.apache.org/archiva/guides/security-configuration.html

Setting the issue as "Won't Fix" based on the statement that people can't agree on what minimum values are is completely bogus.

1) This is a team of experienced developers and sombody does have the final say to get people in line when no agreement can be reached.
2) When in doubt, err on the side of the user experience; which means you don't limit the values. Most people using it will not care and those minority that do can be the ones to go looking though the documentation to find out how to limit it.

Brill Pappin
added a comment - 17/Jun/07 10:04 PM Setting the issue as "Won't Fix" based on the statement that people can't agree on what minimum values are is completely bogus.
1) This is a team of experienced developers and sombody does have the final say to get people in line when no agreement can be reached.
2) When in doubt, err on the side of the user experience; which means you don't limit the values. Most people using it will not care and those minority that do can be the ones to go looking though the documentation to find out how to limit it.

Joakim Erdfelt
added a comment - 18/Jun/07 10:11 AM Moved JIRA from Archiva to Plexus Redback.
Upper limits on passwords are common.
They exist due to limitations imposed on various password encoders, and datastores.
Above all, this is configurable by you, the user. If you don't like the defaults, change them.
The only valid reason to keep this jira open is to allow the upper limit to be set to infinite, and that is a recipe for other security nightmares.
If you feel so strongly about this, then participate on the discussion at archiva-dev. Be sure to cite industry practices.

allow a 16 digit password, then break that into two 8 character strings and encrypt that and then append the results together...so if your password was 10 characters long the last 2 characters were trivial to break...

point being 8 characters has been a very common limit for a long time, either strictly enforced, or silently chopping off whatever was left over

I am fine with moving the upper limit to 24 characters and setting the default to that...The user can still change this default behavior themselves if they wish. I'll bump up the default for the next redback release.

Jesse McConnell
added a comment - 18/Jun/07 10:56 AM we could do what NT I think it was used to do..
allow a 16 digit password, then break that into two 8 character strings and encrypt that and then append the results together...so if your password was 10 characters long the last 2 characters were trivial to break...
point being 8 characters has been a very common limit for a long time, either strictly enforced, or silently chopping off whatever was left over
I am fine with moving the upper limit to 24 characters and setting the default to that...The user can still change this default behavior themselves if they wish. I'll bump up the default for the next redback release.

I don't think it makes any sense to set an arbitrary password length limit. Why is setting the upper limit to infinite a recipe for other security nightmares?

Even if Archiva is commonly used in environments enforcing various limits on password length, then the low probability of any arbitrary default limit corresponding with the particular limit of any environment makes such a default useless, it seems to me.

Max Bowsher
added a comment - 18/Jun/07 12:59 PM I don't think it makes any sense to set an arbitrary password length limit. Why is setting the upper limit to infinite a recipe for other security nightmares?
Even if Archiva is commonly used in environments enforcing various limits on password length, then the low probability of any arbitrary default limit corresponding with the particular limit of any environment makes such a default useless, it seems to me.

I would agree that an arbitrary limit doesn't make much sense (which is why this issue exists), however if people are determined to have one then it should be long enough that a nine char password doesn't generate an error... it's simply too short.

Brill Pappin
added a comment - 18/Jun/07 1:24 PM I would agree that an arbitrary limit doesn't make much sense (which is why this issue exists), however if people are determined to have one then it should be long enough that a nine char password doesn't generate an error... it's simply too short.

Joakim Erdfelt
added a comment - 18/Jun/07 2:08 PM Brill, Max.
All systems have an upper limit.
Most systems will silently truncate at that limit, making any content after that limit pointless.
There are always upper limits.
There will remain upper limits.
What's left to hammer out ...
Do we state the upper limit in the error messages?
Do we allow the upper limit to be configurable?
Do we emulate other systems and have a hard-coded upper limit that just truncates?

While I understand the argument, this is a Java library and itself doesn't have any such limit beyond the limits of a string string or char array.

That does not mean that there are not limits in stores that Plexus may want to provide an implementation for, however those implementations can handle the requirements of their stores in a way that makes sense for them. This component should not arbitrarily enforce limits that those implementations may or may not need.

Stores with a "hard coded upper limit" may truncate or use any other pattern that they need to use to satisfy the story they are implementing. To answer you question, here is my opinion:

Do not state the upper limit in the error message, this I think would be a security problem.

Upper limit if there is one must be configurable, preferably in-process to that an application using it (like Archiva) can provide their own limit or allow the user to change it though a UI.

No truncation should occur. Allow implantations to truncate if that is truly what they need to do, but not all implementations will need to truncate and they should not receive a pre-truncated password under any circumstances.

Brill Pappin
added a comment - 18/Jun/07 2:22 PM While I understand the argument, this is a Java library and itself doesn't have any such limit beyond the limits of a string string or char array.
That does not mean that there are not limits in stores that Plexus may want to provide an implementation for, however those implementations can handle the requirements of their stores in a way that makes sense for them. This component should not arbitrarily enforce limits that those implementations may or may not need.
Stores with a "hard coded upper limit" may truncate or use any other pattern that they need to use to satisfy the story they are implementing. To answer you question, here is my opinion:
Do not state the upper limit in the error message, this I think would be a security problem.
Upper limit if there is one must be configurable, preferably in-process to that an application using it (like Archiva) can provide their own limit or allow the user to change it though a UI.
No truncation should occur. Allow implantations to truncate if that is truly what they need to do, but not all implementations will need to truncate and they should not receive a pre-truncated password under any circumstances.