The challenge for Day Seventeen is – Research a recent hack/security breach
This was a fun challenge with tonnes of material to pick from.
I decided to look into the HSBC breach that I heard about on the IT Governance Weekly Podcast from the 9th of November.
In a BBC article posted on the 6th of November, it claims that a number of HSBC US customers were affected by a data breach that compromised “information including account numbers and balances, statement and transaction histories and payee details, as well as users’ names, addresses and dates of birth.”
HSBC claimed that the breach occurred between the 4th and 14th of October and affected less than 1% of their 1.4 million US users (which still sounds like an awful lot).
The affected accounts were suspended and customers were forced to change their passwords in an attempt to stop the damage.
Official information on how the accounts were accessed is slim, but it’s suggested that credential stuffing was used to “guess” customer’s usernames and passwords.
Credential stuffing is where attackers use an automated script to attempt to log in using a list of known compromised usernames and passwords. This is another reason why people are recommended against using the same password across different sites.
You might think it’s unfair for HSBC to carry the blame for this, it’s not their fault their users had weak or repeated passwords right?
Well, sort of.
Yes it’s true that people are human and it’s more natural to pick a password they can remember, but there are steps an organisation can put in place to help ensure that the login details are secure.
I don’t have any visibility of what HSBC had set up before the breach, but here are some ideas to help mitigate the risk of this happening:
Two Factor Authentication
2FA is increasing in popularity, it requires that users have an additional method of confirming their login attempt.
For example entering their username and password, then having to enter a code sent to their mobile phone number via SMS.
This way malicious users will need to have both the username/password and find a way to intercept or generate a SMS code. It’s not a silver bullet but it’s better than just relying on a username/password that could be stored in a stolen database.
Enforcing strict password policies
If a user can have “password” as their password, you’re going to have a bad time.
Adding complexity like uppercase/lowercase/special characters/numbers means you’ll have passwords like “@Password123” – better, but still not great.
One clever way of ensuring that users chose a strong password is by limiting their ability to pick a previously compromised password.
Troy Hunt is very highly regarded in InfoSec and has created a website called haveibeenpwnd.com which has an extensive database of credentials that have been compromised in recent events. From his website you can enter your email address and it will quickly let you know if you should change your password.
Using this clever method will add the list of compromised passwords from haveibeenpwned.com to your company’s Active Directory so that users will be unable to use a known vulnerable password.
Set up monitoring and reporting services
If you know that your users generally access their account within a set time and from a set location or IP address, by using services like New Relic and GoogleAnalytics it’s possible to have your network administrator / security expert notified if someone from outside of these requirements logs in.
There is a cool feature here that has been designed to advise users if their login details have recently been involved in a breach. On entering their username and password, a pop-up will advise them that their details have been potentially compromised and that they should consider changing their password.
This will help your organisation to respond to breaches and hacks quickly.
Or – get rid of passwords altogether
This is a bit left field, but a significant portion of breaches are down to user credentials being disclosed or guessed.
Organisations such as the FIDO Alliance are working towards removing passwords to remove the risk of disclosing them in the first place.
It’s impossible to say an application or database is 100% secure.
I like to compare it to having your car stolen.
If you leave your car parked:
On the side of the road
With the windows down
The doors unlocked
With the keys in the ignition
With no alarm / immobiliser
There’s a good chance that someone could take your car
But just because you:
Park the car in a locked garage
With the windows up
Keys locked away from the car
With an alarm and immobiliser fitted
Doesn’t mean that your car won’t get stolen – it just makes it harder for someone to take it from you.
By setting up barriers for attackers, it makes it more likely that they’ll go for easier targets rather than wasting valuable time attempting to break into yours.
Thanks for reading my post and following my progress through the 30 Days of Security Testing.
Feel like joining in? Sign into the WeTest Slack group and get involved!