Thycotic Telephone Number +1-202-802-9399 (US)
The Lockdown

Thycotic’s Cyber Security Blog

Stop storing cleartext credentials in the registry for Point of Sale systems

Written by Thycotic Team

November 30th, 2017

Do you want to enable auto logon 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 unsecure way?

Well, Thycotic’s Secret Server has the answer, with complete automation, and without storing credentials in cleartext.

Let’s talk about how auto logon works, why it’s not recommended in most cases, and how to securely do it.

In this post:

How does auto logon work?

When is it needed?

Security Concerns:

So, what are my options?

Secure Auto logon

Secret Server’s Advanced Scripting

Conclusion

How does auto logon work?

Auto logon is 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 logon is fundamentally insecure. However there are ways to secure it when enabling that feature is needed.

When is it needed?

At Thycotic, 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 logon 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 logon 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 logon account. The complexity and fear of breaking these machines makes it hard to rotate these passwords periodically, which in turn increases the risk of compromise.

The auto logon 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 logon is desirable because it’s easier to manage, secure, and revoke.

So, what are your options?

Secure Auto logon

Microsoft provides the ability to secure auto logon credentials by using LSA secrets in the registry. These encrypted values hold passwords for service accounts and whatnot, and can handle auto logon 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 logon 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 accidental reveal.

Conclusion

Auto logon 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 logon passwords with little user intervention, and no third-party tools required!

IT Security should be easy. We’ll show you how.

Try Secret Server and experience how FAST & EASY
IT security products can be.

 

Like this post?

Get our top blog posts delivered to your inbox once a month.

SHARE THIS


The following two tabs change content below.

Thycotic Team

We deploy smart, reliable, IT security solutions that empower companies to control and monitor privileged account credentials and identities.