Steven H. McCown wrote: > The reason that I proposed the non-centralized storage option is that not > that security is more or less, but because attacks on very small databases > yield very small rewards. In contrast, attacks on highly-centralized > databases offer greater rewards for the attacker.
The architecture I suggested would effectively turn the centralized server into warehouse of small, practically unbreakable databases. A desktop application will be the only way to use the database. The database will be encrypted with high grade encryption and using a long key. When users enter their password, they will enter the password for accessing the key, not for opening the database. The key will be stored on the user's hard drive (or even in the TPM module embedded in their computer), not on the web server. To allow a new user to access the database, that user needs, at a minimum, both the key to the database (an RSA key, perhaps) and the password for using that key. Users will be required to copy keys between computers using removable media. Even administrators of the web server won't be able to access the databases because they won't have the keys. It wouldn't even matter if they guessed passwords. A password of "123" is OK as long as the key is guarded. If everyone loses their keys, the database will become impossible to access. There is no "master" key. The only practical way to break such a system is to steal private keys one at a time or find a flaw in the way the software is using cryptography. Conceivably, someone could write a virus that steals private keys, but *any* desktop application is vulnerable to that attack, so that's merely an argument for not using operating systems that have a lot of vulnerabilities. So the only concern is that the application has to use cryptography correctly. Now that we have OpenSSL, that's not very hard. Shane _______________________________________________ Ldsoss mailing list [email protected] http://lists.ldsoss.org/mailman/listinfo/ldsoss
