Hacker News Reader

> they test to see if your database is decryptable with the password you entered (after it is hashed).

At which point they have full access to your database, don't they?

> And you can already read the Lastpass browser extension's source code

Of course, it's a bit more difficult, I'm betting it's minified.

High profile open source encourages people to read the source code, if nothing else. It's possible someone would've noticed that nasty cross-domain autofill bug from a while back (https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...). It's also possible that the community would hold the codebase to a higher quality standard, and a lot of issues would go away (only a rumor, but I've heard that parts of the LastPass codebase are a mess).

You're right but I would like to point out that a few things actually aren't encrypted in your vault, in particular the URL field of the form. I don't really know if they mine that for info but in theory, they could. And obviously anybody having access to your encrypted blob on your filesystem can do the same.

Also, the extension queries the server to know the number of rounds to use while deriving the master key from the password before it'll deliver the encrypted blob to the client, so in theory if they really wanted to break your password they could tell the extension that it's encrypted with a single round of the hash function (IIRC the minimum is actually two) which would make bruteforcing a whole lot easier, although still very much non-trivial.

> it'll deliver the encrypted blob to the client, so in theory if they really wanted to break your password they could tell the extension that it's encrypted with a single round of the hash function

That's incorrect. When you change the round count your master password is re-computed, and database is re-encrypted with the new hash. The server needs to return the round count so the client can generate the correct master password hash, if you ignore that and simply calculate it for e.g. 2 rounds, the master password hash won't match and therefore the AES-256 database won't decrypt.

The way Lastpass works is straightforward... PBKDF2(password, rounds) -> AES256(hash, blob). If the rounds change then the resulting hash changes and therefore the database won't decrypt. Your second paragraph is quite confusing, in that I cannot make heads or tails of why you think you can use 2 rounds when e.g. 10,000 are specified previously. A correct round count is just as vital as a correct password in generating the correct hash.

I'm talking about the authentication to the lastpass server, not the decryption itself.

Lastpass won't serve you the encrypted blob if you don't authenticate with their servers. To do this it computes a different key (using a different derivation function, but using the same "master" password as the encryption key) that it uses to log into the lastpass server.

This key cannot be used to decrypt the blob because of the different derivation function, but the client asks the server how many rounds of the kdf to use for a given user by posting its email to https://lastpass.com/iterations.php . As you can see it defaults to 5000, but the client will gladly accept any value.

Therefore the server can tell the client to send a key derived from only one iteration, it which case this code is run: https://github.com/lastpass/lastpass-cli/blob/623b344e898958...

In other words if an hostile party gets access to the lastpass server they can instruct your client to send your master password protected by two rounds of sha256. If you have a strong password (as you should) it's not an issue, but clearly you can't count on thousands of rounds of the KDF as you might think.

Yeah, implementing a Vault client in the browser is just asking for trouble. Currently, I am copy-pasting into the browser, which has two obvious vulnerabilities: the clipboard, which is accessible to everything, and the login page, which could be running an XSS exploit.

Perhaps we could eliminate both problems, by handling authentication outside of the browser, and then injecting an auth cookie into a new browser tab?

  1. `curl site.com/login` to get the login form as HTML
  2. Extract the form submission URL and the name of the user/pass fields
  3. Pipe a key from Vault, to a URL encoded HTTPS POST request (curl again)
  4. Receive the resulting session cookie and the login-success URL from the login response
  5. Insert or replace this cookie into Firefox's jar
  6. Open a new browser tab to the login-success URL

This way, the browser never sees the password, and the clipboard never holds it. The session cookie is still just as vulnerable as ever, but is of a lower value, assuming that it alone does not grant the ability to change the user's password or PW recovery email address. The entire sequence could be scripted into an `authenticate my-user@site.com` command, which would depend on a connected Vault client (or some other backend scheme). I have no idea if this would work on mobile operating systems, it might not be possible to write to the FF cookie jar from another app.

Thanks for this detailed description!

Is there a way to close the entry point for evil JS? For example, can you tell the extension to stop touching the DOM and injecting any code. That way the username/password can be only interacted with via the browser's chrome button?

No practical one. The extension needs full access to the data in order to push it into a page's forms or to update them via the admin UI ("Lastpass Vault").

I believe the Chrome Web Store does check an extension's signing certificate before updates are published, so security wise that's a good thing, but realistically it remains the weakest part of Lastpass's overall design.

Sure, it can happen to open source; all engineering rules still apply. The attractive part to me would be that there are more eyes on the code.

I would host my own in a google app engine or heroku and avoid a 3rd party who is more attractive to hackers due to the number of accounts they host and potential gain to criminals.

Thats not how many (most?) breaches occur. The situation you would run into (and worry about) is that an exploit is found in the software and then it is mechanized so that things like google app engine and heroku are scanned and user run versions exploited in mass. Open source does not prevent that, only diligent operations do. So by self hosting your are making the bet that you are doing that singularly more competently than the hosted version.

No, open source does not prevent anything. There is just more transparency.

Any self hosting would need to be fully connected with automated update notifications from the "crowd" of contributors and reviewers.

I guess, it becomes a managed service at that point (since as you point out it should have reliable and secure production characteristics which does require a high level of competency). I am imagining a cloud of one for my passwords (a stateless, secure container, with disabled user access to the OS and which connects to an encrypted simple file store to keep my small sized but precious passwords).

Just to be clear: I have nothing against Open Source at all. Open Source is great.

I was just pointing out that Open Source in and of itself isn't a security protection. If you follow the same design you'll have the same design weaknesses, Open Source or closed. The "more eyes" thing, may be true, but I'd argue popularity is more important than license in determining the number of "eyes."

I'd also caution you in assuming an exploit would be against the server side. The server holds a bunch of really hard to decrypt blobs. The client is the real crown jewel. The client browser has all of the usernames/passwords decrypted, so if you were either able to deliver an "evil" extension update, or find an exploit in the existing extension, you could extricate those credentials.

That's the real rub: You turn off extension updates and you're more secure against "evil" extension updates; but you're now more vulnerable to situations where a bug is discovered in the legitimate extension and the organisation pushes a real update to patch that. Auto-updaters in particular are both a huge benefit and a huge security hole.