-----Original Message----- From: r s [mailto:richard.scottat_private] Sent: Friday, 31 January, 2003 10:11 To: secprogat_private Subject: Re: Application to Application authentication models.... > 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 Either you have to store the real credentials on the server, or you have to store credentials to obtain the real credentials. Either way, an attacker, with sufficient time and resourcefulness, get into and do anything that your application can do. Once you accept that, adding complexity will undoubtedly slow an attacker down (and perhaps stop a less resourceful one), the expense here is the added complexity (which impacts efficiency and stability), so it's a trade-off. And mainly my point was more towards the case of a public-facing application, with no aspects of that application dealing in sensitive information. When you do have to worry about sensitive information, you should definitely take whatever steps (as above, and as you suggest) to place every kind of speed bump you can in the face of an attacker. But again, once he has control of your server, you have to assume that he can do anything and everything that any process running on that server can do. > 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? Again, you gotta have *something* on the filesystem, or in some way accessible to the application, in order for it to remember it when it needs to start up. Whether that's an SSL certificate (which could still work on connections to/from the same system; the application would just need to validate using more information), a username and password, or some other key. > The use of SSL on database connections is considerably high. I am not so Yah, it is, but in some configurations still very necessary. Your configuration may not warrant it. > 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? Yah, understood. I'm not aware of any industry standard mechanisms to do what you're describing. In my experience, each "tier" would just come pre-configured (on the filesystem) with the credentials it needs to access non-sensitive data. This would generally be independent of the code, so you would deploy from one tier to the next, and each application would utilize the centralized credentials. Access to sensitive data would be done either via SSL certificates to a back-end content system, or in some cases, just proxying SSL credentials from the user agent back. All of these credentials would be stored on the local filesystem, with proper permissions to restrict access to the user the applications run as. I personally don't see much value in storing the credentials elsewhere, since this just requires credentials to obtain the credentials be stored on the filesystem as well. It's just a small speed bump. I would certainly be intersted in hearing comments from others, though. This is certainly an issue that most of us have to deal with. I'm curious to know how others approach this as well. David
This archive was generated by hypermail 2b30 : Fri Jan 31 2003 - 13:01:54 PST