Hacker News new | past | comments | ask | show | jobs | submit login
Discovering LastPass shared passwords (changedmy.name)
72 points by zdw on Oct 27, 2013 | hide | past | web | favorite | 35 comments



Cannot argue with the results. The whole concept is "impossible" to begin with since even if LastPass hid the content for the development bar (on the LastPass UI) they would eventually still have to submit it to the third party site and you could use the Network tab to grab the raw HTTP request right out of the air.

So I am fine with this weakness. It doesn't impact their core product. This feature is still vaguely useful for less technically literate people, but maybe needs some kind of disclaimer.


The sharing feature is legitimate, implying that they can hide it from the sharee is not.


Agreed. On the other hand, I've used it to share passwords with non-geeks, and I wouldn't expect them to be able to retrieve it just with the Chrome inspector. That is the surprising part of the article, at least to me.

I would like to see at least that part fixed, anything else is fine by me at least (if you want their browser to login, the password has to go through the network at some point, so there's really no news here).


Non-geeks probably don't know how to use the chrome inspector, right?

Well, they do if they find instructions to follow to do so to retrieve a LastPass shared password.

I would expect that, no matter how they try to obscure it, it will be retrievable even by non-geeks who find and follow specific instructions to retrieve it.

So I'm not sure how much development effort it's worth to try and obscure it further -- if that's even possible.

LastPass probably ought to be VERY very clear that it's merely slightly obscured, not truly protected, from someone you share it with. Mainly because if someone is confused about this, when they find out it's less protected then they thought, they may begin to doubt LastPass's security in general.

If I were LastPass, I'd reduce the level of obscuring going on, to try to make it even more obvious that a shared password is not protected from the sharee.


IMHO LastPass is clear about it. They say: "Savvy end users could potentially access the password if they capture it using advanced techniques during the login process". I think this sentence conveys the correct meaning to most people reading it (programmers should understand that the feature is not real security just upon seeing it).

I agree that most end-users won't know how to use the inspector, but that's really two clicks on a window of their browser. The blog also goes the complicated way with javascript, but the easiest way (also mentioned) is really really easy: right click on the password, inspect element, click on "properties", scroll down.

Using wireshark or modifying /etc/hosts with a custom html file is surely more complicated.


But what if those non-geeks have other geek friends besides you who are able to retrieve it and have temporary access to their computer?


In that case, it's just like if the feature didn't exist.

I think it's pretty clear that the feature is just obscurity and works only in simple cases. It was pretty clear for me at least from the moment I saw it, and it's clearly written and explained.

Does it make it useless? I don't think so. I'd rather LastPass keep it the way it is (maybe closing down the most simple way to retrieve it, like the inspector) rather than removing it altogether just because it can't be a real security feature.


You could probably proxy the login form via the lastpass server which would insert the correct password and perform the login before passing back the logged in state to the browser.

Perhaps there could be issues because of the origin domain of the cookie though.


We are also using lastpass at it is simply comfortable for sharing accounts. I fully agree that there will always be a way to sniff the details if you are using such a centralized password manager for web-login.


We do this differently at Meldium (YC W13) and reliably provide a way to share passwords without end-users seeing them. The login occurs on the server side and only the session is transferred to the sharee's browser. Thus, the password is truly never shared or sent down over the wire.


This is interesting and certainly solves the problems mentioned in the article. However, it does introduce a whole bunch of new attack vectors.

Have you thought about the idea of selling the product as a machine that clients can run in house? Something that is only accessible to them, similar to how GitHub enterprise works.


We definitely intend to provide the secure vault component as something you can host internally (exactly like GitHub Enterprise).


This points to what is actually quite a large problem with the LastPass vault. A lot of people I know (myself included) keep the password saved on the vault, so that it will offer to AutoFill/AutoLogin when you visit a site you have an account on. It then is set to re-prompt for the master password to actually fill or reveal the site's password.

Unfortunately, passwords are retrievable out of the LastPass vault in exactly the same way as in the article. It is trivial to simply inspect the DOM and pull them out with some basic JS. This is unacceptable IMO and must be fixed; LastPass is barely functional if you don't keep it logged in. But if you do, all it takes is a right click and a few keystrokes to reveal each password.

I feel a lot worse about this product, now.


In what way could any password manager both auto-fill login fields on a web form and also prevent DOM inspection from revealing the password? It seems flatly impossible to me.


This is not what is being claimed here.

I do the exact same thing STRML with my lastpass vault. Lastpass has a bunch of fine grained access controls for when the password needs to be entered. Having your password saved on lastpass just lets you view your list of password, as long as you have it set to require the master password before accessing an individual password.

Here is how the process goes for logging into a website with these settings:

1) Go to website

