LastPass Password Database Explanation

LastPass has gotten a lot press recently with the security scare detailed on there blog, before this time I was not an active LastPass user but I was planning to migrate over from my previous KeePass password database based heavily on recommendations from technical podcasts I subscribe to. To be absolutely honest, LastPass’s response to the security incident is what has sold me on the product and am now a premium member, I don’t want this post to be review of the product but an explanation to a not so technical minded users how the product works and why it is secure. I am a very visual person and when these sorts of technical implementations are explained to me I usually jot it down as a little hand drawn diagram so what I have done is reproduced this in a digital form.

Now I was actually surprised I was unable to find any diagrams already produced increasing my emphasis on including them in my post. Unfortunately this means I need to be extra careful in my research to make sure what is being describe is what I’m drawing. I’ve intentionally left the salting information a bit vague as I could not find much reliable information how it actually worked but will explain a little bit about salting hashes shortly, the main importance is that they are included in the process to increase security. I’ve tried to highlight in red information you do not want LastPass to have and in green or neutral colours public or shared information between the user and lastpass and I’ve picked orange the encrypted data blob to indicate it has important data inside but his protected by encryption. Hopefully this makes sense, but what I am really trying to say is I’ve done my best, if there are any errors please let me know so I can update the diagrams.

Some terms that need to be explained before going any further are the following:

  1. One Way Hashes:
    • They are one way because they can not be decrypted, only generated one way.
    • They standardise the length of any string entered:

test = 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 tester = 9bba5c53a0545e0c80184b946153c9f58387e3bd1d4ee35740f29ac2e718b019

  1. Salting Hashes:
    • Salt adds an additional bit of data to the data already being hashed to make it more difficult to attack via Brute force or Dictionary attacks.
    • This means an attacker would need to try the same hashed text for every single salt possible to successfully test a single hashed value.

Example: If the salted data was a number between 0 and 9999 and the hashed data was ‘test’ the attacker would need to attempt ‘0000test’, ‘0001test’, ‘0002test’ etc. to successfully complete cracking the hash data ‘test’ (salted data is not as simplistic as between 0-9999, I’m just using it as an example.)

A goal for LastPass is to never know what your Master Password is, or have access to any of the information stored inside your personal password database, to achieve this, all encryption and decryption happens on the user side and none of this completed on the server side. The first diagram explains how the encryption creates the Encrypted Data Blob (containing your personal password database) which is then synced to the LastPass cloud servers.

The diagram shows the three inputs: ‘Username’, ‘Master Password’ and the ‘Unencrypted Password Database’, then the process that occurs to encrypt the data, and then finally the outputted ‘Encrypted Data Blob’.

The username, which for LastPass is an email address is sanitised (made all lowercase, no spaces) and is combined with the unaltered Master Password, and encrypted using salting to increase the complexity of the Hash generated.

This hash is then used as the key for encrypting your personal password database, the result of the encryption (using AES256 encryption) is a ‘Encrypted Data Blob’ (text file of random gibberish) which can only be decrypted with this hashed key.

The ‘Encrypted Data Blob’ is the only piece of sensitive data that is sent to the LastPass servers (over SSL/HTTPS) it can not be decrypted by Lastpass because they are not sent the ‘Master Password’ or the ‘Private Hash’ used to encrypt the Password Database.

Now the next step is sending the ‘Encrypted Data Blob’ to LastPass but because this is authenticated using the same Master Password for your LastPass database, LastPass need to use a method of authenticating the user without storing your actual Master Password. This is done by creating Unique ID hash based on your Master Password, and because hash’s are one way, it is not feasible for LastPass to decrypt or are able to determine the Master Password based on this hash.

The hash is created in a similar way to the hash key to your password database, but the hash result is then hashed again to create a new unique hash. It is done this way so the hash that you use to authenticate to LastPass is not the same as your key to your Password Database. 

Once this ‘User ID hash’ has been created it is used to authenticate to LastPass, however, LastPass take an additional step to protect your security and does not store this ‘User ID hash’.

The ‘User ID hash’ is used in the process to generate and compare a LastPass server-side hash, which is created using a ‘Random Number’ (generated at account creation) and your ‘User ID hash’.

If the hash stored on the LastPass server matches the hash generated on the fly during login then the user is authenticated, if not the user is not authenticated.

Also to note all this communication is taken place over SSL/HTTPS, making man in the middle attacks (people who are monitoring data traffic), almost impossible.

Ok to clarify, the username (email address) is known by both parties, the User ID hash is used to create the server-side hash to confirm authentication, this situation allows LastPass to authenticate a user without knowing there ‘Master Password’ or having access/requiring the ‘Private Hash’ used to encrypt the password database containing users personal passwords.

With this foundation it allows for a user to have a password database that is secure but has the built-in convenience of being available on any platform the user is using (eg. IE, Firefox, Chrome, Android, iPhone, iPad, etc.).

For the most part I have been talking about how LastPass works, I think the added advantage is the built-in functionally of promoting good password security and prompting when a web site is changing passwords to generate a new unique strong password for that site with polices like lowercase + uppercase + numbers + symbols etc. but still allowing the user convenience of only having to remember one master password.

For me personally this provides exactly the same password database security as KeePass but with the added integration into the browser which is not possible with an isolated password management solution. With the latest security breach at LastPass, even though it is not possible to know what information was actually exposed to hackers, the most that a 3rd party could access is the Username, LastPass server hash and the salt random number, which even with this information exposes little risk to you, and the simple act of changing your Master Password nulls the information exposed to any 3rd parties including LastPass.