Steve Sapovits wrote:
Maxim Sloyko wrote:
I don't think this solves the problem, because what I usually want is
the user to be able to use the application, but unable to see the DB
password. So the user should have "read" permission set for the file,
but on the other hand he shouldn't. It's not not a problem for Web
App, though.
Storing passwords encrypted, decrypting before using doesn't cover this?
I've played around with Crypt::CBC (and different ciphers) for this sort
of thing but admittedly have not applied this to any production systems
yet. You still have a key somewhere to hide/obscure. You can also use
Perl source filters to totally encrypt the source -- something else I've
done but not in production. Just some things you may want to look at ...
Well, I mostly do Web apps, so it is not a problem since user can't see
code. If the user can see the code, can find a password int it and
understand what password is this, then there is no way encryption can
help much (storing keys etc. as you pointed it out.), because this kind
of user can figure it all out, if he wants to.
But this is not the point. The point was that usage of some file with
passwords by *DEFAULT* is not the way to go, IMHO. It raises more
problems than it solves.
--
Maxim Sloyko
