Increase the default max password length

Should also be decided on by beta-1.

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.

Password length is configurable via Plexus Redback.

See: http://maven.apache.org/archiva/guides/security-configuration.html

Then set the default to a larger value and make sure its documented in the application.

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.

I suggest someone starts a thread on the dev list about this

I agree that an 8 character maximum is too short for the default, but this needs to be changed in Plexus Redback, not in Archiva.

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.

Mailing List Information:
http://maven.apache.org/archiva/mail-lists.html

Nabble Post for thread:
http://www.nabble.com/Default-Password-Controls-in-Archiva-%28-MRM-229---MRM-225-%29-tf3939367.html

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.

Thanks Jesse. 24 sounds reasonable to me. (I'd edit the summary to 'Increase the default max password length' but I don't have permission here.)

24 sounds good to me as well, it should allow a sufficiently complex password that any systems policy would be satisfied.

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.

Adjusting summary description to fit with request from wsmoak.

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 ...

1. Do we state the upper limit in the error messages?
2. Do we allow the upper limit to be configurable?
3. 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:

1. Do not state the upper limit in the error message, this I think would be a security problem.
2. 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.
3. 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.