Encryption of "shared secret" database column

[Transistor]

I’m creating a Perspective password database application for use by controls engineers, electricians, mechanics and various other bodies in our factory. The idea is that we have a central repository for all our passwords (HMI user levels, etc.) and that they don’t get lost when someone leaves or if I don’t need it for years, etc. It will be on our intranet only. Access will be by Active Directory login via Ignition and which passwords are revealed will be controlled by Ignition user role.

My question is, “What is a sensible way to encode / encrypt / obfuscate the password column in the database?”.

For this application the actual passwords need to be decoded on retrieval. That means that one-way encryption is not an option and I’m aware of the resultant security risks. We have multiple Ignition administrators and developers with access to the gateway and to the database.

Can anyone suggest a suitable way of doing this or ideas for where or how to store the encryption key to make it difficult to decode the whole table. In the working environment we’re unlikely to have internal rogue actors and the general purpose of the application is to centralise password storage in a way that the users can retrieve passwords based on their Ignition role.

To put things in context, this will be a step above folks writing the passwords on the back of the HMIs!

Thanks!

[JordanCClark]

Best practice for an API key

If anyone’s interested in learning a bit about Java development, you can refine this proof of concept I just whipped up: It adds a new section to the config page of the gateway that lets you define named secret values, and then (within the gateway scope) you can run system.secrets.getSecret(<name>) to retrieve the un-encoded value.

[ryanjmclaughlin]

@Transistor

Can anyone suggest a suitable way of doing this

Sure this is possible, but this is the type of thing that has burned us in the past using Ignition too far outside its core purpose. Maintenance and security over time become and issue... Yes you can, and its cool, but an enterprise lastpass or 1password account is has much better security and will do what you need out of the box, plus the IT security gods will thank you.

Enterprise Password Management Solutions - LastPass 

[bmeyers]

SQL Server Column Level Encryption Example using Symmetric Keys

I don’t agree with the concept of a password database application because there are so many holes in the system that need plugged but if you want to encrypt a database column this is a good way to do it.

Having the password on the HMI is better in some sense because you know only a person with access to the plant could have accessed the HMI. As soon as you have a database of passwords and a remote connection you don’t know what actor is remoting into your system(s).