Security Through Obscurity – What is it and When is it is OK to Employ it?
Security Through Obscurity is the practice of hiding vs securing. It generally conjures negative associations but when used strategically it could help to improve an organization's security posture.
Speak with any Pen-tester (Penetration Tester or Ethical Hacker) and they will tell you that their first order of business is to perform a process called Enumeration (Discovery of Devices and Services). You can't attack what you don't know about, so if attackers can't find it during enumeration they will focus on what they do find. Whereas a Pen-testers are paid to find avenues of attack and therefore will attempt more robust search and discovery techniques, attackers with malicious intent generally follow a more basic approach. Attackers usually focus on one, or a few, very limited vulnerabilities, where they expect the numbers game to play in their favor. That is why we are still seeing large numbers of attacks on RDP (Microsoft's Remote Desktop Protocol) and password spraying attacks in Office 365. Even though these attacks are well documented, as are their countermeasures, many companies assume they are too small to be targeted.
So how can Security Through Obscurity be deployed to effectively combat these attacks? We can start with authentication. Basic authentication today is thought to consist of 2 pieces of knowledge. A username and a password. It is well established that given the opportunity users will choose weak, easy to remember passwords. Thus, the focus of the security industry for the last decade or so has been to create mechanisms to filter weak passwords, create Multi-Factor Authentication (MFA) methods, and lately, the push towards password-less authentication altogether.
For clarity, I want to quickly derail and explain what password-less authentication is because it is a bit of a misnomer. Password-less authentication generally relies on a smartphone and a two-way verification of the user. The authentication screen displays a prompt which the user much interactively engage with. This interaction proves that the user is a human and a unique prompt at each login ensures that the user does not inadvertently grant access to an attacker. Password-less authentication abstracts (but does not entirely remove the password) the password remains a fallback method of authentication, albeit layered with a 2nd source of authentication such as a push to a phone or verification from a hardware token. The idea behind password-less authentication is a "web-of-trust". Web of Trust refers to the idea that new access can only be granted by persons or devices which have already been granted access, thereby expanding the web with the addition of each new device. This bridges the two biggest challenges in IT, Security and Availability. Traditionally the more available something is the less secure it is and vice versa. Despite its intentions, this technique has its own problems and is not the panacea it was originally thought to be.
So rather than push for password-less authentication or require Multi-Factor Authentication, are there any other techniques one can employ to protect legacy applications? The answer is yes. The first technique is pure security through obscurity, and it is highly effective, which is why for a long time it was considered best practice and is still utilized today by some of the largest organizations in the world. This technique is not using the email and username interchangeably. Most companies rely on Active Directory to provide basic authentication to devices and users. Active Directory has two username fields. The first is called the "sAMAccountName" and is a legacy attribute carried over from the days of Windows NT 4.0 (released in 1996). The second was intended to be the modern replacement, the UPN, or "userPrincipalName". The UPN was designed for ease of use and according to Microsoft "By convention, this should map to the user's email name". That creates a security vulnerability, especially as companies increasingly move to Office 365. Microsoft doesn't consider username enumeration to be a vulnerability (clearly) and therefore attackers can run scripts to discover the email addresses of your users without setting off any alerts or even creating a log entry. This means that earlier when I mentioned you needed two pieces of information to log into an account (username, usually the same as the email address, and password), attackers only need to guess one, they will be able to determine the username with absolute certainty and move onto guessing their password.
So how can we at least make their lives a little more difficult in the process? Username obfuscation is one approach. You can change the username to something unique and difficult to remember, since a username can only be changed by administrators, this has the added benefit that even if a user chooses a weak password, their username will still be different. But what about the UPN? The UPN will still allow login, but what you can do is change the domain name associated with the UPN to something different and not even disclose that to users, nudging them towards using the username. Or simply match up the UPN and the username and users will be forced to use their obfuscated usernames.
One of the most useful things you can accomplish using this approach is to cut down on user lockouts by attackers' password-spraying or brute-forcing their logins. Since most attackers are going to be spraying attempts against usernames based on the "email address = username" convention, none of those login attempts will be counted towards your users. Since account login attempts and lockouts create lots of noise and added logs, this approach helps to prevent analysts and support staff from chasing these entries. The fewer logs entries there are, the easier it is to find attackers trying to gain access.
To further extend this idea of username obfuscation, for every additional system your company takes on you can further differentiate the usernames, pushing users to utilize a password manager to manage this ever-growing list of diverse usernames and passwords.
Keep in mind that Security Through Obscurity is not a comprehensive approach by itself but can be used as an added safeguard. If you need help developing or updating your security or risk management strategy contact us and we will be happy to review your options.
Speak with any Pen-tester (Penetration Tester or Ethical Hacker) and they will tell you that their first order of business is to perform a process called Enumeration (Discovery of Devices and Services). You can't attack what you don't know about, so if attackers can't find it during enumeration they will focus on what they do find. Whereas a Pen-testers are paid to find avenues of attack and therefore will attempt more robust search and discovery techniques, attackers with malicious intent generally follow a more basic approach. Attackers usually focus on one, or a few, very limited vulnerabilities, where they expect the numbers game to play in their favor. That is why we are still seeing large numbers of attacks on RDP (Microsoft's Remote Desktop Protocol) and password spraying attacks in Office 365. Even though these attacks are well documented, as are their countermeasures, many companies assume they are too small to be targeted.
So how can Security Through Obscurity be deployed to effectively combat these attacks? We can start with authentication. Basic authentication today is thought to consist of 2 pieces of knowledge. A username and a password. It is well established that given the opportunity users will choose weak, easy to remember passwords. Thus, the focus of the security industry for the last decade or so has been to create mechanisms to filter weak passwords, create Multi-Factor Authentication (MFA) methods, and lately, the push towards password-less authentication altogether.
For clarity, I want to quickly derail and explain what password-less authentication is because it is a bit of a misnomer. Password-less authentication generally relies on a smartphone and a two-way verification of the user. The authentication screen displays a prompt which the user much interactively engage with. This interaction proves that the user is a human and a unique prompt at each login ensures that the user does not inadvertently grant access to an attacker. Password-less authentication abstracts (but does not entirely remove the password) the password remains a fallback method of authentication, albeit layered with a 2nd source of authentication such as a push to a phone or verification from a hardware token. The idea behind password-less authentication is a "web-of-trust". Web of Trust refers to the idea that new access can only be granted by persons or devices which have already been granted access, thereby expanding the web with the addition of each new device. This bridges the two biggest challenges in IT, Security and Availability. Traditionally the more available something is the less secure it is and vice versa. Despite its intentions, this technique has its own problems and is not the panacea it was originally thought to be.
So rather than push for password-less authentication or require Multi-Factor Authentication, are there any other techniques one can employ to protect legacy applications? The answer is yes. The first technique is pure security through obscurity, and it is highly effective, which is why for a long time it was considered best practice and is still utilized today by some of the largest organizations in the world. This technique is not using the email and username interchangeably. Most companies rely on Active Directory to provide basic authentication to devices and users. Active Directory has two username fields. The first is called the "sAMAccountName" and is a legacy attribute carried over from the days of Windows NT 4.0 (released in 1996). The second was intended to be the modern replacement, the UPN, or "userPrincipalName". The UPN was designed for ease of use and according to Microsoft "By convention, this should map to the user's email name". That creates a security vulnerability, especially as companies increasingly move to Office 365. Microsoft doesn't consider username enumeration to be a vulnerability (clearly) and therefore attackers can run scripts to discover the email addresses of your users without setting off any alerts or even creating a log entry. This means that earlier when I mentioned you needed two pieces of information to log into an account (username, usually the same as the email address, and password), attackers only need to guess one, they will be able to determine the username with absolute certainty and move onto guessing their password.
So how can we at least make their lives a little more difficult in the process? Username obfuscation is one approach. You can change the username to something unique and difficult to remember, since a username can only be changed by administrators, this has the added benefit that even if a user chooses a weak password, their username will still be different. But what about the UPN? The UPN will still allow login, but what you can do is change the domain name associated with the UPN to something different and not even disclose that to users, nudging them towards using the username. Or simply match up the UPN and the username and users will be forced to use their obfuscated usernames.
One of the most useful things you can accomplish using this approach is to cut down on user lockouts by attackers' password-spraying or brute-forcing their logins. Since most attackers are going to be spraying attempts against usernames based on the "email address = username" convention, none of those login attempts will be counted towards your users. Since account login attempts and lockouts create lots of noise and added logs, this approach helps to prevent analysts and support staff from chasing these entries. The fewer logs entries there are, the easier it is to find attackers trying to gain access.
To further extend this idea of username obfuscation, for every additional system your company takes on you can further differentiate the usernames, pushing users to utilize a password manager to manage this ever-growing list of diverse usernames and passwords.
Keep in mind that Security Through Obscurity is not a comprehensive approach by itself but can be used as an added safeguard. If you need help developing or updating your security or risk management strategy contact us and we will be happy to review your options.
