The database schema is unrelated to the maximum length of the user's password, because the password value gets hashed before being stored in the database. The hash function always generates a constant length value, and it's shorter than 32 characters.

The only case where you would need more than 32 chars, is if you were using PLAIN authentication method, which is deprecated. As mentioned by jreese, the default MD5 authentication generates a 32-char hash so a longer field is not necessary.

Are you telling me restricting the password to ridiculously low standards is a feature, not a bug?

1. Even if the hash is shorter than the password, I should be able to chose a longer password.
2. If MD5 is too short with 32, chose SHA1 with 40 or SHA256 with 64 characters.

Hi,

I believe you misunderstand the comments. The password length is not restricted; you can choose a password of any length you like. The system will not store the password itself but its MD5 hash, which is 32 chars in length.

Hope this clarifies.

To complete Dregad, some examples :

password "toto"(length: 4 chars)
=> hash md5 is "f71dbe52628a3f83a77ab494817525c6" (length: 32 chars)
=> hash sha1 is "0b9c2625dc21ef05f6ad4ddf47c5f203837aa32c" (length: 40 chars)

password "1234567890123467890123456789012345678901234567890" (length: 50chars)
=> hash md5 is "bb8c1e1072cec89374f71544c83c3f94" (length: 32 chars)
=> hash sha1 is "8fa2ab0d5a2d8f565b3ba1d22191896788b2124c" (length: 40chars)

About length

password "3!M3M!Cd!Pd4" is more secured than "itismybeautifulandverysimplepassword"

I believe you misunderstood my initial post.

There is an input length restriction for passwords at least in these files:

https://github.com/mantisbt/mantisbt/blob/master/manage_user_create_page.php#L87
https://github.com/mantisbt/mantisbt/blob/master/account_page.php#L149

Also, when taking out these lines and entering a password longer than 32 characters, I cannot login with that. It works with up to 32 characters. Did you try my steps to reproduce?

Lapinkiller: My password manager creates passwords like "xi3=vAHGOdE^u+AE1DOM>qlr->Dv0Llc+-P3".

so it's a HTML or php problem and not a database problem...

Ah, now I get it. We are not talking about a database limitation here, but the number of characters that are accepted by the HTML page.

ilf, I think you can solve your problem with an override the value of PASSLEN constant. This value is historically set to 32, matching the db field size, to avoid problem with PLAIN authentication.

Please create or modify custom_constant_inc.php :
<?php
define( 'PASSLEN', 64 );
?>

Let me know if that works for you.

The problem is twofold.

Problem 1:
Yes, raising PASSLEN would raise the maxlength in the input fields.
In a test with a mantis admin, we took out maxlength entirely and I was able to enter longer passwords.

Problem 2:
Even after doing what I said in 1 (and twice before), I can change my password to longer values, but i cannot login with it.
I cannot debug this further and I do not run a mantis instance.
Maybe (!) the crop happens before the hash?

Bonus:
I leave it up to you to decide how nice it is to:

1. crop passwords over a certain length without telling the user
2. Have that max length at 32 or 64.

I cannot debug this further and I do not run a mantis instance.

OK, I'll test it.

Maybe (!) the crop happens before the hash?

Definitely not. See function auth_process_plain_password, in https://github.com/mantisbt/mantisbt/blob/release-1.2.5/core/authentication_api.php

Regarding your "Bonus" point - I'm not quite sure what you mean to say.

Dear ilf,

I'm sorry but I am still unable to reproduce your problem. Here's what I did:

• fresh install of 1.2.5, all config values (except DB connection) set to default
• PASSLEN = 100
• sign up new user
• click verification link
• set a 60-char password and confirm
• login with new user and 60 char password
  ==> successful
  EDIT: tried also the same with the password you pasted in 0013100:0029225, which was also successful

Can you please confirm, what is the value for $g_login_method in your config ?

As I said, I do not run a Mantis instance, so I cannot say.

But $g_login_method shouldn't matter. Even if it is plain, the password should not be cropped without telling the user.

How about raising the default PASSLEN to 128?

Update: Could you please change PASSLEN on this Mantis install right here, so I can test it?

$g_login_method shouldn't matter.
It does. See explanation about hashes given before and review function auth_process_plain_password again.

the password should not be cropped without telling the user
There is no need to tell the user anything, since in standard configuration the input fields do not allow them to input passwords longer than PASSLEN anyway.

How about raising the default PASSLEN to 128?
That is not possible for the time being as it would require changing the database schema. See 0011250, there is an ongoing discussion on this.

Could you please change PASSLEN on this Mantis install right here, so I can test it?
Sorry, but this is not a test system, so what you ask can't be done. Please see with your admin if they can make the change on your instance, or setup a test environment.

As things stand, I believe that current Mantis behavior is correct.

the password should not be cropped without telling the user
There is no need to tell the user anything, since in standard configuration the input fields do not allow them to input passwords longer than PASSLEN anyway.

As I described in #c29230, an admin took out the maxlength="" values of the input fields. And then the password was cropped without telling the user.

$g_login_method shouldn't matter.
It does. See explanation about hashes given before and review function auth_process_plain_password again.

I know it currently matters, but my point is: It shouldn't.
There shouldn't be a maximum password length. Ever. Anywhere. At least not with values users actually hit like 32. I can take 256 or so, but 32 is too low.

If changing this needs a change in the DB layout, please do it.
This is what my bug report was all about.

an admin took out the maxlength=""

So, if I understand you correctly, you are currently running an non-standard version of Mantis. In that case, I don't think we can be held responsible for unexpected behavior.

In a standard setup, no cropping occurs, ever, because users can't physically enter passwords longer than the limit. If you change the code, then you have to live with the consequences.

As I said before, using MD5 auth, the system allows technically unlimited password size (see my comment 0013100:0029228). The fact that it does not work for you, leads me to believe you are not using MD5, hence my asking, in trying to help you, what authentication method you use.

Unfortunately you just dismissed the question - "I do not run a Mantis instance, so I cannot say". I think that if you can convince your admin to modify php files, surely you can get them to give you the value for that variable, no ?

I will grant you that 32 chars may be too low a limit, and I invite you to follow 0013163 where I'm trying to address that issue.

It's MD5.

Probably the way we did (taking out maxlength="") wasn't standard and my input of the password was restricted/cropped to 32 on some site.

My point remains. On a standard installation (and this one running here), passwords are restricted to 32 characters. I consider this a bug.

Thanks for taking note. And hopefully fixing :)

I'm marking this as resolved, as it turns out to be a duplicate of 0013163.

With regards to the truncation problem in your installation, as I am unable to reproduce it with MD5 auth on a standard setup with increased PASSLEN, I leave it up to you to decide how you want to fix it.