Re^3: Secure ways to use DBI? (do use external config and middle-tier)

in reply to Re: Re: Secure ways to use DBI?
in thread Secure ways to use DBI?

the CGI is executed, and is not available in plain text.

Yes - so long as the configuration is correct and doesn't have to be touched. But these things do happen, and it would not exactly be a housewarming gift to have the username/password visible in plaintext to the entire world after a server move. In contrast, it is slightly more likely that an external file containing the credentials will initially have too restrictive rather than too permissive access privileges.

the SQL server should be configured to limit the abilities of the account hard-coded into the CGI

Ah, but that's what it makes sense to use a middle-tier for: you gain much more finegrained control over the submitted queries than the access control facilities of the database server typically allow. DBI::ProxyServer f.ex enables you to only make some predetermined queries against the proxied database available. This at least severly limits, if not outright eradicates a miscreant's ability to gather information to prepare an attack with.

Makeshifts last the longest.

Comment on Re^3: Secure ways to use DBI? (do use external config and middle-tier)

Replies are listed 'Best First'.
Re: Re^3: Secure ways to use DBI? by MarkM (Curate) on Apr 18, 2003 at 04:26 UTC
To some degree, the only thing being offered is obscurity. Eventually, a password ends up being stored somewhere. Whether it is in the CGI, or behind the scenes in a 'proxy server', the password is available. If somebody wants the password, they will eventually get it. I wish MySQL provided an authentication scheme based on some other sort of credentials than a password. The whole concept of a password is wrong when it comes to automated tasks. In any case, I am merely warning that some commonly accepted security techniques are not security techniques at all, but rather, sophisticated evasive attempts at misdirection. How much effort is it worth, when the mere sophistication involved guarantees that the programmers who will maintain the system in the future understand it less, and may completely unintentionally violate the scheme in such a way as to make the system more open after than before.	[reply]

Replies are listed 'Best First'.

Re: Re^3: Secure ways to use DBI?
by MarkM (Curate) on Apr 18, 2003 at 04:26 UTC

To some degree, the *only* thing being offered is obscurity. Eventually, a password ends up being stored *somewhere*. Whether it is in the CGI, or behind the scenes in a 'proxy server', the password *is* available.

If somebody wants the password, they will eventually get it. I wish MySQL provided an authentication scheme based on some other sort of credentials than a password. The whole concept of a password is wrong when it comes to automated tasks.

In any case, I am merely warning that some commonly accepted security techniques are not security techniques at all, but rather, sophisticated evasive attempts at misdirection. How much effort is it worth, when the mere sophistication involved guarantees that the programmers who will maintain the system in the future understand it less, and may completely unintentionally violate the scheme in such a way as to make the system more open after than before.

[reply]

In Section Seekers of Perl Wisdom