Tag: password

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.