P.S., the documentation would emphasize that encryption is only appropriate when the data needs to be protected 'at rest', e.g., for statutory or contractual reasons. It should also discuss correct ways to handle protection 'in motion', e.g., using a separate schema for privileged tables and using joins on the less secured schema. Most operations would use the regular datasource, privileged users could use the second datasource with access to the add'l tables. That's why access to the encryption key id is less of a problem than the earlier comments suggested -- you can simply store the encryption key id and salt in a separate table so illicit access to the primary schema would never show anything other than the encrypted data.
Also, the database book discusses per-field salts & keys, but a single per-row key and salt is (to me) a good compromise between security and convenience. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
