encryption with python
Kirk Job Sluder
kirk at jobsluder.net
Sun Sep 11 06:46:47 CEST 2005
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.
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust." --Scary Go Round
More information about the Python-list