Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Re: Re: Cryptography Best Practices

by dws (Chancellor)
on Nov 11, 2002 at 22:07 UTC ( [id://212113]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Cryptography Best Practices
in thread 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).

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://212113]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-03-28 17:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found