0

My infosec officer is campaigning the use of client process-based authentication everywhere applicable for future and existing projects. For existing projects, especially for custom applications, this entails non-zero cost, not to mention potential service interruptions down the road. Therefor I need to understand as much as possible on the benefits and drawbacks.

Here's my perception of what client process-based authentication is:

The authentication process requests client process credential which is usually sent along with initial connection establishment. The server then do authentication checks based on this credential. The credential here is usually the OS assigned process owner ID.

This is all done without requiring the client process to collect additional username/password either from enduser input or from some stored setting. This means less secret laying around in some config file or in the environment which is desirable.

Storing secrets in files are often strengthened by obfuscating or symmetrically encrypting the entire file or just the piece of credential. Another common trope is to embed the obfuscation key or decryption key in the application code.

The question is: Is client process-based authentication is demonstrably more secure than storing (encrypted) credential in files?

Additional information: My network is small sized single site network with 200+ workstations and another offsite data center. All business applications runs on the data center. We have a primary directory server (a Microsoft AD)

Edit: I may be using incorrect term here with 'process-based authentication'. I do not know better term for this so perhaps some example taken from my environs can better describe what I mean.

  • A web application written using ASP.NET needing to connect to MSSQL Server database would need authentication credentials. Here, we can take two approach. 1) Configure the database to accept username and password. Then, configure the web app to load these credentials from a configuration file and then use it to connect. OR 2) Configure the database to accept 'integrated security' authentication using certain user id. Configure the web server to run the web app under that user id. Configure the web app to connect using 'integrated security' mode. No username and password needed.

  • Another example, when you attempt to connect to MySQL server using MySQL default client from the command line, without supplying username and password, MySQL client will use it's current process's user id as the default credential to be used when negotiating authentication with the server. When the server is properly configured, the client can connect without prompting user for username and password.

4
  • This feels like it would be easy enough to spoof if proper protection is not in place
    – belkarx
    Mar 22 at 4:15
  • 2
    I honestly have never heard of client process-based authentication. Do you have any reference architecture or white paper on the subject? Or do you mean client authentication using digital certificates? Mar 22 at 4:57
  • 1
    This is a little difficult to understand, and it seems like a thing that you want to make and not something that already exists. Is that right? Also, let me try to rephrase the question. Are you asking "is authenticating a user based on the OS process ID more secure that a user ID and a shared secret?" ? If so, then secure from what? And if my rephrasing is correct, how is a process ID, which would be exposed to all users, more "secure" than an encrypted stored secret??? You're replacing an encrypted value with a plain text value because someone "might" break the encryption...
    – schroeder
    Mar 22 at 9:36
  • I may not be using the proper term here with 'client process-based authentication'. I have added some exemplary cases I could find in my network. I hope it can clarify what I meant.
    – bluearth
    Mar 23 at 2:28

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.