Re: Re: Re: Cryptography Best Practices

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

Comment on Re: Re: Re: Cryptography Best Practices

Replies are listed 'Best First'.
Re: Re: Re: Re: Cryptography Best Practices by kshay (Beadle) on Nov 12, 2002 at 00:44 UTC
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. I think a bigger concern than an exploit would be the possibility that another employee within the organization, who has access to view the source code, might take advantage of the keys to do something unwanted. In every company I've worked for, there's been much less stringent security applied to viewing scripts than to other activities like logging in to databases, launching scripts to live websites, etc. In the corporate world, lazy server administrators often give temps and low-level employees access to much more information than they need or should be able to see. Before you even worry about some hypothetical software flaw whereby a user might view your script over the Internet, think carefully about restricting the set of people in your company who might have unfettered access to whatever keys or other sensitive information you're hoping to conceal. --Kevin	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: Cryptography Best Practices
by kshay (Beadle) on Nov 12, 2002 at 00:44 UTC

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.

I think a bigger concern than an exploit would be the possibility that another employee within the organization, who has access to view the source code, might take advantage of the keys to do something unwanted.

In every company I've worked for, there's been much less stringent security applied to viewing scripts than to other activities like logging in to databases, launching scripts to live websites, etc. In the corporate world, lazy server administrators often give temps and low-level employees access to much more information than they need or should be able to see.

Before you even worry about some hypothetical software flaw whereby a user might view your script over the Internet, think carefully about restricting the set of people in your company who might have unfettered access to whatever keys or other sensitive information you're hoping to conceal.

--Kevin

[reply]