5

I'm developing a PHP application (PHP 7.3) for my company, which will be hosted in our own servers. For now it will only be accessible from within the network but eventually will be opened to the web.

The IT department is going to give me a "service" user whose password won't expire (so all the services for both the servers assigned to me and the app itself will keep on running forever) but they don't want that user's password to be stored in plain text anywhere in the server. To do that, the System Admin will have to input the password through a Remote Desktop Connection every time we need to make changes to the server services or such but I also need PHP to use that user's password constantly to access other resources on the network (LDAP server, other DBs, MS SQL DB and so on).

What I thought might work is:

  1. Having the password encrypted in a plain text file above the root folder of the PHP application
  2. Having a key in another plain text also above the root folder of my app but in a different folder
  3. Having a cypher in another file or maybe in my main configuration PHP file

Does this make sense? Or maybe I could also have the key encrypted and another key in a file to decrypt the first key?

I'm very new to encryption so any explanation or link will be very much appreciated.

migrated from crypto.stackexchange.com Sep 2 at 15:07

This question came from our site for software developers, mathematicians and others interested in cryptography.

0

You certainly shouldn't keep the file on the system in any folder that could be publicly accessible, as misconfigurations etc. could lead to the password being exposed.

Keeping the key on the server, even in an encrypted format, won't work either as you will need to decrypt it for use with PHP, so it will exist somewhere on the server in decrypted format, even if it's just in memory, which sounds like it falls foul of your admin's request. Since there are other resources available, you could ask IT to make an API available on the network which will act as a gateway to the other services you require access to.

For a real world demonstration you can look at how it has been implemented in the cloud in AWS infrastructure (via their 'Secrets Manager' service) or Azure's 'Key Vault'.

0

I'm a bit confused by «The IT department (...) don't want that user's password to be stored in plain text anywhere in the server. To do that, the System Admin will have to input the password through a Remote Desktop Connection every time we need to make changes to the server services», an I think the gist of the problem lives previsely there.

It's quite normal to have service accounts with no expiry for applications. This account (or accounts) should be limited just to the resources they need access to.

This password could be stored in plaintext inside a configuration file (I don't think it's a problem, really), or be slightly hidden with some encrypted-with-a-key-somewhere-else obfuscation (what you suggest). In both cases, an attacker with whole access to the system (even just www-data), would be able to get hold of the key.

However, the fact that it is mentioned the System Admin would input the password through RDP every time, makes me think this would not fulfill waht your IT department is expecting. Note that with such approach, there would be no need to ever enter the passphrase more than once.

So you should clarify with your IT department how they want the password to be stored and used, and then proceed accordingly. Maybe they are fine with this approach. But they might be adamant that the password may not ever hit the disk (not even in encrypted form), and you would need to keep in memory at all times. Perhaps they didn't consider that you would need to bind many times to the AD. They might prefer to generate a separate account for accessing the LDAP and databases...

You may be able to make it work by having the credentials stored only in memory by a trusted process, and it may suffice for it to pass the in-memory secret (password) to another process, or it could need to perform the bind/login itself on behalf of the app. It may also be possible to use a kerberos token for the application access (but note it would have to be renewed periodically!).

Your Answer

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