Thank you to Mike Meyer, Kirk Sluder, and anyone who made constructive comments and/or corrections to my earlier post about generating student IDs as random numbers.
Especially thanks to Marc Rintsch who corrected a stupid coding mistake I made. Serves me right for not testing the code. Kirk pointed out that there is a good usage case for using a one-way encryption function to encrypt a Social Security Number to the student ID: > you are prepared to deal with the inevetable, "I lost my > password/student ID, can you still look up my records?" Whether the usefulness of that use outweighs the risks is not something we can decide, but I hope the original poster is considering these issues and not just blindly going for the technical solution. For example, this is one possible way of dealing with students who have lost their student ID: - ask student for their name, d.o.b. and SSN; - search the database for students whose name, d.o.b. and SSN match; - if you have more than one match, there is a serious problem; - otherwise you may consider that the student has proven their own identity to you sufficiently, so you can safely tell them the student ID. No need for a function that calculates the ID from the SSN, with the associated risk that Black Hats will break the algorithm and use the student ID to steal students' SSNs. In effect, this scheme uses the algorithm "look it up in a secure database" as the one-way function. It is guaranteed to be mathematically secure, although it is vulnerable to bad guys cracking into the database. Thanks also to James Stroud for his amusing extension to the one-time pad algorithm. If you have a need to be able to reconstruct the data, then of course you need some sort of cryptographic function that can encrypt the data and decrypt it. But that begs the question of whether or not you actually do need to be able to reconstruct the data. The point of my post was that you may not need to, in which case a random number is as good as any other ID. James also protested that passwords are "security through obscurity", since "All they have to do is to get that secret key and all those records are easily readable." Of course this is technically correct, but that's not what security through obscurity means to folks in the security business. The difference between security through obscurity and security through a secret key is profound: if I reverse-engineer your secret algorithm, I can read every record you have. But if I discover the secret key belonging to one person, I can only read that person's messages, not anyone else's. As James says, "The point is that *something has to be kept secret* for encryption security to work." Absolutely correct. But now think of the difference between having keys to your door locks, compared to merely keeping the principle of the door handle secret. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
