Hacker News Reader

Comment by dinkumator | Hacker News Reader

There's really no point in restricting length or non-alphanumeric characters. They should be storing a salted hash, not the actual passwords, so the content of the password shouldn't matter.

It's really just laziness and incomptence on the part of the programmers.

View on HN

They should be storing a salted hash, not the actual passwords, so the content of the password shouldn't matter.

No, they should be using bcrypt. You didn't think you'd get away with this by posting after tptacek's bedtime, did you?

md5, sha, blowfish, bcrypt... name your pick. i didn't mention a specific algorithm. either way, you're still not saving the password to a database.

And another thing that's incredibly irritating are these stupid sites that force you to type out your password (they don't let FF write it in the text field). How is that more secure! It just forces me to either use a simple password or write it down somewhere. My normal behavior is to use a totally different password for every site and let my browser manage it.

> There's really no point in restricting length or non-alphanumeric characters.

I agree, the only rationale I can think of for this is that these institutions don't want people to forget their passwords, but even then I don't understand why they would want that at the expense of security.

The irritating thing is that forbidding spaces discourages pass phrases. You can't use "the cat sat on my blue suede shoes", which is pretty secure yet easy to remember.

You could use "thecatsatonmybluesuedeshoes", but that may be harder to type accurately.

The argument I once heard for restricting length of a password (and possibly special characters) is that it would be harder to craft a buffer overflow (or SQL injection attack) with those limitations. I don't agree that this is a good solution, but it's not always good programmers/managers who are making these decisions. It at least sounds plausible.

Hmm? The hash will be a fixed length, which is the only thing you'd be storing.

In order to get that hash you'd have to process the password in its entirety. But really, if they're that concerned about the buffer I see no reason to cap it at 8 or 10 rather than 1000.

Eh. That seems unlikely, assuming you're not writing your own routines. At most you'd get an out of memory error. I can calculate the SHA1 digest of a 1Bn character string without running into that problem.

So let's cap the length at 100k characters and call it a day.

That's a really bad argument. If password length is threatening to you, you have no business accepting passwords.

(Length also has almost nothing to do with SQL Injection, and you're plugging a raw password into an SQL query you're doing something very wrong anyways).

Reply on news.ycombinator.com