View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013047 | mantisbt | authentication | public | 2011-06-03 17:41 | 2011-08-05 02:45 |
| Reporter | packman | Assigned To | dregad | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | Linux | OS | Centos | OS Version | 5.4 |
| Product Version | 1.2.5 | ||||
| Summary | 0013047: PASSLEN constant doesn't match database field size | ||||
| Description | The PASSLEN constant is used for two purposes... 1) To limit the length of user input passwords on input forms PASSLEN is defined as 32, but the password field in the database is VARCHAR(64), so I think PASSLEN should be 64 rather than 32. Alternatively, two constants should be defined...one to limit the maximum input length and one to define the database field size. I ran into this because I'm trying to add an alternative password crypt system into Mantis (for my own purposes only) which generates 40 character encrypted password strings. I knew the database could handle the generated string, but I couldn't work out at first why I couldn't get any password matches until I found the artificial truncation to 32 chars. | ||||
| Tags | No tags attached. | ||||
|
I am not sure where you found the information that password field size in db is varchar(64) - the field size is 32 (cf schema.php [1], line 320). Did you alter your DB schema by hand ?
[1] https://github.com/mantisbt/mantisbt/blob/release-1.2.5/admin/schema.php |
|
|
Hmmm...I haven't changed that field recently, but I looked at the default size and it is as you say only 32 chars. I can only assume that I changed it a few years ago and forgot to make a note of the change at the time. This report can be closed, although it may well still be worthwhile creating a new PASSLEN_DB variable in future if different crypt systems are implemented because not all crypt algorithms generate an encrypted value of the same length as the original string. |
|
|
Thanks for your reply; I am marking this one as resolved. However, taking into account your suggestion to decouple the DB field size from the password size when using MD5 authentication, I have opened 0013163 to track this. |
|