Password validation security issue

Roy Smith roy at panix.com
Sun Mar 2 21:01:09 CET 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