I am trying to find the smartest way to handle the root password in my product.

For legacy reasons, I need to have a technical account. My services create a token associated with this account directly in the DB to authenticate and access the rest of the platform. I tried to find some documentation online to make sure I was dealing with its password in the most secure way but could not come up with a straight answer.

Here are the two solutions I came up with:

  • Set the password to a random string at every boot of the server, log it to the console in case we actually need it one day

  • Pass it as an environment variable TECHNICAL_PASSWORD and set it at every boot to make sure it is always up to date

Note that the password is never used so I don't technically need to know it.

In terms of good practice, what would you advise?

  • If its only needed for service access rather than physical login you could use a NULL password and make sure your system does not allow login of users with this? I would add a physical NULL check rather than assuming the user has no way of submitting NULL to the application to avoid future changes opening up an exploit. Alternatively add an explicit flag to disable users for physical login (also useful for disabling users without deleting them). – Hector Apr 6 '18 at 11:03
  • Yes, definitely did not think about that one. However, the framework below does not support such case. – cadesalaberry Apr 6 '18 at 12:00
  • What happens if you set the password to NULL in the DB? And why couldn't you use a module or hook into the login method to enforce the null check (if it doesn't already exist) - something like this github.com/AbdoulNdiaye/loopback-mixin-complexity – Hector Apr 6 '18 at 13:32

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.