List:General Discussion« Previous MessageNext Message »
From:Paul DuBois Date:June 30 2000 11:48am
Subject:RE: ENCODE/DECODE encryption methods..
View as plain text  
At 1:31 PM +0200 2000-06-30, Carsten H. Pedersen wrote:
>  > -----Original Message-----
>>  From: Paul DuBois [mailto:paul@stripped]
>>  Sent: Friday, June 30, 2000 6:30 AM
>>  >
>>  >I think you have a misconception here, because you can specify a
>>  username from
>>  >the connection  code in the web script you can  provide different levels
>>  >security on the web, in fact the user nobody (apache) can be
>>  disallowed all
>>  >access to the database. This puts some work on the DBamins plate
>>  but it is
>>  >possible to say accounting can only write scripts that will  only access
>>  >billing records in the DB, while the customer rep programers can
>>  >have access to
>>  >more sensitive information.
>>  I don't see this.  Accounting can write scripts that read the customer
>>  rep programmers' scripts to find out their password.  The Web server has
>>  to be able to read everybody's scripts, so if you can write a script,
>>  I can write one to read your script.  You can write a script that accesses
>>  a file outside the Web tree containing the connection password, but I can
>>  still write a script to read that file.
>>  I don't see any security in this at all.
>Why would the password need to be stored on the machine? There are many
>other places you could store a password (heads of users being a good
>starting point).

The text above says "you can specify a username from the connection code".
I took that to mean "in the code of the script" and was simply pointing
out that all scripts the Web server can run must be readable by the Web
server uid.  That means you can't hide passwords in your scripts, for
example, by making the script readable *only* by the Web server; I wanted
to point that out in case someone thought otherwise.

>Yes, it would be more cumbersome for users to enter a password each
>time they access the db / start a session / whatever granularity you
>choose. But implementing security usually is, and is certainly always
>a matter of judging useability/accessability versus security.
>Yes, it will require quite a bit of skill on the part of the
>webadmin/dbadmin. But programming for security *is* difficult and
>there is never an easy way.


Paul DuBois, paul@stripped
Re: ENCODE/DECODE encryption methods..Dennis Gearon29 Jun
  • RE: ENCODE/DECODE encryption methods..Daevid Vincent29 Jun
    • Re: ENCODE/DECODE encryption methods..Michael Meltzer29 Jun
    • Re: ENCODE/DECODE encryption methods..John Cichy29 Jun
      • Re: ENCODE/DECODE encryption methods..Paul DuBois30 Jun
        • RE: ENCODE/DECODE encryption methods..Carsten H. Pedersen30 Jun
          • RE: ENCODE/DECODE encryption methods..Paul DuBois30 Jun
      • RE: ENCODE/DECODE encryption methods..Daevid Vincent2 Jul
    • Re: ENCODE/DECODE encryption methods..sasha30 Jun
      • RE: ENCODE/DECODE encryption methods..Daevid Vincent2 Jul
        • Re: ENCODE/DECODE encryption methods..Rolf Hopkins3 Jul
    • Re: ENCODE/DECODE encryption methods..Benjamin Pflugmann30 Jun
    • Re: ENCODE/DECODE encryption methods..Dennis Gearon30 Jun
RE: ENCODE/DECODE encryption methods..Mark E. Rolen30 Jun
  • RE: ENCODE/DECODE encryption methods..Carsten H. Pedersen1 Jul
  • RE: ENCODE/DECODE encryption methods..Jeremy Cole2 Jul
RE: ENCODE/DECODE encryption methods..Ben Gollmer2 Jul
  • Re: ENCODE/DECODE encryption methods..Michael Meltzer2 Jul
    • RE: ENCODE/DECODE encryption methods..Robert Goff5 Jul
    • RE: ENCODE/DECODE encryption methods..Daevid Vincent5 Jul
      • RE: ENCODE/DECODE encryption methods..Robert Goff6 Jul
Re: ENCODE/DECODE encryption methods..sasha2 Jul