# Encryption of "shared secret" database column **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [August 13, 2022, 8:18am UTC](https://forum.inductiveautomation.com/t/encryption-of-shared-secret-database-column/62977 "2022-08-13T08:18:08Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [August 13, 2022, 8:18am UTC](https://forum.inductiveautomation.com/t/encryption-of-shared-secret-database-column/62977/1 "2022-08-13T08:18:08Z")
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! ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [August 13, 2022, 9:55am UTC](https://forum.inductiveautomation.com/t/encryption-of-shared-secret-database-column/62977/2 "2022-08-13T09:55:25Z")
> [@Best practice for an API key](https://forum.inductiveautomation.com/t/best-practice-for-an-api-key/36088/7): > > 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(\) to retrieve the un-encoded value. ---
**Author:** ![ryanjmclaughlin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryanjmclaughlin/32/4318_2.png) [@ryanjmclaughlin](https://forum.inductiveautomation.com/u/ryanjmclaughlin)\ **Post date:** [August 13, 2022, 1:50pm UTC](https://forum.inductiveautomation.com/t/encryption-of-shared-secret-database-column/62977/3 "2022-08-13T13:50:26Z")
> [@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 ](https://www.lastpass.com/solutions/enterprise-password-management)** > > Our enterprise password management solution unifies security controls, user and group management, federation, and more into an all-in-one interface that is easy and simple to use. Add on SSO and advanced MFA for full control over enterprise identity. ---
**Author:** ![bmeyers](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmeyers/32/37453_2.png) [@bmeyers](https://forum.inductiveautomation.com/u/bmeyers)\ **Post date:** [August 13, 2022, 6:18pm UTC](https://forum.inductiveautomation.com/t/encryption-of-shared-secret-database-column/62977/4 "2022-08-13T18:18:21Z")
> **[SQL Server Column Level Encryption Example using Symmetric Keys](https://www.mssqltips.com/sqlservertip/2431/sql-server-column-level-encryption-example-using-symmetric-keys/)** > > Financial firms have sensitive data including credit card numbers, social security numbers, financial history, etc. Based on the sensitivity of the data, it needs to be secured and protected from unauthorized access. With data stored in tables, you... 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).