I particularly liked this security issue uncovered by Tavis Ormandy which exploited an undeclared variable to trick LastPass into loosening up its API restrictions. There has been a number of reports in the past about that API being accessible by random websites. The response to these calls contains your local encryption key, the one which could be used to decrypt all your server-side passwords.

Not sure how I managed to overlook it on my previous strolls through the LastPass codebase but the getdata and keyplug2web API calls are quite something. So back in November I discovered an API meant to accommodate this context switch from the extension to a web application and make it transparent to the user. Some other extension functionality is implemented similarly. For example, whenever you access Account Settings you leave the trusted browser extension and access a web interface presented to you by the LastPass server, something that the extension tries to hide from you. In particular, the decision to fall back to server-provided pages for parts of the LastPass browser extension functionality is highly problematic. However, LastPass has been designed in a way that makes taking this route very difficult. It is absolutely possible for a password manager to use a server for some functionality while not trusting it. The most severe issues have been addressed, so all should be good now? Early last year I reported a number of issues that allowed subverting LastPass encryption with comparably little effort. The thing is: when your password manager uploads all data to its server backend, you normally want to be very certain that the data visible to the server is useless both to attackers who manage to compromise the server and company employees running that server.

The latest one so far looked into the way the LastPass data is encrypted before it is transmitted to the server. I’ve written a number of blog posts on LastPass security issues already.

Lastpass safari plugin