|
|
|
|
|
|
by rupert_murdaaa
4405 days ago
|
|
|
this always gets me, and every time i ask i can't seem to find a direct answer why so many sites have this 20 character limit. bank of america does as well, with the additional restriction that you can't use the following characters: $ < > & ^ ! []. bluecross/blueshield allows up to 30 characters, but only numbers and letters. if passwords are being hashed, which i guess i would have to believe they are, at least in the BOA case, what's the point of restricting character counts (especially to 20), or choosing random characters to exclude? |
|
|
1. Legacy systems. The system that was built 15 years ago might have limited the field for performance or storage reasons and it was never updated. Or maybe the Palm Pilot app only supports 20 characters in a text field and nobody has the source code but there's still a dedicated bunch of 200 users who do $50,000 in sales every year and nobody wants to piss them off. Or maybe they're just afraid the monster has gotten too big and they don't know what'll break if they change anything. Better to play it conservative so you're not the person who shut a group of users out of the system.
2. Just because. True story: I was working on an internal app for a company years back and I asked my manager if there were any particular password restrictions we needed to honor, any kind of company policies or weird accessibility concerns or something [1]. So what does he do? He emails the marketing stakeholder and asks her what the password rules should be. She doesn't know anything about security, so she concocts something completely arbitrary based on stuff she's seen on other sites. 6-10 characters, at least one number & one symbol, etc. And those were the requirements I had to implement, because that's what the stakeholder wants, even though that was the answer to completely the wrong question.
> if passwords are being hashed, which i guess i would have to believe they are
I wouldn't assume that. Think about a bank where you have call center staff who know a certain customer by name because he calls every Thursday saying he can't remember which of his grandkids' names he used as a password and could you please tell him because the rent is due Monday and he needs to transfer money from savings to checking because his Social Security check is late this month. And so on. You know how old guys are with their stories. You're reading one now. The CSR doesn't want to walk him through the steps of resetting his password over the phone…again. The faster he can get him logged in, the sooner he'll go away.
"We need a way to display that guy's password to a CSR," the head of the department tells the CEO over golf, knowing if he gets the department's average call time under two minutes he gets an extra $100,000 this year. So, the edict comes down from the highest levels of the company that the passwords have to be encrypted & reversible instead of hashed.
Now, this story is completely fictitious, but I've been in similar situations where the all-important call-center & support metrics trumped security. It happens. It shouldn't, but it happens.
[1] Maybe even a legacy Palm Pilot app…