RE: Application to Application authentication models....

From: NESTING, DAVID M (SBCSI) (dn3723at_private)
Date: Fri Jan 31 2003 - 12:13:27 PST

  • Next message: Glenn_Everhartat_private: "RE: Application to Application authentication models...."

    -----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