encryption with python

[Kirk Job Sluder]

Ron Adam <rrr at ronadam.com> writes:

> Kirk Job Sluder wrote:
> 
> > 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.
> 
> I would think that any n digit random number not already in the data
> base would work for an id along with a randomly generated password
> that the student can change if they want.  The service provider has
> full access to the data with their own set of id's and passwords, so
> in the case of a lost id, they can just look it up using the customers
> name and/or ssn, or whatever they decide is appropriate. In the case
> of a lost password, they can reset it and get another randomly
> generated password.
> 
> Or am I missing something?

Not really.  My suggestion is that in many cases, if the data is being
used only as a backup password or authentication token, there is no need
for that data to be stored in plaintext.  For example, with the
ubiquitous "mother's maiden name" * there is frequently no need to
actually have "Smith," "Jones," or "Gunderson" in the database.
"bf65d781795bb91ee731d25f9a68a5aeb7172bc7" serves the same purpose.

There are other cases where one-way anonymity is better than a table
linking people to randomly generated userIDs.  I'd rather use
cryptographic hashes for research databases than keep a table matching
people to random numbers hanging around.  But I'm weird that way.  

* I think "mother's maiden name" is a really poor method for backup
  authentication because for a fair number of people in the U.S., it
  will be identical to their current surname, and for the rest, it's
  trivial to discover.  

 
> Cheers,
> Ron
> 

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