Lessons From LastPass Breach

Password management firm LastPass admited to being PWNED by hackers.  If you are a customer, your data was potentially breached and so us “Paranoid Androids” will be spending a significant amount of the holidays changing passwords and double checking our MFA settings.  The bad guys apparently got away with a massive stash of customer data, including password vault data that could be compromised by brute-forcing or guessing master passwords.  So much for the “Zero Knowledge” strategy, or is this it working? Is this as bad as it could get in terms of password manager security? I guess the only thing that could compromise your passwords quicker would be an attacker literally looking over your shoulder (known as shoulder surfing) while you type your username and password in.

But, well now, let’s look on the bright side, as long as you have diligently respected the power of keyspace and dutifully used a sufficiently long pseudo random password as your “LastPass” you should be fine… Unless the data gets into the hands of APT attackers that throw supercomputers at the vault data… Which they most certainly are doing as we speak… Oh well!

Then instead of looking on the bright side, let’s look on the security side. How can we look out for each other though a crisis of epic proportions such as this? As developers we should strive to implement the most secure authentication architecture in our applications as possible. So, let’s look at 6 ways to protect our users with access security controls!  I should warn that these are not bullet proof solutions (and under the adage of security I would never declare such a thing exists) but they will harden your application security and your users will thank you!

On dancer and Comit and Vixxen (I’ve named my fingers after the Reindeer).

#1 Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) is a security system that requires users to provide more than one method of authentication to verify their identity. This helps to prevent unauthorized access to sensitive information or systems. By requiring multiple authentication factors, MFA makes it much more difficult for unauthorized users to gain access to a system because an attacker would need to have not just one, but multiple pieces of information or devices in order to authenticate as the user. The future of MFA is getting even more exciting too with QR codes, fingerprints, and facial recognition to do the heavy lifting.

In a typical MFA setup, a user is required to provide at least two of the following three types of authentication factors:

1. Something the user knows: This could be a password, a PIN, or a security question.
2. Something the user has: This could be a security token, a mobile phone, or a hardware device that generates a unique code.
3. Something the user is: This could be a biometric feature such as a fingerprint or a facial recognition scan.

#2 Behavior Analytics

Behavioural analytics, behavioural analysis, is the process of analyzing user behaviour in order to identify patterns or anomalies that may indicate a security threat. In the context of access security, behavioural analytics can be used to monitor and analyze the actions of users as they interact with systems and applications, in order to detect unusual or suspicious activity and take action to block the user until they verify their identity.

A simple example of behavioural analytics would be to check the last time a user logged into your site before rolling out the red carpet and giving them access with only a username and password. If it has been 5 years, maybe you should ask them to verify their email address again even if they have demonstrated miraculous powers by remebering their password after all that time. Another easy thing to check is the geo-location of the user. If they are logging in from an unexpected location, ask them to re-verify their identity with an emailed token. Geo-location checks can reduce the likelihood of session hijacking as well. You can record the IP address associated with a session token and restrict sessions to that IP. If the user swaps WiFi networks in the middle of a session, heck ask them to put their thumb on the screen.  It’s not a silver bullet but it can prevent certain types of session hijacking attacks and your user’s will thank you for it!

# 3 Zero Trust

Zero Trust is a security model that assumes that all users and devices, whether inside or outside the network (or in our scenario the application), are potential threats and should be treated as such. In a Zero Trust model, access to resources is granted on a need-to-know basis, and all access is authenticated and authorized before being granted.

One key aspect of Zero Trust is the use of micro-segmentation, which involves dividing the network into smaller, more secure zones and strictly controlling access between them. Adapting this core Zero Trust principle to a application design you can divide your application in to “zones” and classify them by data and action sensitivity. If the user wants to access a sensitive area such as changing their account email address, payment information, or other highly sensitive actions, it is a good time to verify their identity with MFA or an email based token. Your users will hardly even notice and they will thank you for it!

#4 Rate Limit Authentication Attempts

Rate limiting is a security measure that is used to prevent unauthorized access to systems or resources by limiting the number of requests that a user or device can make within a certain period of time. This can help to prevent a range of security threats, including denial of service attacks, brute force attacks, and other types of malicious activity. Without rate limiting, an attacker could potentially make an unlimited number of login attempts using different username and password combinations in an attempt to guess the correct credentials. This is called a brute force attack and greatly increases the attackers ability to gain unauthorized access by eventually guessing the correct credentials. Don’t let it happen.  Make. Them Go. Slow.

Rate limiting by sets a maximum number of login attempts that a user or device is allowed to make within a certain time period. If the maximum number of attempts is reached, the system will temporarily block further login attempts from that user or device. This helps to prevent unauthorized access to the system and protect it from security threats.

Rate limiting can be applied to a variety of different types of systems, applications, and resources to prevent other types of digital abuse and can be an effective way to prevent unauthorized access and protect against security threats. Anyone who says differently is a fool!

#5 Salt Hashes For Stored Password Vaults

Salting a hash is a security practice that is used to protect stored passwords from being compromised in the event that the password database is accessed by an unauthorized party. Applications typically hash user passwords before they are stored using a cryptographic hashing function. This function takes the password as input and produces a fixed-length output, known as a hash. The hash is then stored in the password database, rather than the original password.

The problem with this approach is that if an attacker is able to gain access to the password database, they could potentially use a technique known as a “rainbow table” to crack the hashes and determine the original passwords. Rainbow tables are pre-computed tables of hashes and their corresponding plaintext values, and they can be used to quickly reverse the hashing process and reveal the original passwords and can result in brute-forcing attack against stolen passwords offline in what is known as a “rainbow table attack”.

To prevent this type of attack, the practice of salting a hash involves adding an additional layer of protection to the hashing process. When a password is hashed and stored in the database, a random string of characters, known as a “salt,” is added to the password before it is hashed. Most languages have built-in Bcrypt functions to make this an elementary breeze. The salt is then stored along with the hashed password in the database. By salting the hash, the original password is much more difficult to determine, even if an attacker is able to gain access to the password database. This helps to protect stored passwords and prevent unauthorized access to systems and resources.

# 6 Password Complexity Requirements

In the context of password complexity, “keyspace” refers to the total number of possible combinations of characters that can be used to create a password. A larger keyspace means that there are more possible combinations of characters that can be used to create a password, making it more difficult for an attacker to guess or crack the password.  Well… almost.  The user still has some skin in this game.  There are still some pretty lame passwords that can be generated for a requirement of 8 characters uppercase, lowercase, number and special character!

For example, consider a password that is composed of lowercase letters and numbers, and has a length of 8 characters. The key space for this password would be the total number of combinations of letters and numbers that can be used to create an 8-character password. If the password only allowed for lowercase letters, there would be 26^8 (208827064576) possible combinations. If the password also included numbers, the key space would be increased to 36^8 (2176782336). In general, the larger the key space, the more secure a password is likely to be.

The bottom line is this: force your users to meet a minimum key space. Hopefully they will use a password generator to create something truly random, because P@SSw0rd123 might have all forms of characters, but it’s still easily brute-forced by the masters. That’s why I put this one at the end of the list!

Leave a comment

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.