in reply to Re: Securing your scripts on webhoster's server
in thread Securing your scripts on webhoster's server

I pick a host where suExec is in force. That permits me to make best use of unix filesystem permissions for security. Nothing needs to be world-readable.

I have heard of this approach before, but always wonder: if your script uses suExec, why couldn't mine do the same to get to your files?

Update: I got suEXEC and sudo confused :(

User passwords don't need to be stored. Standard practice is to store a digest of the password, and compare the digest of the offered password to authenticate.

Very true for user accounts stored in a database, but you still need to connect to the database daemon, in order to check the digests, and thus you need to store a password somewhere, or have numerous accounts with read access on the database daemon itself, which might be a problem, when you have an account on some webhoster's machine.

Update: I'm more interested in limiting other users on your system from altering your database, than limiting them from "stealing" passwords of users on your website.

--
b10m

All code is usually tested, but rarely trusted.
  • Comment on Re: Re: Securing your scripts on webhoster's server

Replies are listed 'Best First'.
Re: Re: Re: Securing your scripts on webhoster's server
by Zaxo (Archbishop) on Jan 31, 2004 at 22:27 UTC

    SuExec causes your [cgi] script to run with your uid. Other users' will run under theirs. They cannot 'donate' a snooper [or clobber] script to your uid because chown to another user is a privileged operation.

    [If you give your db password-containing module 0600 permissions, nobody can see inside but root and you.]

    After Compline,
    Zaxo