('binary' encoding is not supported, stored as-is) In-Reply-To: <4ABF0315D817AB4EAD6224C31961A08C01276DC4at_private> <snip> >The web application generally doesn't need access to workflow states, >revision histories, etc. In other words, for a public-facing application, >you should be comfortable if that application's back-end or database ID's >had no passwords to begin with. If you feel that this approach would >compromise the security of your application, then you might want to look >into why that is (maybe you have too much business logic in your >presentation layer, for instance). </snip> I disagree in part. The very fact that the security credentials have to be stored on the filesystem to me, means that there are two possible issues - (a) a breakin at the web layer could lead to a comprimise of the data withint he database. (b) connections to the database could be made from inside the enterprise, pending firewalls etc. > >With that issue addressed, securing the application's credentials becomes >less of a worry. You have to assume that if someone can break into your >server and take control of it, the intruder can do everything that the >application can do, including pulling credentials off of a separate LDAP >database and using those to further their interests. While you can put >speed bumps in their way by using SSL-encrypted LDAP sessions, stashing >credentials directly in binaries, etc., I don't know that those solutions >are going to buy you much more in the way of security. I accept that this may be the case for web applications per machines. What if I have two separate applictions running on the same physical box, one uses very highly sensitive database the other does not. How can I authenticate the two processes without resorting to basic user id's and passwords being stored on the filesystem? > >Though continuing on this trend, any sensitive traffic from your DMZ servers >to your back-end systems should be SSL encrypted anyway, where "sensitive" >includes traffic with usernames and passwords in any form. Sometimes the >simplest way of approaching all of this is through the use of SSL >certificates, authenticating *both* ends of a session. If you're going to >use SSL anyway, why not use an authentication system built into SSL? (This >includes access to databases, LDAP, etc.) And always keep in mind that >you're just authenticating the system, which could always be under the >control of someone else. The use of SSL on database connections is considerably high. I am not so worried about passive attacks. I am wondering if there are any frameworks that exist such that when I take code and run this in production it can authenticate against a directory service, and obtain permission to access resources. I can take the same code run it on the DEV box and intrsically connect to the DEV database systems. It's much like Kerberos for applications to authenticate against applications. What my requirements would be is that the code itself could identify where it was being executed. This information is passed to the directory service and the directory service gives the necessary credentials to access resources in that environment. The problem is, the application needs to authenticate to the directory service. Using certs just binds all applications, potentially, at teh physical machine layer, not at the application layer. And accordingly, we are left with storing passphrases on the file system. Any other comments would be great? Cheers r1. > >My two cents, at least. > >David > >
This archive was generated by hypermail 2b30 : Fri Jan 31 2003 - 11:00:34 PST