encryption with python

[Kirk Job Sluder]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> Kirk Job Sluder <kirk at jobsluder.net> writes:
> > Well, there is a form of security design that involves one-way
> > encryption of confidential information.  You might want to be able to
> > search on SSN, but not have the actual SSN stored in the database.  So,
> > you are prepared to deal with the inevetable, "I lost my
> > password/student ID, can you still look up my records?"  
> 
> The minute you provide a way to do that without secret keys, you have
> a security hole.

Providing any kind of access to data involves creating a security hole.
This is the biggest flaw in most discussions of computer security.  Too
much of it depends on everyone remembering (and using) unique
cryptographically strong keys.

You have a client on the phone who needs access to information, but has
forgotten or lost the 10-digit unique ID and the PIN you gave them two
years ago.  How do you provide that client with the information he or
she needs?  This is the kind of dilemma that one-way encryption is
designed to make a tiny bit safer. 

SSNs + some other secret (such as mother's maiden name) is certainly
crappy security.  However, I don't think we are going to see widespread
adoption of anything better in the near future.  

But even if we go with "more secure" authentication tokens, there is usually
no reason to store the authentication token in plaintext.   

>  SSN's are 9 digits which means there are 1 billion
> of them.  If there are 100,000 hashed SSN's in the database, the
> attacker (since this is clpy) can read them all into a Python dict.
> S/he then starts generating SSN's at random and hashing them and
> checking whether those hashes appear in the dict.  Doing stuff like
> iterated hashes to slow the attacker down doesn't help that much: the
> attacker needs to hash only 10,000 or so SSN's to be likely to hit one
> that's in the dict.  If the attacker can hash all 10**9 SSN's, which
> isn't all that terribly many, every SSN in the database spills.

Of course, an additional step I didn't mention was that in actual
practice the SSNs would be hashed with a strong random secret key. But
from my point of view, the possibility for dictionary attacks is pretty
much unavoidable as long as we are dealing just with memorized tokens.

We've been bitching, whining and moaning about the small keyspace and
poor quality of what users are willing to memorize for 20 years.  We can
complain about it for the next 10 which is about how long it will take
for any kind of alternative to be adopted.  I still think that one-way
hashing of authentication "secrets" is better than plain-text storage.

> Bottom line: to keep confidential stuff secure, you need actual security.

The only way to keep confidential stuff secure is to shred it, burn it,
and grind the ashes.  

I think the fundamental problem is that that most customers don't want
actual security.  They want to be able to get their information by
calling a phone number and saying a few words/phrases they memorized in
childhood.  Given the current market, it seems to be cheaper to deal
with breaks after the fact than to expect more from customers.

-- 
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust."  --Scary Go Round