# Database Connections' credentials encryption **URL:** \ **Category:** Ignition\ **Tags:** security, ignition81, database\ **Created:** [October 19, 2021, 1:55pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111 "2021-10-19T13:55:28Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![PrinceVade](https://avatars.discourse-cdn.com/v4/letter/p/f19dbf/32.png) [@PrinceVade](https://forum.inductiveautomation.com/u/PrinceVade)\ **Post date:** [October 19, 2021, 1:55pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111/1 "2021-10-19T13:55:28Z")
I found this post from awhile back: [Database user authentication password encryption](https://forum.inductiveautomation.com/t/database-user-authentication-password-encryption/10552) and I wanted to determine if this was still the case. If so, is there a way to control how Ignition stores these credentials? Thanks in advance. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 19, 2021, 2:13pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111/2 "2021-10-19T14:13:03Z")
That post isn’t about how Ignition stores DB credentials, but how the target DBs store user credentials. Ignition has to have these credentials in plain text or recoverable to plain text because it has to _ **supply** _ the password to the JDBC API. There is no other option. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [October 19, 2021, 2:45pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111/3 "2021-10-19T14:45:57Z")
Even if Ignition did encrypt your password, it would necessarily have to have the key to decrypt it as it can’t send a hashed password in a database connection stirng. If you are worried about database security- 1. Make sure Legacy DB Access is not on for your vision clients. This would mean you are using named queries everywhere, or are using a message handler to get datasets from a gateway function that is doing dyanmic sql and serving it to a client. This will help prevent SQL injection attacks. 2. Make sure your gateway logins are hard to guess. Especially important if your gateway is internet facing. 3. Make sure your database logins are hard to guess. Same rule applies. 4. Do NOT have Ignition login to your DB as root or sa, but as its own user with roles set for it by root (So that even if someone got into designer and tried to do DROP TABLE X; they would be denied because the Ignition user doesn’t have the privileges) 5. Good idea to keep your database on a separate machine usually, not only for performance, but if your Gateway machine is compromised, the attacker will not just get root access to your database for free for getting into your server that’s hosting your gateway. Databases are assets to a lot of companies and will stay around a lot longer than whatever the current front end you are using to interact with it is. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 19, 2021, 3:01pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111/4 "2021-10-19T15:01:49Z")
> [@bkarabinchak.psi](#): > > Even if Ignition did encrypt your password It does, and just as you describe. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [October 19, 2021, 3:03pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111/5 "2021-10-19T15:03:39Z")
> [@pturmel](#): > > Ignition has to have these credentials in plain text or recoverable to plain text Ah, good to know, this line made me think otherwise. ---
**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\ **Post date:** [October 19, 2021, 3:05pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111/6 "2021-10-19T15:05:17Z")
> [@bkarabinchak.psi](#): > > 1. Do NOT have Ignition login to your DB as root or sa, but as its own user with roles set for it by root (So that even if someone got into designer and tried to do DROP TABLE X; they would be denied because the Ignition user doesn't have the privileges) I think that point # 4 is important. You shouldn't be giving any system more access than they need. OTOH I work with a system that has had the sa password embedded in plain text in the HMI client code 😲 ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 19, 2021, 3:13pm UTC](https://forum.inductiveautomation.com/t/database-connections-credentials-encryption/52111/7 "2021-10-19T15:13:34Z")
> [@peter](#): > > > [@bkarabinchak.psi](#): > > > > 1. Do NOT have Ignition login to your DB as root or sa, but as its own user with roles set for it by root (So that even if someone got into designer and tried to do DROP TABLE X; they would be denied because the Ignition user doesn’t have the privileges) > > I think that point # 4 is important. You shouldn’t be giving any system more access than they need. This is mentioned in the [security hardening guide](https://www.inductiveautomation.com/resources/article/ignition-security-hardening-guide#step--protect-the-database).