"be consistent" | |
PerlMonks |
Re: Re: Re: Cryptography Best Practicesby dws (Chancellor) |
on Nov 11, 2002 at 22:07 UTC ( [id://212113]=note: print w/replies, xml ) | Need Help?? |
the problem that i am combatting is two-fold: data integrity and non-repudiation. i am trying to prevent people from being able to change data, and if they do change data (or add data) they will be logged in a secure way.
For access, you could combine SSL (https:) and Basic Authorization. That, coupled with logs, can give you a record of who changes what. You're still relying on your end users to not leak (or share) passwords. On the server side, if you want the system to have unencrypted access to the data, you have to decide how to handle your keys. A worst-practice is to embed keys into scripts. This can be bad because every so often an exploit appears that lets users see script source. A somewhat better practice is to place keys in a configuration file that isn't visible to the web server (i.e., in a file that can't be reached via a URL).
In Section
Seekers of Perl Wisdom
|
|