-2

At work there is a given task where a python application is currently running on a server, this application is using a enviorment file, which has username and password information. The current ask is to encrypt the username and password string such that only application is able to decrypt the username/password and use it to run the application. Is this possible or is there some type of industry wide best practice we can adopt at this juncture.

2
  • why is anyone downvoting this question ? – Vaibhav Chauhan Mar 1 at 21:21
  • 1
    I suppose you need to provide more specific information about your environment. But, if you want to look up solutions for yourself, the general term is "protect secrets" or "protecting secrets". If you use that as a search term, with your environment, you might find answers on the web. Or you can make this question more specific. – davidbak Mar 1 at 21:23
2

There are a couple of accepted practices.

  1. The old way. Use the OS to manage the user, run your program as an OS user. Let the OS manage the password safety ie windows service/IIS app pool/Linux... whatever

  2. The new way. Use a configuration/service mesh such as Consul/Nomad every service gets TLS and authentication pushed out to it and centrally managed + various dns and gateway trickery

  3. Various off the shelf products that essentially automate 1

  4. Lock down the boxes and deploy plain text user/pass via a deployment tool which securely stores the info. Here the security boundary is the box, so you don't let anyone log onto it except the deployment system, on which you implement your security.

  5. Boxes get SSL keys that authenticate whatever is running on them. You can get the username/pass, but it will only work from that box. Limiting the problem.

Bad ways that people do anyway

  1. Two way "encrypt" the username/password. Bad because, if the attacker can read the config then they can presumably read the program files as well and hence decrypt the config.

  2. Have some central user repository that the box connects to to get the latest password. Obviously the box needs authentication in order to connect to the central location, so once an attacker has that they can retrieve any password they like.

Overall, you are trying to limit your risk and attack surface. A plain text password in config isn't necessarily bad, as long as have other security layers in place.

For example your API has the database password. but

  1. The box is secured, no one can log on and read the file
  2. The firewall only allows database connections from the API boxes
  3. The db user is specific to the APIs database
  4. The database user only has permissions needed by the API
  5. The password changes often

Now if the password leaks, an attacker still has to breach the other security ontrols before any information leaks.

The main thing you are trying to protect yourself from with these service passwords is internal attackers, or more probably, internal breaches of various data protection legislation audits.

ie. sysadmin team have root access to box, box has plaintext db password, sysadmin can connect to db, password never changes.

You fill in the "who has access to personal information on the DB" question on your audit as "no-one", but when you check the log you see the sysadmin logs in with the service user all the time to do maintenance because "everyone knows it".

"That will never happen because we rot13 the password" will probably satisfy the auditor and your risk register, but it's obfuscation rather than security.

2
  • after looking at the comments by I have following plan in mind, please correct me if this is an acceptable way of doing things. as this application is run by a dedicated user, say app-user I plan to have an environment variable which stores db_password and app can access these values when app is invoked to run. to further harden, can we disable shell login forapp-userso that no user can login and have access to these env variables ? OS: redhat 8 application codebase: python3 – Vaibhav Chauhan Mar 3 at 3:55
  • I guess that hides it from the person deploying the application, but if the app runs as a user why not give that use access to the db rather than having a second user/pass – Ewan Mar 3 at 16:31

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.