With the growth of personal data privacy regulations like GDPR and CCPA, it’s clear the tech world is moving towards a Privacy by Design approach when it comes to how organizations store data and design software. While securing sensitive data is a critical concern, it’s also essential that individuals and developers continue to secure the credentials used to access that sensitive data.
This may seem obvious, however, a recent KPMG advisory shows that while 75% of Americans consider it risky to reuse passwords for multiple accounts, more than 40% still engage in that behavior. Furthermore, a LastPass survey suggests 62% of respondents reuse passwords between personal and work accounts. Clearly, there’s still a long battle ahead for those who champion best practices for securing credentials.
First, let’s review some individual best practices to protect against attacks like Credential Stuffing, Password Spraying, Phishing, Brute-force, and more. After that, we’ll take a deeper dive into how software providers and web applications can help enforce individual best practices and protect log-in pages and processes.
End users are the last line of defense when it comes to credential security. Software, web application, and website developers certainly take on most of that responsibility, however, individuals shouldn’t assume in good faith that all services are employing proper security practices.
Here are some ways individuals can protect themselves from credential theft, along with the associated attacks these practices prevent.
Prevented Attack: Most credential-related attacks, including Credential Stuffing, Password Spraying, Phishing, Keyloggers, Brute-force, and Local Discovery.
Let’s start with an all-encompassing tip for credential security: use multi-factor authentication whenever it’s available. If you only do one thing to protect your credentials, this should be it. In fact, analysis from Microsoft suggests multi-factor authentication could have prevented 99.9% of account compromises.
While it’s up to each service to provide and advertise MFA functionality, it’s always worth checking under your account settings (usually under Privacy and/or Security) to see if MFA is a not-so-obvious feature. Personally, I’ve found MFA services for accounts that never once prompted me to use them, just by poking around in the settings on the website.
There are also hardware-based MFA options, such as Google’s Titan Security Key, that takes MFA security to the next level.
To reiterate, using multi-factor authentication is the most important thing you can do to secure your credentials. For the rest of this blog, it will be assumed that MFA is being used as it helps prevent everything we’ll be discussing. That being said, you should still always change passwords if they’re stolen or breached regardless if you’re protected by MFA.
Prevented Attack: Credential Stuffing
Credential Stuffing attacks are popular and on the rise year-over-year, although preventative maintenance is relatively easy. This attack is when breached username/passwords combinations are programmatically tested against various services to try and gain access to potentially sensitive user accounts. Since this is only effective If users reuse their breached credentials elsewhere, the solution is to avoid all password reuse.
This may seem like a pain, needing to remember so many passwords, however, password managers make this much easier. By using a password manager, users only need to remember one master password (which should be long and complex). While this increases risk if the master password is stolen, it protects users against being vulnerable if one of their non-master passwords is included in a data breach. Password managers will automatically generate long, complex passwords, making it easy to use a unique, complex password for each account.
And don’t worry too much about the password manager service being breached. Even if that were to happen, all the major password manager providers ensure stored credentials are properly encrypted.
Prevented Attack: Password Spraying
Using common passwords enables the practice of Password Spraying, which is a popular attack where threat actors programmatically apply a large dictionary of well-known passwords against many services and user accounts across the internet. We’ve discussed bad passwords before, however, well-known passwords such as “123456”, “password”, and “qwerty” continue to see frequent use. Simply put, the best way to prevent this attack is to use unique passwords (i.e. don’t use common passwords) and to avoid password reuse, which again is aided by the use of a password manager.
Prevented Attack: Brute-force
A brute-force attack, although uncommon these days in lieu of Credential Stuffing, Password Spraying, and Phishing, is when an attacker uses a program to continuously guess passwords for an account until they gain access. Typically, the attack starts with short, simple passwords and expands in complexity as it continues to run (and fails to gain access) This is why the length of your password is so important, as passwords containing numbers, upper/lower case letters, and symbols that are 11-characters or longer will take years to brute-force even with a top-of-the-line cracking rig.
In addition to using long, unique passwords, it’s also important to avoid using personal information in passwords (ex. birthday, family names, pet names, essentially anything that can be tied back to you), as well as context-specific information (i.e. don’t use the phrase “google” in your Google password). If an attacker is specifically targeting you, then using personal and context-specific information can reduce the number of passwords they need to guess.
While end-users should take responsibility for securing their credentials, the growth of data privacy laws such as GDPR and CCPA means websites, web applications, and software need to take proper preventative measures against credential attacks or potentially face stiff fines in the event of a breach.
Unfortunately, security for the sake of security is not popular among end-users. When new security features are added to a website or software, users typically ignore them or push back if their experience is impeded in any way (ex. required multi-factor authentication may be considered a nuisance).
Despite this potential pushback from users, proper security features should continue to be implemented in all services, and potentially required. It not only helps protect organizations from fines and lawsuits but also helps users see the big picture regarding security in the long run.
Here are some ways websites, web applications, and software can protect end-users from credential theft:
As stated earlier, using multi-factor authentication is the most important thing end users can do to secure their credentials, so any software or service requiring log-in to an account should enable this functionality for their users.
However, many MFA implementations default to using SMS for the verification code, and unfortunately, the SMS protocol has many security problems and is generally an insecure option for MFA.
SIM Swaps – With enough of a user’s personal information, including their phone number, an attacker can socially engineer the user’s phone service provider into transferring the victim’s phone number to the attacker’s SIM, meaning they will now receive all SMS messages addressed to the victim’s phone number (including MFA verification codes).
Intercepting SMS Messages – Attackers have also found ways to intercept SMS messages, specifically by abusing vulnerabilities in the Signaling System No 7 (SS7) protocol (known as Common Channel Signaling System 7 (CCSS7) in the United States). While not an issue domestically in the U.S., SS7 is what allows a smartphone to change networks and operators when used in different countries (i.e. roaming). To abuse known vulnerabilities in SS7, attackers only need Linux and a readily available SS7 SDK.
Due to these vulnerabilities in SMS, the protocol should be avoided for sending MFA verification codes to users. In its place, authentication apps, such as Google Authenticator or Okta Verify, should be used. These apps were built specifically for multi-factor authentication and have security in mind. Plus, even if a user’s SMS messages are hacked the attacker won’t be able to access verification codes handled by authenticator apps.
Single sign-on centralizes user identity and authentication, so a single set of credentials can be used to access multiple applications, services, and websites. Not only is it very convenient for end-users, but it also reduces your risk as a vendor by limiting the number of credentials you’re storing (with SSO the identity provider (IdP) verifies credentials, not the service provider).
Before implementing SSO for your software or service, you’ll need to pick an SSO standard. Some popular options are:
It should be noted that OAuth 2.0 is more aimed at limiting access scope than SAML and is far more popular than SAML for web and mobile applications.
To use these options for SSO, you also need to pick an identity provider that supports your chosen protocol, such as Google, Facebook, and Microsoft for individual SSO. For a corporate environment, popular identity providers include Azure Active Directory, G Suite, and PingFederate.
This one is easy to overlook, however, the error messages returned from failed logins can give attackers performing reconnaissance plenty of info. Take this screenshot from a failed Facebook log-in as an example:
What this tells an attacker is that the email or phone number they’ve tested for log-in doesn’t exist. When compared to the error below, for a valid account but incorrect password, it’s obvious how attackers can gather a list of valid account names, emails, phone numbers, etc. for a website or service.
For Facebook this likely isn’t an oversight, as determining an individual has a Facebook account isn’t sensitive information that most people want to be protected (after all, you create a personal profile to share with the world on Facebook). However, there are other websites and services that users may not want to have their membership exposed for, which these types of error messages clearly relay to attackers.
Besides simply exposing that a user has an account on a website or service, informing attackers of an account’s existence can also motivate Credential Stuffing, Brute Force, and Phishing attacks towards the specific victim. It’s not a terribly high risk to expose this type of information, however, if you’re following security best practices there’s no reason not to implement proper error messages.
To give you an idea of what a good generic log-in error message looks like, look at this error from GitHub (which is the same for both a non-existent account and an existing account with an incorrect password):
Hashing is at the core of any password storage workflow, but it’s worth mentioning as there are still websites out there that store passwords in plaintext.
Any time you need to store a user’s password, it should be salted and hashed using proper, modern cryptographic techniques, such as PBKDF2 and Bcrypt, that are deliberately slow algorithms to deter programmatic brute-force attacks (compared to fast algorithms like SHA-256, which accelerates programmatic attacks).
In case you’re unfamiliar with salting, it’s when you add random data to a user’s password input before it’s sent to the hashing algorithm, which adds complexity to the resulting hash and makes pre-computed Rainbow Table Attacks and Brute-force dictionary attacks more difficult.
This is a perfect example of helping users help themselves. When users enter their password, whether it’s for a new account or changing an existing password, it should be compared against a list of well-known and breached passwords, such as the Have I Been Pwned database from Troy Hunt.
If the user tries to use a password that’s known to be included in password database breaches, and thus a target for Credential Stuffing, then it should be rejected, and the user should be prompted to choose a different password.
The error message returned to the user should also explain why their password choice was rejected, to prevent them from becoming confused or frustrated by the password selection experience.
HTTP is old news and doesn’t encrypt communications between a client (web browser) and a server (meaning everything is in plaintext, including credentials). To resolve this, your website, application, or service should allow the installation of a TLS/SSL certificate to enable encrypted HTTPS traffic for all communications.
This may not be news to developers in 2020, but there should also be safeguards in place that prevent users from accidentally accessing an HTTP version of your website. Primarily this is done by redirecting any HTTP requests to the HTTPS version of the requested page, however, HTTP Strict Transport Security (HSTS) can also be used to mitigate man-in-the-middle and protocol downgrade attacks.
Any time there’s suspicious activity on an account, the end-user should be notified via an email.
This may be a new log-in from a region of the world the user has never previously logged-in from or a request to change their password. Any time a user’s sensitivity information is changed, they need to be alerted via email, so they can revert the changes and change their password if their credentials have been compromised.
Besides these event-based alerts, it may also be useful to periodically email users and inform them of the security features your service enables that the user may not be aware of (such as MFA options).
We’ve discussed NIST’s 2020 password guidelines in-depth in a previous blog post, so I won’t go into depth here. However, these guidelines should be strongly considered as a solid foundation for any website, application, or service handling passwords.
Although outside the scope of this blog focused on protecting credentials, there are far more developers can do to secure websites and web applications.
One such example is to implement a Web Application Firewall (WAF), which protects against malicious file execution, SQL injections, cross-site scripting (XSS), DoS/DDoS, and more by inspecting all HTTP/S requests before they’re served.
Another example is bot detection software, which can inspect incoming requests to filter out bots before that traffic communicates with your website or application. This is a more advanced technique, but it can help prevent programmatic attacks on credentials such as Credential Stuffing, Password Spraying, and Brute-force.
80% of breaches involve weak or compromised passwords, and the top 10 most common passwords still including “123456”, “password”, and “qwerty”. Breach costs will only rise, further emphasizing the importance of the password.
Using a dictionary of 570+ million known compromised passwords, along with complexity, character substitution, and testing tools, StealthINTERCEPT Enterprise Password Enforcer safeguards your organization from credential-based attacks.
Stealthbits can identify and prevent weak and compromised passwords from being used, and even provide end-user guidance on how to choose a stronger password. In addition to enforcement, Stealthbits’ Data Access Governance (DAG) solution, StealthAUDIT, includes a Weak Passwords assessment for organizations using Active Directory.
IDENTIFY THREATS. SECURE DATA. REDUCE RISK.
Stealthbits is a customer-driven cybersecurity software company focused on protecting an organization’s sensitive data and the credentials attackers use to steal that data. Learn more about Stealthbits here.
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.Read more
Start a Free Stealthbits Trial!
No risk. No obligation.