Live data from Hacker News

How *NOT* To Do A Password Field

shkspr.mobi

11–20 of 20 posts

Re: How *NOT* To Do A Password Field

#11
post #9

The problem with really awful password interfaces lies mainly with big institutions (banks!) who are unlikely to be influenced by bloggers linked on hacker news. Ever since switching to a password manager (1Password in my case) I've become acutely aware of how many places have ridiculous restrictions on passwords (especially maximum lengths and character restrictions), and the worst offenders are invariably banks and…

I just hope that one of their consultants' designers read my blog :-)

Re: How *NOT* To Do A Password Field

#12
I hate sites that restrict how complex my password can be. Seriously, NemID, a Danish ID every person has that's used for everything (banking, among other things), don't allow special characters. What the heck. It's like they want it to be insecure.

Re: How *NOT* To Do A Password Field

#13
On a related topic, a troubling new trend (to me) is the reliance on passwords being automatically generated/kept by a tool. You are putting your trust in something else for something only you (or a select group) should be trusted with. If everyone were to start doing this or a vulnerability was found in it and exposed, then attackers would exclusively target the tool or the password store, making many at risk.

It is a trade off, because you have the ability to use significantly more complex passwords that are harder to brute force or guess using personal information. Just don't forget that you are providing new attack vectors in the process. If they access your password store and you didn't know about it, how at risk would you be if they were to unlock all of your passwords?

Do you really understand how the password store and password generator work?

Re: How *NOT* To Do A Password Field

#14
post #9

The problem with really awful password interfaces lies mainly with big institutions (banks!) who are unlikely to be influenced by bloggers linked on hacker news. Ever since switching to a password manager (1Password in my case) I've become acutely aware of how many places have ridiculous restrictions on passwords (especially maximum lengths and character restrictions), and the worst offenders are invariably banks and…

It seems like the more secure you need your data to be, the worse their password restrictions are. Restrictions such as no special characters, or an arbitrary short length raises a red flag. It says they don't really know what they are doing, and it makes me wonder what else is broken.

Re: How *NOT* To Do A Password Field

#15
post #11
post #9

The problem with really awful password interfaces lies mainly with big institutions (banks!) who are unlikely to be influenced by bloggers linked on hacker news. Ever since switching to a password manager (1Password in my case) I've become acutely aware of how many places have ridiculous restrictions on passwords (especially maximum lengths and character restrictions), and the worst offenders are invariably banks and…

I just hope that one of their consultants' designers read my blog :-)

We can hope :-)

Re: How *NOT* To Do A Password Field

#16

Why would you have to restrict the length at all? I could see something like a few thousand characters max, to avoid making it easy to strain the server, but other than that, you're not supposed to store it as is anyway, and if you hash it, the input length doesn't really matter... what am I missing?

You're missing the obvious - that such restrictions are a sign the site does probably store passwords in plaintext.

Although maybe they aren't but they still want to make sure they meet some arbitrary standard of "randomness" to make it less "hackable."

Re: How *NOT* To Do A Password Field

#17
If you must have a maxlength, please be sensible. I've seen plenty of sites use 12 as max length - which is really not that much.

Also, requirements to what characters must be used (at least one number, at least one upper case letter) doesn't do much to increase security I think. Just let me enter whatever I want.

Re: How *NOT* To Do A Password Field

#18
post #9

The problem with really awful password interfaces lies mainly with big institutions (banks!) who are unlikely to be influenced by bloggers linked on hacker news. Ever since switching to a password manager (1Password in my case) I've become acutely aware of how many places have ridiculous restrictions on passwords (especially maximum lengths and character restrictions), and the worst offenders are invariably banks and…

It seems like the more secure you need your data to be, the worse their password restrictions are. Restrictions such as no special characters, or an arbitrary short length raises a red flag. It says they don't really know what they are doing, and it makes me wonder what else is broken.

And no SQL keywords allowed in passwords. Because they like to advertise that they don't bother escaping user input before concatenating sql strings to store plain text passwords in the database.

http://stackoverflow.com/questions/13738141/blacklist-filter...

Re: How *NOT* To Do A Password Field

#19

Earlier quoted context omitted.

It seems like the more secure you need your data to be, the worse their password restrictions are. Restrictions such as no special characters, or an arbitrary short length raises a red flag. It says they don't really know what they are doing, and it makes me wonder what else is broken.

And no SQL keywords allowed in passwords. Because they like to advertise that they don't bother escaping user input before concatenating sql strings to store plain text passwords in the database. http://stackoverflow.com/questions/13738141/blacklist-filter...

I'd bet that patterns like

    $db->execute("INSERT INTO USERACCOUNTS ('username','password') VALUES ('".$_POST['username']."','".$_POST['password']."')");
are more common than anyone wants to believe.

Re: How *NOT* To Do A Password Field

#20
post #19

Earlier quoted context omitted.

And no SQL keywords allowed in passwords. Because they like to advertise that they don't bother escaping user input before concatenating sql strings to store plain text passwords in the database. http://stackoverflow.com/questions/13738141/blacklist-filter...

I'd bet that patterns like $db->execute("INSERT INTO USERACCOUNTS ('username','password') VALUES ('".$_POST['username']."','".$_POST['password']."')"); are more common than anyone wants to believe.

The PHP manual pages are full of user comments with helpful suggestions just like that, which incompetent programmers copy and paste into production systems. But I think of it as a good thing, an instance of evolution in action, because banks that hire such stupid programmers deserve to have all their money stolen from them.
Post reply on HN