Password validation security issue
Roy Smith
roy at panix.com
Sun Mar 2 15:01:09 EST 2014
In article <mailman.7592.1393788339.18130.python-list at python.org>,
Christian Heimes <christian at python.org> wrote:
> On 01.03.2014 21:11, Chris Angelico wrote:
> > The problem isn't SHA-256. The problem is insecure passwords, the way
> > we've been taught to make them by the banks. Hence, XKCD 936.
>
> Your argumentation is just wrong. You are saying "It's OK to use a
> totally insecure way to hash passwords because passwords are insecure".
> The point of KDF and KSA is to derive some token from a low entropy
> source (human input) that makes an attack harder. Please do your reading
> and trust secure experts on algorithms like PBKDF2, bcrypt and
> scrypt. hash(salt + password) is outdated and proven to be insecure for
> at least a decade, more like 15+ years.
>
> The concept of passwords itself is insecure. But we are stuck with
> passwords for authentication mechanism for the foreseeable future. 2FA
> is an attempt to increase the security of passwords-based authentication
> schemes.
>
> Christian
Security is as much about cryptography as it is about human factors and
business drivers. You can make things resistant to brute-force attacks
by using longer keys, but people are still going to pick bad passwords.
You can force them to pick "good" passwords by rejecting their first 37
choices, but all that does is encourage them to write the passwords down
on sticky notes.
And, yes, you can make things more secure with 2FA, but there's a cost
there. You have to purchase and manage the infrastructure. More than
that, there's lost business if potential customers prefer a competitor's
product because it's easier to access. Many of the known insecure
systems we use today are not that way because the people who run them
are stupid; they're that way because the people who run them have worked
the numbers and decided the cost to implement more secure systems would
exceed the risk exposure.
We recently got a frothing email from a user, which basically said, "You
farking idiots, you emailed me my password in plain text!" It turns
out, his user name was the same as his password and what we had sent him
(in response to an account recovery query) was his username. In
response to that, we altered our account generation process to forbid
passwords which are too similar to your chosen username or email
address. Which, of course, means we've taken one more step down the
road to forcing our users to write their passwords on sticky notes.
More information about the Python-list
mailing list