I stand behind LastPass as my pick for a password manager even with the security breaches that have happened because the design of their system allows for such breaches without compromising the security of their users’ data. As long as a ‘sufficiently secure’ master password is used, there is virtually no chance of user data being exposed to an attacker. Their system was designed from the ground up to be able to withstand such attacks and because they are transparent about how their system works, I can trust that system.
Today, 2016, the short answer of what I mean by a ‘sufficiently secure’ master password is 16 characters or longer. Basically, a 16 character password makes the task of brute forcing said password take far too much time for an attacker to attempt or spend much time on. I discuss sufficiently secure in more depth HERE.
One key point to how LastPass operates and why I trust them is that they do not store your master password. The traditional way to authenticate you on a system is for you to provide your username and password to the system and what you provide is compared to what they have stored. If they match, then you get in.
LastPass chose not to handle authentication that way because your password is the encryption key to your data and storing your encrypted data in the same place as your encryption key for that data is a recipe for disaster one day. What they came up with is an elegant solution that not only protects your data from an outside attacker, but also from an employee gone bad – which is arguably the hardest attack surface to eliminate for any company storing sensitive data.
(To fully understand this process, you must understand how a ‘hash’ works. I discuss what a ‘hash’ is HERE)
Here is a sort of pseudo code representation of how LastPass authenticates you followed by some explanation
Client Side
UniqueID = SHA256( SHA256( Email + MasterPassword) + MasterPassword )
The login process sends your email address and the UniqueID to authenticate you. The important things to note here are that this occurs on the client device and that your master password is lost in a double hash operation so the resulting UniqueID can NOT be used to decrypt your LastPass data and can NOT be turned back into your master password.
Server Side
Token = Random 256 bit blob (stored in DB)
AuthHash = SHA256( UniqueID + Token ) (stored in DB)
Their servers receive your email address and UniqueID, then they use the UniqueID you sent and a previously stored Token to produce an AuthHash and compare that AuthHash to one they have stored. An important point here is that they do not store the UniqueID. Your UniqueID could be used to impersonate you so LastPass specifically does not store it anywhere. Also important to note, that even if the UniqueID and AuthHash are stolen, they can NOT be used to decrypt user data.
This method of authentication accomplishes two things. First, LastPass does not have to store your password to accomplish authentication. The benefit there is that even if their entire database was stolen, or if a bad employee copied it all, an attacker could not use this information to successfully log in to their system as you or decrypt your data.
The second thing, and arguably the more important thing this method accomplishes, is keeping your encryption key off of their servers AND out of their network. At NO time does your master password leave your device so there is zero chance of an attacker stealing your encryption key from the LastPass servers, the LastPass network, or anywhere in between. The only real attack surface left is your local computer or device and if that is infected then the bad guy already can see everything you type, so they’d be able to get all of your account information already.
BREACH
If an attacker was somehow able to gain access to your AuthHash stored on the LastPass servers (as the recent breach seems to indicate has happened) – then that is still only one of two critical pieces needed to authenticate as you with LastPass. If an attacker was also able to gain access to your UniqueID by way of tapping into your network traffic with LastPass – which isn’t common, but IS possible – then they would have what they needed to successfully authenticate with the LastPass servers. After all of that however, they still could NOT decrypt your data without going through a brute force attack and the success of that attack would be directly tied to the strength of your master password. If your master password is ‘sufficiently secure’, as discussed above, then there is nothing to worry about because a bad guy wouldn’t have enough time in his or your lifetime to brute force their way into your data.
Some people only stand behind offline password managers and I won’t argue against the idea that an offline password manager could still be more secure in some ways than even a ‘perfect’ online one. However, with the system LastPass has designed, for me, there is nothing to fear. Both online and offline password managers rely on the strength of your master password however, so be sure to use a ‘sufficiently secure’ master password no matter where you store your passwords and other sensitive data.
Source:
