re: What are the worst security practices you've ever witnessed? VIEW POST


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 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: "😑"


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:


Yes, I had to implement that 🤦‍♂️

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!

"Our customers aren't used to passwords that long."

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!


Pretty much any actual action taken that reduces security is done in the name of convenience. In the case of max password lengths, it could be due to a really naive SQL implementation where there's a max character length in a plaintext field, but it's much more likely that some manager saw that 90% of the help desk time was spent resetting passwords and thought "Well if we make the passwords shorter, people will stop forgetting them."

code of conduct - report abuse