Also: for debugging purposes, I enabled MySQL logging with the intention of shutting it down once we went live. It logged all SQL commands - yes, the passwords were hashed, but with MySQL's password function, so all passwords appeared in plain text in the log.
My (former) boss: "So, the passwords are hashed in the database and we can't decypher [sic] them, but we're still seeing them with this log?"
Me: "Yes, but..."
My boss: "You know what, I see a solution for all those clients that keep calling for their forgotten passwords..."
Me: "😑"
Because they wanted, for "customers' convenience", the same passwords to work both on the web portal and as their AS/400 passwords. (Customers could also access to the AS/400 terminals.)
Which were limited to 10 EBCDIC characters. 😩
This actually had a glimpse of sense. Because it wasn't like that before. I've just left the passwords unconstrained and happily hashed them into the DB.
"Wait, limit the number of characters to... say, 20."
"What?! Why?"
"Our customers aren't used to passwords that long."
I'm not making this up.
Thinking about that now, there were so many security issues that make my stomach churn. And I'm no security expert!
Upper password limits are a sane thing to do, when the limit is high enough. Setting the upper limit to 100 characters allows you to test your system for how it deals with long passwords. Just see my other comment for why you should always make your password set fields a character longer than your maximum accepted password.
I'm not sure I'm following you here. Systems just shouldn't have maximum password lengths, period. Passwords should be hashed to fixed-length strings (and that should take a fixed amount of time), so the length of a password shouldn't be a problem, be it 100, 1000 or 314159 characters long. (Well, except for the fact that you're sending a request with a payload of more than 300 kb, but that's another problem...)
Anyway, we were dealing with AS/400 systems with rather old OS versions (5.2 I think), so the upper limit was 10 characters.
In theory, yes, passwords shouldn't have a limit. Password hashing isn't significantly affected by the input size, and storage definitely isn't affected. But what could be affected is your server and application and how they handle long strings. If you want to set the limit to 314159 characters, go for it. Just be sure you test for it too.
I explain the password set field should be 1 character longer than the password entry field here: dev.to/mitchpommers/comment/di2c
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Maximum password length.
Yes, I had to implement that 🤦♂️
Also: for debugging purposes, I enabled MySQL logging with the intention of shutting it down once we went live. It logged all SQL commands - yes, the passwords were hashed, but with MySQL's
passwordfunction, so all passwords appeared in plain text in the log.My (former) boss: "So, the passwords are hashed in the database and we can't decypher [sic] them, but we're still seeing them with this log?"
Me: "Yes, but..."
My boss: "You know what, I see a solution for all those clients that keep calling for their forgotten passwords..."
Me: "😑"
What was the reasoning here?
Because they wanted, for "customers' convenience", the same passwords to work both on the web portal and as their AS/400 passwords. (Customers could also access to the AS/400 terminals.)
Which were limited to 10 EBCDIC characters. 😩
This actually had a glimpse of sense. Because it wasn't like that before. I've just left the passwords unconstrained and happily hashed them into the DB.
"Wait, limit the number of characters to... say, 20."
"What?! Why?"
"Our customers aren't used to passwords that long."
I'm not making this up.
Thinking about that now, there were so many security issues that make my stomach churn. And I'm no security expert!
Wait, what?! Why in the heck does that matter? They set their own passwords. They don't have to enter 100-character passwords if they don't want to.
You're assuming I was talking with people that had an idea of what that was all about. 😵
I think I've learnt that people can be that clueless. Even in IT!
Upper password limits are a sane thing to do, when the limit is high enough. Setting the upper limit to 100 characters allows you to test your system for how it deals with long passwords. Just see my other comment for why you should always make your password set fields a character longer than your maximum accepted password.
I'm not sure I'm following you here. Systems just shouldn't have maximum password lengths, period. Passwords should be hashed to fixed-length strings (and that should take a fixed amount of time), so the length of a password shouldn't be a problem, be it 100, 1000 or 314159 characters long. (Well, except for the fact that you're sending a request with a payload of more than 300 kb, but that's another problem...)
Anyway, we were dealing with AS/400 systems with rather old OS versions (5.2 I think), so the upper limit was 10 characters.
In theory, yes, passwords shouldn't have a limit. Password hashing isn't significantly affected by the input size, and storage definitely isn't affected. But what could be affected is your server and application and how they handle long strings. If you want to set the limit to 314159 characters, go for it. Just be sure you test for it too.
I explain the password set field should be 1 character longer than the password entry field here: dev.to/mitchpommers/comment/di2c