# How are Vision Auto-Login Credentials Stored **URL:** \ **Category:** Ignition\ **Tags:** vision, ignition81\ **Created:** [June 13, 2022, 4:52pm UTC](https://forum.inductiveautomation.com/t/how-are-vision-auto-login-credentials-stored/60701 "2022-06-13T16:52:27Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![zacht](https://avatars.discourse-cdn.com/v4/letter/z/ea5d25/32.png) [@zacht](https://forum.inductiveautomation.com/u/zacht)\ **Post date:** [June 13, 2022, 4:52pm UTC](https://forum.inductiveautomation.com/t/how-are-vision-auto-login-credentials-stored/60701/1 "2022-06-13T16:52:27Z")
Prior to Ignition V8.1.17 we used the Enable SSO option to launch vision projects without any authentication visible to our users. When we update we are considering switching to the Auto-Login option and have some questions. I believe the Auto-Login option for vision projects should step around the SSO security concerns, [https://support.inductiveautomation.com/hc/en-us/articles/5979279808397-Active-Directory-SSO-Disabled-for-8-1-17-7-9-20-](https://support.inductiveautomation.com/hc/en-us/articles/5979279808397-Active-Directory-SSO-Disabled-for-8-1-17-7-9-20-) Is this assumption correct? Does Auto-Login introduce any security concerns of comparable severity? (We’re fine with users being able to access these vision projects if they have access to our network but don’t want to open up arbitrary remote code execution, for example). We are considering using accounts back-ended in an AD User Source. IT is understandably concerned about AD account credentials staying secure, even for low permission users. Once input into the project properties, how are these credentials stored? Related to the SSO vulnerability, the technical advisory specifies that “So long as you know the username of any user with privileges to access the Designer, you can log in as that user into the Designer without having to supply their password.” What are the security implications of re-enabling SSO in ignition.conf but disabling Allow Designer SSO? (Effectively allowing SSO to vision clients but not to the designer.) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/5/1590ba730a83357254c3f1675da103d92624f4fb.png) Thanks for taking the time to read through my wall of text 🙂 ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [June 13, 2022, 5:20pm UTC](https://forum.inductiveautomation.com/t/how-are-vision-auto-login-credentials-stored/60701/2 "2022-06-13T17:20:39Z")
> [@zacht](#): > > Does Auto-Login introduce any security concerns of comparable severity? No, you're correct; there's obviously a tradeoff of security vs convenience, but auto login doesn't expose the SSO vulnerability. > [@zacht](#): > > Once input into the project properties, how are these credentials stored? They're stored (unencrypted, unobfuscated beyond Java serialization) in the Vision login properties project resource. What you could do is switch your project to an Internal user source configured for soft failover to your actual AD user source. Thus, the auto-login credentials can be invented and _only_ apply to Ignition/your Vision project(s), and you can still log in with your AD credentials when appropriate. > [@zacht](#): > > What are the security implications of re-enabling SSO in ignition.conf but disabling Allow Designer SSO? Basically, just that anyone could authenticate (as a Vision client) from anywhere as long as they know your domain and a valid username to impersonate. This is essentially the same tradeoff as autologin, but harder to control. ---
**Author:** ![zacht](https://avatars.discourse-cdn.com/v4/letter/z/ea5d25/32.png) [@zacht](https://forum.inductiveautomation.com/u/zacht)\ **Post date:** [June 13, 2022, 7:11pm UTC](https://forum.inductiveautomation.com/t/how-are-vision-auto-login-credentials-stored/60701/3 "2022-06-13T19:11:43Z")
Thanks for getting back to me so quickly, @paul-griffith. > [@paul-griffith](#): > > This is essentially the same tradeoff as autologin, but harder to control. By "harder to control" I assume you mean that anyone with Gateway Config Section access can flip Designer SSO back on. vs. `ignition.conf` can be accessed by a (potentially) much smaller group of people. Did I understand you correctly? Is there any hope of a new, more secure implementation of SSO being introduced in a future version? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [June 13, 2022, 7:17pm UTC](https://forum.inductiveautomation.com/t/how-are-vision-auto-login-credentials-stored/60701/4 "2022-06-13T19:17:20Z")
> [@zacht](#): > > By “harder to control” I assume you mean that anyone with Gateway Config Section access can flip Designer SSO back on. vs. `ignition.conf` can be accessed by a (potentially) much smaller group of people. Did I understand you correctly? That, and also, with autologin everyone's going to show up as one user in e.g. audit trails. With SSO enabled, anyone _could be anyone_; you lose any guarantee of 'trust' in authentication in the system. > [@zacht](#): > > Is there any hope of a new, more secure implementation of SSO being introduced in a future version? Yes, it's definitely on our radar. However, we need to do it "right", especially with an eye toward "future-proofing" (e.g. cloud based stuff, mutual auth based on certificate sharing, etc). ---
**Author:** ![cesrom](https://avatars.discourse-cdn.com/v4/letter/c/ea666f/32.png) [@cesrom](https://forum.inductiveautomation.com/u/cesrom)\ **Post date:** [June 13, 2022, 7:52pm UTC](https://forum.inductiveautomation.com/t/how-are-vision-auto-login-credentials-stored/60701/5 "2022-06-13T19:52:46Z")
On the [Security Best Practices for Your Ignition System](https://inductiveautomation.com/resources/webinar/security-best-practices-for-your-ignition-system) Webinar, I asked a question about SSO and the answer I got was: > The feature as we know it today will likely never come back in its current form, and it will likely be removed altogether. But down the road [Inductive Automation] plans on investigating how they may introduce Kerberos support, which would give users a more secure Industry-standard method for achieving the same Desktop SSO experience. Listen to the Webinar recording starting @ 31:27. > **[Security Best Practices for Your Ignition System](https://inductiveautomation.com/resources/webinar/security-best-practices-for-your-ignition-system)** > > Cybersecurity is a moving target. The techniques and technologies of yesteryear won’t necessarily protect your system in this highly interconnected era of IIoT-enabled systems. As attacks on industrial control systems become increasingly commonplace,...