Strong Passwords and LastPass: Part 2

Tue, 04 Aug 2015

In our last post, we reviewed why strong passwords and using LastPass is a good idea, especially for MSPs, like Trek10, who need to be sure that customer data are stored securely using best practices. We also discussed how attackers are able to crack passwords from an encrypted database by explaining how rainbow tables work. In Part 2, we will discuss LastPass’s technical design. To better understand their implementation, let’s first review the concept of salting to, which is a key aspect of how LastPass is able to keep our customer data safe.

What is a Salt? As we discussed in Part 1, LinkedIn’s password storage design was found to be very insecure after its breach. In addition to not using the obsolete MD5 hash, there is one simple way LinkedIn could have significantly improved the security of its password databases — it’s called salting. A salt is data that are generated and added as additional input to a cryptographic hash function. The purpose of a salt is NOT to keep it hidden from the attacker but to alter the hash function input making rainbow tables useless. For example, LastPass leverages the user’s email address as a salt (more on this later). Instead of hashing “123456” and storing this value in the database, the system will hash “user1@example.com123456” resulting in a completely different hash:

Now, if the attacker has the salt and the hash (which is usually the case if a system is breached), he might still be able to target some users and crack individual weak passwords, but he will not be able to run the 6.5 million hashes (in the case of LinkedIn) against a rainbow table to crack all weak passwords. He would need to create a separate rainbow table for each user by using the appropriate salt associated with each hash. This is computationally expensive, but it is certainly not impossible with the processing power available today. For additional security, the number of hash iterations can be increased to a point where it becomes computationally infeasible for an attacker to precompute a rainbow table that will crack all weak passwords.

In the next section, we will discuss how LastPass keeps its passwords safe so that even if a breach occurs (as it did), users with strong passwords need not worry. LastPass has set the bar for password storage design, and they set it pretty high!

LastPass Implementation: The Golden Standard With LastPass’s implementation, they have no access to your encrypted password vault or your master password. Both are hashed/encrypted prior to being stored on their servers. In order to understand this complex design, let’s take a look at each step taken to authenticate the user and decrypt the password vault:

• After installing the LastPass browser plugin, the user enters her email address and master password to retrieve her password vault. LastPass takes the email address (a salt), changes it to all lowercase, appends her password to it and hashes it using PBKDF2-SHA-256 (a very secure way to hash involving lots of additional salting — just take our word for it!). This process happens, by default, 5,000 times locally on the user’s machine.*
• The PBKDF2-SHA256 algorithm generates an AES-256 bit symmetric key (discussed in step 4), on which one final round of PBKDF2 hashing is performed. Then, finally, this value is sent to the server over SSL (or should we say TLS?) to authenticate the user.
• The resulting value from the final round of hashing is processed on the server by adding another salt and another 100,000 rounds of PBKDF2-SHA256 hashing. This value is then compared to what is stored in the database (which was found through these same computations the very first time the user set up her master password); the user is now authenticated! If the user is logging in from a new browser/device, she will be prompted for her MFA code if (hopefully) enabled. Once fully authenticated, the encrypted password vault is sent to the client machine for local decryption.
• The AES-256 bit key generated in step 2 is kept locally in the browser and used to decrypt the password vault sent to the client machine at the end of step 3. The user is now able to see all saved passwords. Each time a new password is saved to the vault, this AES-256 key is used to encrypt it, and it is sent to the database on LastPass’s servers. Keep in mind, this key was generated only within the user’s own browser through the aforementioned hashing process (derived by the master password and email address salt). LastPass never has access to the key!

*You can actually change the number of hashing iterations to any number. This increases security because it varies from the default 5,000 number an attacker would use when trying to crack passwords. Navigate to your Account Settings and find “Password Iterations.” Although these hashing iterations only occur when you log in, don’t make the number too high — it takes time and resources for your CPU to complete all those iterations! LastPass recommends to keep the number under 10,000.

If you ever wondered why strong passwords are so important (and why to never reuse them) or had second thoughts about installing LastPass, I hope this post steers you in the right direction! If you have any questions about this post or on securing your cloud environment, shoot us an email at security@trek10.com.