Ron Adam <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