2) Click autologin

3) Type your master password

4) Lastpass fills in your password on the website and logs you in

This clearly involves your master password before doing anything that would seem to reveal your individual website password. The problem here is that this would appear to be completely false as the article points out.

Another way to get the password in lastpass:

1) Open the lastpass vault

2) Search for the target website

3) Click edit

4) Click the eye icon to show your password

5) Type in your master password

6) See the password

Once again, exactly as you'd expect, and seems to require the master password before revealing anything. The problem is that you can replace steps #5 and #6 with (in chrome):

5) ctrl-shift-j (brings up dev console)

6) $('input[type=password]').setAttribute('type', 'text')

And now your password is sitting there in plaintext without ever requiring your master password, despite telling lastpass to require your master password for any password access.

I agree with the rest of the commenters that sharing a password with someone and expecting it to remain secret is a bit foolish, but the problem I described here is a HUGE vulnerability. I'm going to seriously reconsider using lastpass ever again.


So the LastPass vault itself is a web application? If that is the case, I'm a little flabbergasted.

I use 1Password (not associated with them at all, just a reasonably happy customer). The 1Password app is a native application which as far as I know has no vulnerabilities like this.


The correct way of using LastPass (or, actually, your computer) is to lock it if you leave it on the table or hand it to a friend.

All hell break loose if you hand a logged-in computer to a friend, the security model of all operating systems don't account for that.

If you follow this basic security principle, you can keep your LastPass vault logged-in, with a decent timeout (eg: 1 day).


Breaking account locks on Windows is pretty simple, and full-disk encryption is not as easy to pull off as it is on OSX. If someone were to steal the computer, they would have as much time as they needed to break the Windows account and raid LastPass. What else could be the point of the master password reprompt, but to give the perception that your passwords are locked after an idle timeout? If it doesn't actually work, they shouldn't have the feature at all.


I'm not suggesting to activate the feature that asks you to reenter the master password to USE a specific password. I'm suggesting that you force a logoff of your LastPass vault after inactivity.

