How Donald Trump could be locked out from Twitter
The account lockout Denial of Service attack scenario
A common security compliance rule (such as PCI, ISO27K, NIST) is to apply an account lockout for a period of time after several failed login attempts. The primary aim is to throttle brute force attacks, where the bad actor is attempting to programmatically guess a password using a dictionary.
This attack vector can also be used to perform a Denial of Service (DoS) attack, where the bad actor’s aim is not to gain entry but to prevent a legitimate user from their own system. Such as effectively stopping a CEO, President or a board member from checking their email, social media, accessing a CRM or an ERP or other vital system. With the advent of Single Sign On and Directory Services, the blast area is much greater — you are locked out of nearly all services.
Like several martial arts styles where the force of the opponent is used against themselves, the account lock out security measure preventing entry is leveraged against itself to stop legitimate users from the system it was protecting.
More worrying, is a bad actor could target an entire organisation users, which can be attained or gleaned from email lists, LinkedIn or similar online directories, email addresses or first and last name combinations. Usernames that use an identification number, such as an employee number could be used by simply cycling through the numbers, locking each employee out as it increments to the next.
Most counter measures involve throttling or slowing the attacks, such as time outs, or using an additional security layer such as CAPTCHA or Multi Factor Authentication. Unfortunately, these also delay legitimate users from logging in and neither stop an actor whose aim is to simply lock the account. Attempts with the wrong CAPTCHA or MFA will still lock an account.
Blocking the IP address of an identified attacker will stop that bad actor. However, a Distributed Denial Of Service (DDoS) attack mitigates this. The account still gets locked out from another IP address. Tools like Fail2Ban is useful on Linux type systems, but for SAAS systems the firewall or Intrustion Detection System enters the play. See the article on how to throttle Bad Actors like “David Caruso” from accessing a Linux system.
Setting the account lockout threshold to 0 failed attempts prevents a malicious user from intentionally locking accounts but now allows brute force password attacks and also contravenes various security compliance regimes.
External vs Internal network lockouts are a good idea for corporations. Hopefully the bad actor isn’t able to use Malware internally to launch attacks.
If an account becomes locked while the user who is already logged in or on a whitelisted device, they can still perform their functions until they log out or the whitelist entry expires. A bad actor would try to perform the denial of service attack before the user begins their morning online routine.
A cunning attacker would target help desk staff first before moving onto the rest of an organisation. Self service to unlock an account is useless because the DoS attack locks your account again. So you ring help desk, but even the support staff are now locked out too.
A useful counter measure is to treat the username like a credit card number. It should not be easily known, guessed or given away without authorisation. Online banking seems to have taken this approach but unfortunately corporate systems, social media platforms and other cloud offerings still prefer easily identifiable usernames, such as an email address or known handle. Perhaps it’s about managing risk, your online bank account vs an inane system. However, if DDOS protection is always set at the (network) perimeter, then the weakest link will be the one that is ignored but present: the Account Lockout DoS attack.
A more paranoid option would be to obfuscate the login name entry just like the password field: ********. Login names and passwords would be treated equally, both are secret. This combination makes an account highly secure.
For the developers of security models, differentiate between a login name and a username. The username might be publicly known (such as a Twitter handle), but the login name is secret. That is, the login name is not the same as the username. Having the login and password both secret increases security and you could apply the same password controls on the login name (roll it, reset it, change it or set conventions).
Don’t use email addresses as a login name or a combination of a person’s name (such as john.doe, jdoe), no numbers either. It should not be easily guessed or programmatically attempted.
Treat a login name like a credit card number. Guard it.
*Twit [noun]: a user of the social network Twitter; Also an imbecile.
