Skip to content

Should you trust looks like a handy online service for storing all your website passwords. Browser extensions are available to make the whole process easier. If you use the web from several PCs it does sound nice to have all your passwords available and synced between your PCs.

First thought was wether I should hand over my passwords to the 3rd party, hopefully they are storing them with some serious crypto. Perusing their FAQ I found some info on this:

We only support keeping the encryption done on your computer so LastPass can’t see your sensitive data

…your sensitive data is always encrypted and decrypted locally on your computer before being synchronized. Your master password never leaves your computer and your key never leaves your computer. No one at LastPass (or anywhere else) can decrypt your data without you giving up your password (we will never ask you for it). Your key is created by taking a SHA-256 hash of your password. When you login, we make a hash of your username concatenated with your password, and that hash is what’s sent to verify if you can download your encrypted data.

So they are encrypting everything with a key derived from your password – plus they don’t know your password – so they CANNOT access any of your passwords. Nice. But why stop there? Let’s fire up fiddler to make sure they definitely don’t have my passwords.

I’ve created a junk account on lastpass username:, password: test1234 (the account will be gone by the time you read this!). The first form I see submitted to the server is when I create my account:

hash 53c81a859a3f3d4dc3762d3a47bab07fad7ad3f2673724deb20fb420e8bdc03a
password ********
password2 ********
password_hint testing
timezone2 +10:00,1
language2 en-US
agree on
agreeupload on
loglogins on
improve on
json 1

I don’t see my password going to their servers in the clear. I can confirm that the hash getting sent is geniune by creating the same hash elsewhere via an online SHA256 generator, or writing some code myself. Try it yourself, the hash created is SHA256(SHA256(username + password) + password) – everything checks out. All the C# code to verify the encryption/hashing is at the end of the article.

The login form:

method web
hash 53c81a859a3f3d4dc3762d3a47bab07fad7ad3f2673724deb20fb420e8bdc03a
encrypted_username T2tBleI3PxuLOoNEwNkv5PZ/rYr5dDIoYZS+We4vER4=

Again the same hash is being used to verify me when I login. I can see an encrypted username is being sent (although I’m not sure why?), rooting around in the javascript I can see the key being used for encyption is SHA(username+password). Importantly this is different to the hash being used to authenticate me – as we don’t want the server to be able to decypt anything encypted by the client, i.e. they would have to know my password to derive the same key on their side.

The form to add a new website:

hasplugin 0
extjs 1
purgeext 0
undeleteext 0
ajax 1
basic_auth 0
isbookmark 0
aid 0
useurid 0
fromwebsite 1
name pyJlY+AX0Aoczlx50hwlHg==
url 66616365626f6f6b2e636f6d
username ICkGIGAn7SIk16iKNkl3DA==
password dl78FYUSIdsxxSdkBuBWEA==
extra faESoIpzmCQg5PeHpXN0GQ==

We can see here the client is sending encyrypted versions of name, username, password, and the extra info. Again this is encrypted with a key we only have on our client – no one at lastpass could have this key. For some reason the URL is being sent in a HEX representation of the string – not sure why they aren’t just sending the string?

So when I log back into lastpass, I can drill down into this entry and see it again. Let’s make sure everything looks okay here. The HTML that renders this screen is available in fiddler:

  <td class='col1'>Name</td>
  <td><input name='name' id='name' type='text' value='pyJlY+AX0Aoczlx50hwlHg==' style='width: 250px'></td>
  <td class='col1'>Username</td>
  <td><input name='username' id='idusername' type='text' value='SgVkuVKH4MjkP+Saz64UhA=='> </td>
  <td class='col1'>Notes</td>
  <td><textarea name='extra' id='extra' rows='6' cols='35'>1rZ3sSuggtdavyCu446GZA==</textarea></td>

The server is sending down our encrypted details, and relying on the client to decrypt everything.

So, yes – you CAN trust with your passwords! Don’t just take my word for it; fire up Fiddler, and compare the hashed/encrypted values with what you expect.

Lastly the c# code to confirm the AES encrypted strings above are geniune.

static void Main(string[] args)
    string username = "";
    string password = "test1234";
    string hash_auth = ByteArrayToHexString(SHA256(ByteArrayToHexString(SHA256(username+password)) + password));
    byte[] hash_key = SHA256(username + password);

    Console.WriteLine("hash for authentication => " + hash_auth);
    Console.WriteLine("hash for encryption => " +  ByteArrayToHexString(hash_key));
    Console.WriteLine("'{0}' encrypted => {1}", username, Encrypt(username, hash_key, ""));
    Console.WriteLine("'{0}' encrypted => {1}", "facebook", Encrypt("facebook", hash_key, ""));
    Console.WriteLine("'{0}' encrypted => {1}", "cryptolearner", Encrypt("cryptolearner", hash_key, ""));
    Console.WriteLine("'{0}' encrypted => {1}", "password", Encrypt("password", hash_key, ""));
    Console.WriteLine("'{0}' encrypted => {1}", "no notes", Encrypt("no notes", hash_key, ""));

static byte[] SHA256(string data)
    byte[] indata = Encoding.UTF8.GetBytes(data);
    SHA256 shaM = new SHA256Managed();
    return shaM.ComputeHash(indata);

/// <remarks>From</remarks>
static string ByteArrayToHexString(byte[] data)
    StringBuilder sb = new StringBuilder(data.Length * 2);
    foreach (byte b in data)
        sb.AppendFormat("{0:x2}", b);
    return sb.ToString();

/// <remarks>From</remarks>
static public string Encrypt(string plaintext, byte[] KeyBytes, string InitialVector)
    byte[] PlainTextBytes = Encoding.UTF8.GetBytes(plaintext);
    byte[] InitialVectorBytes = Encoding.ASCII.GetBytes(InitialVector);
    RijndaelManaged SymmetricKey = new RijndaelManaged();
    SymmetricKey.Mode = CipherMode.ECB;
    SymmetricKey.Padding = PaddingMode.PKCS7;
    ICryptoTransform Encryptor = SymmetricKey.CreateEncryptor(KeyBytes, InitialVectorBytes);
    MemoryStream MemStream = new MemoryStream();
    CryptoStream CryptoStream = new CryptoStream(MemStream, Encryptor, CryptoStreamMode.Write);
    CryptoStream.Write(PlainTextBytes, 0, PlainTextBytes.Length);
    byte[] CipherTextBytes = MemStream.ToArray();
    return Convert.ToBase64String(CipherTextBytes);