Using a laptop with full-disk encryption, I think 1-day logoff is more than enough for common scenarios (we're not speaking of NSA-going-after-you, as usual).

If you're using a laptop without full-disk encryption, I'd agree that the best way is to configure LastPass to automatically logoff when the computer enters standby/hibernate (for enterprises, this kind of configuration can be enforced for all business accounts as a policy). That's still a much better compromise than having it always logged off and having to relogin for any password you use.


However, if you do "break-in" without knowing the password you may gain access to most data, but not data encrypted with the user's auth; stored passwords (hopefully including lastpass stores) typically are therefore not accessible.


I always assumed that the option only determined whether or not they were given the ability to click and view the password in the LastPass UI. The password must necessarily exist on their computer in an unencrypted state in order to fill out a login screen. It seems really strange to me that people would assume there was a way for it to be securely hidden from the user.

Either way, sharing the password assumes that you are giving them the ability to login to your account. If the person you share with wants to give the password to someone else, it doesn't matter if they can see it or not. They can just share the password to their LastPass account. In other words the fact that they can see the password doesn't change anything from a security standpoint.

I suppose the one exception is a situation where you wanted to use the same password for your email and your bank and only wanted them to share access to your email but not let them see the password so they couldn't log in to your bank. This has a lot of security problems even if you aren't using LastPass or sharing your passwords. LastPass does warn you not to use the same password on multiple accounts unless you explicitly turn the warning off.


I use KeePass with a password vault stored on SkyDrive but I would never use LastPass. The web browser opens up so many attack vectors that I don't trust anything they do.

I know one person that used to use LastPass. He was a coworker that would utilize it on a shared terminal server and he would select the option to remain logged in. I logged in as me on the terminal server, copied his Chrome cookies file to another account and was immediately able to log in as him to LastPass and access every single one of his passwords. He deleted his LastPass account that day.

There are plenty of ways to address this and other inherent security issues with it but I don't see evidence that the majority of non-technical LastPass users are utilizing any of them.

Here's a discussion that I found about the issue I discussed on LastPass' forum:

https://forums.lastpass.com/viewtopic.php?f=6&t=33329


So this "one person" deliberately made his LastPass account insecure by selecting "the option to remain logged in" on a "shared terminal server" and it's the fault of LastPass?

Sometimes you simply can't protect end-users from themselves.


This sounds like the kind of "security" feature that will show up on a criminal court case in the future -- that's why I don't like it.

Think about how easy it will be for a company to prosecute the "hacker" who was able to circumvent the security of highly-reputed LastPass to do whatever minor thing they did. LastPass uses strong cryptography and blah di blah blah, after all, so this must be a hard-core hacker who needs to be made an example of.

I understand why the feature is useful -- it's a sort-of "honesty lock" that's easy to get off, but it's obvious to the user that they're not supposed to take it off -- but LastPass should change the language around it so that non-technical users understand that regular people, non-experts, can bypass it.


I love LastPass and like sharing access to my accounts this way, but I don't even know why they have this option and it's turned on by default. This option is trivial and they should just get rid of it.


I love LastPass...but I don't even know why they have this option

What is your love of LastPass based on? I suspect it's based on trust. But here's what we have: a company states that you can share a password and the "password will remain a secret" but it's anything but a secret. Doesn't that erode your trust in the company - just a little bit? What other security assertions are they making that are just plain wrong?


Did any of you actually expect that you could share an account (a username and password) without one party knowing a piece of the information?

Whether through burp or through Dom inspection there is not much possibility to share an account without them reading the password.

The feature of sharing an account is, by definition, insecure.

The best solution, if you must share the account, is to use LastPass and change the password after they use the account and let LastPass remember the new password.


Did any of you actually expect that you could share an account (a username and password) without one party knowing a piece of the information?

Most technical users would not believe this. But here's the problem. This is what LastPass says when sharing the password:

password will remain a secret

So it is rational to believe that the majority of users will believe (since they are told this by LastPass) that the password will remain a secret.

And this misses the most important issue. What other claims are LastPass asserting that are easily falsified?


In my examination last pass does a good job with what it does and I know it has held up under scrutiny from various infosec professionals (you can find some blog posts from nova hacKer's)

You can also code audit them by installing their chrome extension and finding where it's installed


it has held up under scrutiny from various infosec professionals (you can find some blog posts from nova hacKer's)

Thanks for the additional information. I was honestly incredulous that any security professional would recommend LastPass for important things like bank credentials so I did some Googling specifically for the one you mentioned:

https://www.novainfosec.com/2011/11/15/new-multifactor-authe...

Although I probably wouldn’t store high value passwords using an online service like this, LastPass provides an simple way to use different strong passwords for every site you need to authenticate to.

This is exactly how I think about it. Online forums? Sure, LastPass is probably great. Online banking? No. Brokerages? No. Web-based email? No.


This is why we have looked at services like https://www.meldium.com/ but unfortunately (because of the way it works) it doesn't work for arbitrary services, only for ones they have done an integration with.


Anything we can add for you to get to full coverage?


You also can just use 1password to save the field that was filled in by lastpass, then log into your 1password and copy saved password.


How does this compare to the way that sharing is implemented in PassPack?


Totally different beast. The issue here is that LastPass claims they can hide the password from the person you're sharing it with. Passpack makes no such claim. When you share a password with someone, they see it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: