I am a new user to LastPass and have been reading the literature to better understand how it works. What I do not grasp is how to best use LastPass on other computers.
In the case where you only want to use the web GUI, I don't believe LastPass can automatically fill in credentials/forms nor automatically down-/upload your database (please correct me if wrong). Because you must copy and paste, the risks are leaving passwords in clipboards and having the Vault open to be seen. I think the best practices are to
- Use One Time Passwords, as in all cases.
- Flush the clipboard.
- Presume there is no screen recorder, logger, nor onlookers.
The other case would be installing (or using an existing installation) of the OS client and/or browser extensions on foreign computers. Here, LastPass is writing your (super strongly) encrypted database locally. Does this mean on each foreign computer I am leaving behind a version of my database (daunting)? What do experienced users do to manage this: Extension > Tools > Advanced Tools > Clear Local Cache (I am not exactly sure what is cleared), manually delete relevant files, leave your litter as is? Secondly, are there any fields to be conscious of where the Master Password (if no OTP) is remembered? Finally, is there any conflict with or overwriting of another user's database/credentials (you don't want to ruin their experience afterwards)?
I know one solution is to use LastPass Portable (what I use at home) or possibly LastPass Pocket, depending on if it ever copies the database locally (I don't know). I'd like to limit the second case to not having these options, since it's a common situation when traveling, with a friend, or even at work/school to not have a USB copy.
I hope this question doesn't bother folks as being overly conscious. I am just curious to know how to best use LastPass when I am not on my own stuff. Thank you very much for reading and in advance for any thoughts!
Original post in the LastPass forum.
Correction: I now understand that LastPass does all encryption/decryption locally. That would mean LP sends their copy of your encrypted database and you (the foreign device you're using) decrypts. Even using the web GUI, the database must be "littered" onto it.
Discussion toward Tim X's answer:
Wow! Thank you for your exposition @Tim X, and my sincerest apologies for responding so late. You were very thoughtful. I am neither a security expert nor a programmer, but I'll share some broad-overview information about LastPass.
LastPass (LP) is a cloud-based password manager that has become a mainstream consumer-, and to some extent enterprise-, adopted solution in the last 3 years. This is of course different from popular offline password managers, such as KeePass, as information is trafficked across the Internet and stored remotely. LP operates via local (client-side) encryption/decryption. That is to say, after SSL handshaking with LP servers, the client-side application will only send and receive products of LP encryption. LP has gone to great length to arrange that they never receive user credentials nor the private key that is generated from user credentials and used for the encryption. For login and information-transit, the client first concatenates a user's login email and master password. It then performs a PBKDF2 salted-hash (I don't know the salt's bit strength) at a user-specified number of iterations (5000 is default). A user's password database, or any changes made to it (changes are always local, except maybe in web GUI, which still confuses me), is encrypted under the influence of this key via AES 256-bit. Because LP never receives the private key, they need another way to identify its users. LP performs a second client-side, one-way hashing algorithm (I believe PBKDF2) from the concatenation of the private key and a user's master password. This becomes the unique ID LP employs for first-authentication, but it is not stored server-side (although it would have been reasonable to do so). Instead, LP goes another step, performing a third local hashing, now of the concatenation of a pseudo-random 256-bit token that was shared between server and client at account creation with the user's unique ID. 1) The result of this third hashing, 2) the 256-bit token, and 3) the user's encrypted database are what is stored on the LP servers. The client only ever sends 1) the unique ID and 2) the encrypted database, the former of which is again, not permanently stored server-side (LP servers perform an on-the-fly first-authentication, employing their copy of the 256-bit account creation token).
This methodology is great and is lauded by folks who know way more than me. One of the implications is that no one, including LastPass, has a point of entry without the (presumably strong) master password (or breaking modern symmetric cryptography). LastPass also offers many features @Tim X thought of, including multi-factor authentication and login without your master password. One Time Passwords are random passwords that are generated by the user via LastPass which can be used once to log in before being disassociated; this would be a means of accessing your LP database without ever typing in the master password. This, of course, does not thwart screen recording of the database afterwards, nor the copy-and-paste process @Tim X strongly cautioned against when using a public terminal. I think that is a very important discussion piece, but I also wanted to ask about the following:
A second implication of the LP methodology is that every client (I use the Chrome Portable extension, but there are Windows/Mac/Linux binaries, mobile versions, and bookmarklets) and client computer writes a copy of the encrypted database locally. This is evident from having to perform local encryption/decryption. I am concerned about leaving that (unbreakable, super-valuable) database on machines I don't permanently control. Is there an option to make the database not persistent? Is there a timed mechanism that overwrites with a random key encryption in case your master password is compromised? I don't believe there are any perfect forward secrecy techniques employed by LP. We can imagine a situation where a user is in a compromised master password situation. When they go to change it, can any of the local, unsynced copies update their encryption? (I mean, of course they can't.) That means the user would have to quickly change every password in their database, which is impossible (and just bad technique) considering the average number of online accounts users have today. This is not to mention the unchangeable data LP offers to store in the database, such as text notes and forms containing personal information.
Because of how highly recommended LastPass is (perhaps I should be throwing my question at the those who recommended), I would like to adopt it fully. However, this important concern about littering your databases that can be retroactively opened prevents me. I hope it is a problem that I am just missing information to understand, not one that that lies unasked or in apathy. Perhaps the assumption is users will never, under any circumstance, run LP on a device you won't always control into the future, whether it is trusted or not (similar to @Tim X comment). For the person who doesn't have the premium subscription (which enables mobile apps) or their laptop on them, perhaps the model is "you are out of luck."
@Tim X made two more points, one about the phone and another about risk factor. Using an owned-mobile device to access your database is great advice. It is slightly stymied in this case, because LP doesn't offer their mobile applications to free subscribers (although premium is only 12 USD/year), and I am looking for free in my own recommendation criteria. Using only low-risk accounts with a password manager is a model I will now be adopting too (once I find my PM).