When designing security for your organisation, consider looking from the outside in. Put on your black hat and think:
“If I was trying to hurt this company, what could I do?”
Throw away the rule book, disregard that moral compass and listen to the devil on your shoulder. Reckon you could do some damage?
You don’t necessarily have to be an experienced hacker or penetration tester to be effective in this mindset either. You already have the advantage of knowing the network, the software used, and authentication flows. You’re already several steps ahead of an attacker trying to gain a footprint in your organisation. Using this knowledge you can better assess whether a skilled hacker could potentially damage your brand.
So, what’s some areas to look for when assessing your security? The following is not comprehensive and does not negate the need for formal security testing, but it should provide some prompts to address potential weaknesses early on.
Depending on your use case, you may or may not employ Multi-Factor Authentication (MFA). Low risk apps may not require it, but should at least be offered as an opt-in using something like TOTP (Google Authenticator, etc).
If you mandate MFA, great start! If not, there’s a range of ways to attack your login page from the get-go. Account enumeration, mass account lockout and weak password tests are low-skill, high impact attacks that even inexperienced hackers can utilise to damage your business.
Also, don’t allow yourself to be seduced into thinking MFA is a simple on/off switch, it’s more nuanced than that, and its only part of the equation. MFA can be implemented in a variety of different ways, with varying levels of complexity, from simple codes to liveness-checking biometrics.
Let’s keep going with some more food for thought:
- When authenticating, what comes first? An MFA code or a password?
From here we venture down the rabbit hole. If MFA is first:
- How many attempts do I get before getting locked out?
- Is there any lockout mechanism or can I just keep on trying?
- If I get locked out, am I locked out across the whole organisation? Or just this login page?
Hopefully this is shining a light on possible ways to exploit your login page. We’ll use this information later.
If challenged for a password first:
- What is the password validated against? An internal directory?
- Can I lock out the directory account?
- Are authentication requests rate limited regardless of user?
- What are people using for a username?
- Can I enumerate the username?
- Is it an easily guessable email address (e.g. could I guess email addresses by looking up names of employees on LinkedIn)?
- Is there a response time difference between a failed login for a non-existent account vs an actual valid account? Can I use that to identify real accounts?
Depending on the answers above, here are some possible attack vectors to consider:
- Brute forcing a TOTP code (like a Google Authenticator code) is possible in a relatively short period of time without intrusion detection.
- Password cracking by testing weak passwords across a wide range of known user IDs.
- Locking out mass amounts of users to disrupt business operations by repeated bad login attempts.
Let’s say the login page yields no obvious security flaws, nice work! We can start applying similar logic to other public interfaces such as Password Reset flows.
- Do I need to call a helpdesk to reset a password?
- What information does the helpdesk ask for to reset a password? Is there a way to source that information?
- Do you employ a web-based self-service password reset tool? If so, what are we using to verify the user’s identity? Email address? Security Questions and Answers? Are the questions simple?
- If you’re unable to lock out accounts on the login screen, can completing multiple bad password reset attempts actually lock out an account?
Are the security questions easily guessable? How easy would it be for someone to write a script to test answers across ten thousand users? What’s the chances of cracking even one account?
Often, it’s only a matter of cracking one account to set up a foothold in your organisation. From there an attacker can look to elevate their access or attack less secure targets within the front door of your organisation.
So now that you’ve poked and prodded your authentication endpoints, how do we address the weaknesses we’ve found? There isn’t a single configuration set which mitigates against all these attacks, because requirements are different from application to application. However, here’s some suggestions:
- Usernames should not be easily guessable or sequential. Depending on your app, emails as usernames may not offer enough protection either.
- Password complexity is an easy one, but also, if you are using security questions/answers for password reset, enforce complexity here too. Laziness leads to a lot of these ‘answers’ being ‘12345’ or similar.
- Ensure that intruder detection is enforced on both first and second factors in the login process. I’ve seen systems that only enforce this on the first factor, leaving the second factor wide open to brute force.
- If the public app uses staff credentials, consider compartmentalising lockout to only your public app. This protects against someone attempting to lockout bulk accounts. This needs to be weighted against the needs of your organisation.
- Track intruder detection and rate limiting across IP and session and not just based on account. This makes the job of the hacker much harder to perform attacks on scale.
- Implement a CAPTCHA on your login screen. This is another tool to make the job of cracking accounts more difficult.
- Review any process for human interaction when it comes to password reset. Social engineering mixed with a bit of OSINT (open source intelligence) means it’s not difficult to answer almost any personal question.
- Implement Adaptive or Risk Based Authentication, this approach will assess each authentication individually and assign a risk score, this could be based on IP geography, time zone, device type and metadata about the account itself. From here a suitable level of authentication can be chosen automatically and dynamically.
It’s worth noting that this is a starting point. Protecting internet facing authentication is not something that can be covered completely in a single blog post. But thinking like an attacker can help to reveal weak spots not only in authentication but other areas of your business.
Have I missed anything? Got something wrong? Let me know in the comments! I’m always learning too.