encryption with python

[Ron Adam]

Kirk Job Sluder wrote:
> Ron Adam <rrr at ronadam.com> writes: 

>>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.

For that matter if the encrypted data is used a the key, then there is 
no need to store the data period. OH... lets see, we'll just store the 
password, and give them the data instead. Never mind it's a few thousand 
characters or more.  ;-)  "Oh, and don't loose your account number BTW."


> 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.  

Why would you need a table hanging around?

Most databases today are relational, so they are made up of lots of 
linked tables of records and fields.  And each user, can have access to 
some parts without having access to other parts.  So couldn't you 
create a separate account to access, names and id numbers only?

Cheers,
Ron