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 SloykoThread Previous | Thread Next