LastPass - Best practices on foreign devices

Question

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

1. Use One Time Passwords, as in all cases.
2. Flush the clipboard.
3. 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).

Answer 1

Without having precise details regarding how Lastpass operates, it is impossible to give a definitive answer to this question. However, there are some things to consider which will possibly allow you to use the software in a more secure manner.

1. In practice, you should consider all foreign devices i.e. those you don't own and control, as being potentially hostile and untrusted. Regardless of how secure the inner workings of Lastpass is, the reality is that at some point, you need to enter your master password, which could be picked up by key loggers etc.

   2. When you use a product like Lastpass, you're not locked in to always using the product. Lastpass can greatly simplify the management of passwords, but you can still enter passwords manually. You can find out what your password is even when it has been auto-genrated by Lastpass. Just because you use Lastpass doesn't mean you cannot login to a service without it.

   3. Not all passwords are equal with respect to threat. These days, we are required to remember/know passwords for a large number of services. However, the risk and sensitivity of all these passwords are not equal. I have some credentials which are managed by a password manager, but which have low value or risk. The password manager is used to make the management of these passwords easier. If someone was to hack the manager and get the passwords, it doesn't really matter to me. Other passwords are high risk and it would be legitimate decision not to use a password manager to manage these sites, preferring instead to remember them.

   4. Not all password managers are equal. Some password managers, like Lastpass, provide a web based password service where you can login to a site and retrieve your password from your vault. Others, like 1password, use an encrypted vault which you tend to store on some sort of shared/mapped drive, such as dropbox. Some will argue that this is a more secure solution as there isn't a web site target which could be hacked. The question as to which would be a better solution depends on individual risk assessments and typical use cases.

Personally, I would never use a password manager on a computer I don't trust. Instead, I would probably have Lastpass available on my mobile phone and if I needed to use a foreign/untrusted device, I would lookup the password using Lastpass on my phone and then enter it manually. However, I don't use foreign or untrsuted computers often, so this works for me. If you regularly use foreign/untrusted systems, this solution could be inconvenient. An alternative solution might be appropriate, such as having an accessible remote host which you access from the foreign device using some sort of remote desktop protocol - turning the local foreign device into acting like a dumb terminal. It all depends on your requirements and level of threat exposure

Note also I would be very careful regarding using any system clipboard or support for cut and paste to get the password from the Lastpass web login and enter it into the login for the service I want to access. Depending on OS and OS version, there are significant security risks associated with clipboards. Products like metasploit have modules which make it relatively trivial to extract data from a users clipboard.

My approach with password managers is to only use them for the low value/low risk credentials I need. I still need to remember multiple passwords, but far fewer than I use to and I like the convenience this provides for the low risk services I use. I don't use my password manager for things like my bank. I also use 2 factor authentication for any service which offers it.

The key point to remember is that almost anything which provides increased convenience has some impact on security - usually a negative one. The trick is in getting the balance right and that will depend on individual circumstances. For me, using a password manager for lower risk services provides a lot of convenience with low risk

Answer 2

Use 2 factor authentication, and make sure you log out when you are done. That way, even if they logged both the password and the time based authentication code, the last one will be invalid by the time you log out (60 sec validity) and you will be safe again.