{ 10 } Comments

  1. Captain Scarlet | October 18, 2010 at 12:29 pm | Permalink

    This useful program has been around for a while now and I have seen no outcry from users whose data has been compromised, so it would seem to be legit even if I do not have a full comprehension of the methodology. I am happy to let it manage all my many websites that require registration and passwords to access them. It is a major pain once you get past 50!

    One thing I will never ever do is entrust banking and share dealing password security to any such password manager, and these will continue to reside in an encrypted text file. I am a little leery of letting it handle my email passwords, well maybe ok for my anonymous accounts, but my personal and ISP ones I will manage myself.

    If you are in the market for a really secure password have a look at:

  2. russ | October 18, 2010 at 9:56 pm | Permalink

    Hi Captain Scarlet, yes I’d agree that you should keep your banking passwords out of lastpass. It is a very secure process used to store the passwords. But as lastpass gets more popular the more attackers try get into it. It’s very easy to get something nasty onto your computer (lots of PDF, Flash & Java exploits going around). Once something is on your computer I think the game is over for anything storing passwords. Best to avoid something getting on your PC, and mitigate your risk by keeping sensitive passwords like banking completely off your PC.

  3. saschamaj | October 28, 2010 at 2:25 am | Permalink

    Sure, go ahead and store your most private data on an encrypted text file on your computer. But eventually you’ll have to decrypt it and the passwords will be visible, out in the clear, and even if it’s just for a short moment, if you happen to have a virus/keylogger that takes screenshots every few seconds, you’re vulnerable!

    With Lastpass my passwords are never in the clear. I can copy them etc. without having to make them visible. So a screenshot taking virus won’t see anything of value. Also, you can set Lastpass to delete your clipboard after a few seconds.

    Additionally, you can enable multi-factor authentication in Lastpass account settings. So even if someone cracks your master password, they would also have to have access to your authentication grid (a little table with number and letters) in order to log in from a different computer.

    Finally if you’re still paranoid, just use Lastpass offline which is also possible with software they offer on their site. To me there is no more secure and convenient way to store passwords at the moment.
    (Btw, I’m not affiliated with Lastpass, but a little biased maybe, because I have translated it into German, as a volunteer.)

  4. SiNGH | December 3, 2010 at 11:58 am | Permalink

    I really had to say thank you for writing this up.

    I’ve read all of LastPass’ FAQ, etc – but I’ve always wondered if anyone has actually verified that they in fact do exactly as they claim.

    Now it’s confirmed – I’m really happy.

    Great write-up, kudos on posting the code.


  5. Cerberus™ | December 9, 2010 at 2:07 pm | Permalink

    Very interesting, another reason to trust LP! However, I doubt whether we could ever be 100% sure that LP is not decrypting our passwords locally and sending them at a random time once a month to their own secret servers, encrypting it with a special key that only they have on their servers. The moment it installs itself into the browser, it gets permission to do who-knows what to the browser; it might install some secret code into the browser, or just some obscure sniffing code is part of LP itself. I think this is certainly possible, unless you can be sure to monitor ALL that LP does on your computer.

    Failing that, I do not think we can be 100% sure LP is trustworthy based on analysing what it does. So we just need to trust them. I for one am convinced that they can be trusted, because I think someone would find out sooner or later. That said, I trust LP with everything but the sites that can make me pay. Thankfully, my European bank works with a physical device, so no passwords there, which I’d never entrust to anyone, for that matter.

  6. russ | December 9, 2010 at 9:54 pm | Permalink

    hi Cerberus™, it’s true that you don’t know what LP could be doing on your PC. I’m sort of assuming there’s a few other people out there looking at the network traffic it creates. It couldn’t be good for their ‘brand’ if someone spotted it reporting passwords back to their server.
    We could be a bit more confident with an open source solution, the protocol is visibile, so it would be possible to write an open source client. Or skip the lastpass servers altogether and have a open source client store the encrypted passwords on S3, or a server you control.

  7. Mecki | July 7, 2011 at 2:14 pm | Permalink

    This is a great source of information about how LP actually works (LP themselves have no such detailed documentation), but there are some important details missing that you should really add as an update:

    1) There is an option named “Share login state between other browsers”, which means if you have Firefox and Chrome and Safari and you login to LP via either browser, you are logged in all browsers. How can this work? After all only one of these browsers was able to calculate your SHA256 Master Password Hash (MPH), knowing your Master Password. A good hint: For Firefox, this feature only works with the LP extension that has native platform support, it does not work with the platform neutral extension, that is pure JavaScript. According to Joe Siegrist, this feature works by extensions directly “exchanging” the MPH between each other (IPC – Inter Process Communication) and thus is not possible with JavaScript only (since JavaScript has no IPC mechanism across applications). The problem with IPC is: there is no way for a process to securely authenticate another process. You can encrypt IPC communication, but since both sides need to know the key, the key must be hard coded into the binary and thus can be extracted. So if you want to be REALLY SECURE, you should NOT enable this option, since an attacker could write an application that pretends to be a browser plugin (he only needs to figure out how the IPC works and how it is encrypted, if it is at all) and that way gain access to the MPH, that otherwise is well hidden in your browser process space.

    2) There is an option named “Automatically log off when all browsers are closed for (mins)”. If you don’t check it, you can close your browser, open it again and you are logged in. How can this work? All data stored within a process is lost when you terminate that process. Does LP write the MPH to disk? Yes, but of course not in plain Here’s how it works: When you login to LP, the LP servers generate a random key (RK). This key is different for each login. This key is further bound to a session, which has a random session identifier (RSI). The RSI is sent to your browser as a cookie. Unless you tell your browser to wipe cookies on quit, the cookie survives a browser restart. Using the RSI the extension is able to retrieve the RK from LPs servers. It uses the RK to encrypt the MPH and writes the encrypted MPH to disk (the storage location is different on each platform). If you now close and re-open your browser, here’s what happens: If the cookie is still present, the extension uses the RSI to you log you back in, if the session is still present on LPs servers, then it receives the RK, reads the encrypted MPH back from disk and finally decrypts the MPH using the RK. That way you are logged back in and the extension has the MPH back, without you ever typing your Master Password. Needless to say, this also does not work with JavaScript only, since JavaScript cannot write anything to disk like an encrypted MPH.

    If you check this option, you can give a number of minutes. How is that number used? The number is stored on the LP server together with the session. After that many minutes after the last browser has been closed, the LP server deletes the session data (including the RSI and the RK). If the browser is then opened again, it may still have the RSI in the cookie, but that RSI is useless, since the session is gone from the servers, so it can neither log you in, nor retrieve the RK necessary to decrypt the encrypted MPH on disk. If you want to be REALLY SECURE, you should CHECK this option and SET the time to “0”, which causes your cookie to be a session only cookie (browser don’t write those to disk, they won’t survive a browser restart) and further no encrypted MPH is ever stored to disk (I verified that myself). This makes it impossible for an attacker to get your MPH, what would otherwise be possible if an attacker can do three things: Copy the encrypted MPH from your disk, copy the stored cookie to get the RSI, and use the RSI to get the RK before you are logging out of LP (which will also destroy the session).

  8. Amedee | July 20, 2012 at 3:15 pm | Permalink

    Hi Cerberus & Russ,
    I carefully read your comments and I share your concerns about this possible problem. Russ proposes a solution: an open source password manager and syncing the locally encrypted password database to cloud storage under your own control.
    Well, actually… an open source password manager already exists and it’s even older than LastPass so it surprises me that it wasn’t mentioned. As for cloud syncing, it can be synced to S3, DropBox, FTP,… you name it: there’s an extension for that.

  9. Paul Wormer | July 15, 2014 at 1:16 pm | Permalink

    At it is argued that JavaScript (run on the client) is basically unsafe. Not only LP could send you dangerous JS, but also a man-in-the-middle could modify the JS that is sent to you by LP. The latter danger would be diminished if LP would use HTTPS. Still, I do use LP heavily (except for my bank passwords).

  10. Paul Wormer | July 15, 2014 at 1:53 pm | Permalink

    In my previous comment I implied that LastPass does not use HTTPS, however, contrary to what I suggested, it does. My mistake originated from my using Firefox in which LP uses the chrome:// protocol. In Internet Explore I see that LP indeed uses the HTTPS:// protocol.

Post a Comment

Your email is never published nor shared. Required fields are marked *