Do you want to enable auto-login on your PoS systems without compromise?
Do you need to enable auto-logon for a seamless buying experience for your customers, but you’re doing it in an unsecured way?
Well, Delinea's Secret Server has the answer, with complete automation, and without storing credentials in cleartext.
Let’s talk about how auto-login works, why it’s not recommended in most cases, and how to securely do it.
How does auto-logon work?
Auto-login is a convenience feature in Windows that’s considered a security risk. It leverages Registry values in the Winlogon subkey to define a default username, domain, and password for an account that will be automatically logged in when Windows starts.
These values are stored in Cleartext in the Registry, which means anyone with access to the machine can read that Registry value as per Microsoft: “The specific registry key that stores this value can be remotely read by the Authenticated Users group.”.
So, we’ve established that auto-login is fundamentally insecure. However, there are ways to secure it when enabling that feature is needed.
When is it needed?
At Delinea, we’ve observed that clients in the hospitality and retail business make use of the auto-logon feature for their PoS and PoO systems, but that’s certainly not limited to these industries.
Typically, these systems run on Windows embedded as the operating system hosting the PoS application installed. The use case is: the PoS machine needs to be restarted for whatever reason; upon restart, it should go straight to Windows, and then load the application so customers can pay/checkout their orders.
That can only happen if Windows is able to automatically logon, thus we use Auto Logon.
Security Concerns
The most glaring security concern is that the password is stored in cleartext in the registry. This allows anyone with read access to the registry to retrieve the ACTUAL password, not the hash.
Often, the auto-login account is granted local admin rights. The need is debatable, but based on previous experience I found that it’s not required in most cases.
Another security concern is that often the password for the auto-login account is never changed. Due to the complexity of pushing the same password to several thousand machines, admins dread changing the password for the auto-login account. The complexity and fear of breaking these machines make it hard to rotate these passwords periodically, which in turn increases the risk of compromise.
The auto-login account can be a regular user, thus reducing your attack surface. It’s also worth noting that using a domain account instead of local accounts for auto-login is desirable because it’s easier to manage, secure, and revoke.
So, what are your options?
Secure Auto login
Microsoft provides the ability to secure auto-login credentials by using LSA secrets in the registry. These encrypted values hold passwords for service accounts and whatnot and can handle auto-login credentials as well.
When enabled and configured, Windows will check for the cleartext password. If it doesn’t exist then it will check the LSA secret and log the user in.
This method is more secure than just cleartext passwords for obvious reasons—the password is kept away from prying eyes, and you would require elevated credentials to view it.
Unfortunately, this method isn’t available with OOB or with a simple click. Often, it requires the use of Sysinternals AutoLogon.exe, Logon Expert (paid), or PowerShell and C#. And it still doesn’t solve the question of “how can I automate this on every machine?”
Secret Server’s Advanced Scripting
Secret Server can automate password changes and propagate passwords to several dependencies running across your network. Even better, it has a scripting engine that takes PowerShell, SQL, and SSH scripts to extend its native capabilities beyond what’s offered out the box.
Using a feature called Discovery, Secret Server can discover auto-logon credentials in your environment, which is a great way to report on what’s out there. It can then import these findings and convert them into managed Secrets. Those managed Secrets will be a Service Account type that has the auto-login credentials as dependencies.
And that’s not all. Now, when you need to change the passwords for your service account and propagate those changes across devices with auto logon, it can be done with just one click
Secret Server will change the password on the Active Directory/Local Windows account, and when that’s successful it will then turn to the dependencies. Each dependency will have the default cleartext password removed from the registry if it exists, and the new passwords pushed to the encrypted LSA secret on the registry. Passwords changed and secured from the accidental reveal.
Conclusion
Auto-login can be a necessary evil, but that doesn’t mean you should settle for subpar security, and increase your chances of being breached. Secret Server offers an end-to-end method of finding, securing, and changing auto-login passwords with little user intervention, and no third-party tools required!
IT security should be easy. We'll show you how
