LastPass has pushed Google for years to give us a way to avoid using the browser viewport: infobars was a solution to this issue -- you can see one of my pleas for it back in January 2012: https://code.google.com/p/chromium/issues/detail?id=39511

We do a lot to try to protect our usage of viewports using iframes, but it's not good enough and we'll figure out a way to do better. LastPass has generally told people to use the extension directly to login as it's more secure, we'll need to go further here as well.

Sean was clever using http://chrome-extension.pw which looks close -- but LastPass also detects you enter your master password on an incorrect domain and notifies you immediately of your mistake, mitigating this a great deal. This has existed for a long time before Sean's report and we did not implement as a response to Sean's bug report -- we implemented it as a general way for people to know about password resuse and to be notified of being phished.

Making this practical is a lot tougher than email phishing -- you really need an XSS on a page that people use to login, and unlike email phishing it is immediately caught.

Sean here: the mitigation you speak of (notifying the user that they've typed in their master password) is actually another vulnerability.

A malicious page can detect the fact that LastPass put that notification, and then it knows exactly what your master password is without even contacting LastPass. I've told your security team about this but haven't yet received a response.

Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with) once it goes through QA -- likely early next week.

Also even multifactor now must be new location verified so the ability to exploit this is now extremely low. Any attempt utilize those credentials will be blocked an email will be generated just like what happened in the non-multifactor case.

Hopefully you've gained enough attention for the chrome issue: https://code.google.com/p/chromium/issues/detail?id=453093 to be implemented sooner rather than later, if you could do me a favor and follow it to keep the pressure on Google to help mitigate phishing risk we'd appreciate it.

> Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with)

We went through a similar iteration with Password Alert. If you're setting focus on the new tab, an onBlur event could indicate that the current page has lost focus, perhaps due to the warning tab. I think notifying the user is still net-positive for the user's security.

Interesting, I hadn't heard of Password Alert -- we should definitely share notes if you're open to it -- I'd love to be able to generalize what we're doing to other domains if we could -- it's unfortunately cpu intense how we're doing it.

Sure thing, I'm happy to help. Our code is at https://github.com/google/password-alert and feel free to email me any questions at drew@overt.org

However we haven't published a good design document about the client. If you're interested, let me know and I'll try to publish one.

Sending the notification still seems like a better idea than not doing it. If a page has gotten you to enter the password at all then it's pretty likely that it knows the significance before the notification.

But does the page even need to get you to enter it? Could it be possible to set up a hidden password field for LastPass to monitor, and then run a dictionary attack in the background, waiting for the notification?

(I don't use LastPass, so I don't know anything about how this feature is designed.)

This can be protected against by the extension looking at keyboardEvents and verifying the isTrusted attribute. Here are details about how we do this in Password Alert: https://github.com/google/password-alert/blob/master/SECURIT...

Before Chrome implemented isTrusted, it was a bit more tricky and we had to rely on a variety of attributes that did not have as much of a security guarantee.

Thanks for the helpful explanation! Those seem like fair mitigations.

Reading more on it, though, since isTrusted can apparently be spoofed, it looks like the main obstacles are the (2) rate-limiting and the (3) intentional collisions.

For (2), I suspect typical users would have a memorizable master password that's more susceptible to brute forcing, but of course it depends on the actual rate limit and how long you can keep the script running. Alternatively, I suppose a malicious script could overwhelm the rate limit so that the user wouldn't receive a legitimate warning.

For (3), I wonder whether LastPass has a similar mitigation? From what I understand, they don't store the actual password, so all you would need is a matching hash.

I'd be interested to know more details about LastPass's protections.

Edit: I just saw pwman's response above.

> isTrusted can apparently be spoofed

isTrusted cannot be spoofed in this situation, which is its intended use in Chrome. A Chrome extension in the isolated world is receiving events from the main world and checking isTrusted for those events.

Thanks for the clarification. I assume the spoofability applies only to JS in the main world then? And extensions can receive the event before a script has a chance to fiddle with it?

Sorry for the questions, just trying to figure out how this all works, and Googling doesn't give me a clear answer.

Not great, but at that point they don't get your two factor token at least.

Why not? If I suppress the notification, you won't see it. You will then click "Log in" and I'll redirect you to your 2FA screen. I think it's ineffective at what it's trying to do.

> LastPass also detects you enter your master password on an incorrect domain and notifies you immediately of your mistake

Interesting! How does it do this?

I'm assuming by the same mechanism that offers to save previously-entered passwords. It's always sniffing anything you type into a password field.

How would it know it's a password field and not just some text input box that uses * characters?

<input type="password" /> I assume

For what it's worth, I'd definitely prefer logins from new devices to require an email confirmation when 2FA is enabled.

<a href="https://www.seancassidy.me/images/lastpass_login.png"><img src="/images/lostpass_login.png"

I clicked on the thumbnail to examine it more closely, and was briefly confused, then amused that it pointed to the real one.

I think this quite nicely shows why hiding the URL scheme is NOT a good idea; otherwise it would show this, which is far more obvious to indicate that the page is either from the extension or not:

    http://chrome-extension.pw/:/...
    chrome-extension://...

Ironically, it wasn't that long ago when browser designers thought completely hiding the URL bar was a good idea.

This is of the devil. It needs to be burned with fire and the ashes should be sunk in the Mariana trench and the trench should be filled with dirt that has been cursed by a witch that was formerly dead but was reanimated by Cthulhu and then rekilled, burned with fire, and buried on the opposite side of the earth.

Everything here is usual phishing stuff, but that Chrome-Extension.pw url is disturbing combined with the lastpass API stuff.

Where's that quote coming from? It's awesome.

Seems to be ungoogleable. Maybe it's unique :D

Digging it out from the bottom of the Marianas Trench only to rebury it in an inferior location (from an accessibility standpoint) seems counterproductive.

Woah, this is scary. I'll need to look closely at LastPass alternatives (perhaps something that runs separately from the browser, even if it's a little more clunky to use than LastPass's integration).

I'll keep using Lastpass and I'm not sure that this is really their fault, but I have to say this is the first phishing scheme that I've thought "Wow, I would definitely fall for that".

The chrome-extension.pw domain looked almost exactly the same as the Lastpass URL at first glance. I wonder if it would help if Chrome added a special URL-bar designation for extensions.

EDIT: It looks like Chromium has an issue for adding this sort of URL-bar designation: https://code.google.com/p/chromium/issues/detail?id=453093

Same here. I saw the screenshot before scrolling down to see the explanation, and assumed it was the real thing shown for comparison purposes. Very convincing attack.

Edit: assume->assumed

This isn't the first time that LastPass has had security issues and it seems like a fools game to use a password manager that keeps you data in the cloud.

https://www.blackhat.com/eu-15/briefings.html#even-the-lastp...

https://blog.lastpass.com/2015/06/lastpass-security-notice.h...

I've been very happy with 1password, runs locally can be synced directly to other devices. https://agilebits.com/onepassword

Does anyone have experience with 1password security breaches?

I don't think that's a fair criticism of Lastpass for having "security issues" for the following reasons:

1. In the blog post you linked, no user passwords were at risk. They were being abundantly cautious, which makes sense since they hold everyone's passwords.

2. In the talk you linked, this is a inherent problem with storing keys on your local filesystem and not a problem with Lastpass. 1password is also "vulnerable" to this attack.

3. This current phishing attack is not a vulnerability in Lastpass itself, or anything wrong with their cryptography. As the author points out, anyone who falls for this will receive an automatic email notice (if 2FA is not on) from Lastpass and if you have geographic restrictions enabled this attack won't work at all (note 1password does not have these features).

4. Storing encrypted data in the cloud is not inherently a vulnerability, although it increases your attack surface. Many users of 1password also do this with features like Dropbox sync, and Dropbox provides much less rigorous access control compared to Lastpass.

5. 1password has had it's own share of security blunders. The most recent being their database format that leaks all of your account names and the URL they are for, which 1password defended was for "performance reasons". http://myers.io/2015/10/22/1password-leaks-your-data/

EDIT: Updated to mention that alert emails are only sent if 2FA is disabled.

Thanks for the link to the 1password compromise, although, I stand by my point, that compromise is due to extraneous features as opposed to the core functionality. Being conservative myself, that's not a feature I use.

I see 1password's main vulnerability being that someone could gaining access to a device and vault passcode or obtaining that passcode through a keylogger.

I'm not sure how difficult it would be to brute force into 1Password locally but either way it's a low benefit game compared to the potential access with a compromise to a cloud based scenario like LastPass.

But I'm always open to security advice...

> I'm not sure how difficult it would be to brute force into 1Password locally but either way it's a low benefit game compared to the potential access with a compromise to a cloud based scenario like LastPass.

I'm not sure if you're familiar with how Lastpass works in general, but all of the data you store with Lastpass is encrypted in almost an identical manner to your 1password vault. They can't read your passwords.

A "compromise" of Lastpass would require brute forcing each user's vault in order to gain any actual passwords, which would require an extraordinarily long time.

I know it sounds concerning saying "put all your passwords in the cloud" but the reality is that it's no different than using 1Password with sync enabled.

>the reality is that it's no different than using 1Password with sync enabled.

Except that a users LastPass vault lives in the "cloud" so that a compromise of that password can likely open the door and makes it a more enticing target to begin with. Compared the likely hood of merely getting at the 1password vault (assuming it's not synced to the cloud) being a significant barrier.

Again, for me this discussion is educational, I'm curious how having this data in the cloud could ever be considered more secure than local storage.

> I'm curious how having this data in the cloud could ever be considered more secure than local storage

It's not, I didn't mean to give that impression. It increases your attack surface, which is a tradeoff that 99.99% of users are happy to make for the convenience of having instant and strongly secured access to all of their passwords from anywhere.

I meant to point out that this is no different than how the vast majority of 1Password users configure their database: with Dropbox syncing.

For me, this is a required feature to using a password manager. If you do not need this feature, local storage only is better. However, I'll argue that if you have that level of concern then you should also not be using any closed source password manager in the first place.

Are you sure about the vast majority, do you have a source for that?

I use 1pass too and would never consider storing passwords in the cloud, let alone on Dropbox.

I think you may be wrong about #3. The author argues that anyone with 2factor turned on will NOT receive email notification, and I'm not sure what you mean by geographic restriction. You can disallow Tor IPs but that is about it.

Sorry, you're right that 2FA accounts will not receive the email. I've updated my comment.

In addition to the TOR IP block, you can also restrict it to only allow access from select countries. This is what I meant by geographic restriction.

For sites that really matter, don't use lastpass or any system other than memory or a written down hint system.

I believe so far my brain is still the best, if not only, secure password storage. To add a layer of security while reducing password complexity, I coded a small hasher so my brain remembers easy phrases and passwords come out of this tool über strong. I suppose I am still vulnerable to social engineering hacks or the attacker getting a hold of my hasher, but for such cases the only layer left is whatever vendors implement to defend its users, like SSL, 2FA or external devices.

I like this idea. It allows you do something as simple as:

"[password phrase] + facebook"

"[password phrase] + bank"

etc for all of your passwords, and as long as the hasher works well, you have strong, random passwords for everything.

Still, that's just one password. Do you use this one password for all your accounts, or as input to a password manager?

Or are you just manually copying and pasting this one super good hash into all your accounts? :/

Different phrases->hashes for each vendor. The brain can easily remember what short phrase corresponds to what vendor.

I assume you have hundreds of accounts like I and most people I know have. If you can recall hundreds of passphrases, including passphrases for accounts that you don't access for several years, and you can continue recalling these hundreds of passphrases even while changing them regularly, how else are you making use of your exceptional memory? Just curious.

I wish I had an exceptional memory ;)

Only 4-5 accounts require a strong password. The rest I don't care, I use the same password or request a reset every time I go back.

I do the same. However, sometimes that requires a phone call with a wait time of 30 minutes + identity verification =( This is the case with Blizzard.

I make a record of them shrouded in a mnemonic that I can figure out but that would be useless to a stranger.

Up until one of the vendor's databases leaks on the internet and we find out their passwords were stored in cleartext.

I do manually copy/paste.

What do you do on pages that require / forbid special characters and require / forbid length >8 characters?

Thats an easy tweak (global replace the forbidden characters after hash) on the hash generator and for the max length I normally just copy paste the required length.

But how do you know which transformation to apply when you log in? Unless you store the rules for each site somewhere, but then it's not really portable system.

Like I said before: rules are stored in my brain. So far reliable and portable :)

have been tinkering with this idea also something like

   *echo -n 'my unique passphrase' |sha512sum*

only issue is this shows up in your memory and on disk (e.g. .bash_history)

Prefix the command with a space and bash won't save it in its history.

This doesn't seem to be true in 4.3.42, at least not by default. " echo test" shows up in both the output of the 'history' builtin and in ~/.bash_history.

Is it an option that needs to be set?

Yes, you need to have HISTCONTROL=ignorespace option in your .bashrc

great thanks didn't know this one. Just checked and there is also

# don't put duplicate lines or lines starting with space in the history.

# See bash(1) for more options

HISTCONTROL=ignoreboth

sounds like one shall pass: https://oneshallpass.com/

Very much the same (I was too lazy to use anything else than JS!) but my code has some built in tricks ;) What if an attacker constructs a very long list of phrases/term permutations based on one's social engineered data? Then run a loop (with zero restrictions) on 1SP code to get n possible hashes/pwds. That list could have the password! My code has one more layer of security: discover my tricks :)

I like that 1SP is open source. One could download it and add complexity to it! But to use the 'standard' version is a risk.

This is amazing not just for the execution, but the plain simplicity of it. Could you get around this by always clicking on the browser bar LastPass button when you want to login?

I've noticed LastPass will often log out seemingly at random. This is supposed to be determined by a combination of your settings like "only allow one IP logged in at a time", which would log you out if you switched on your VPN for instance. However, it can appear to happen out of the blue, which makes this attack more dangerous, because people are used to that occurring.

LastPass has a binary extension option for Chrome, hopefully they put that to use here with a desktop window that pops up for you to log in. But the fact that they just got bought by LogMeIn (and their reply to this issue) worries me that they won't do anything.

Yes, clicking on the button in the browser's task bar would foil this phishing attack.

Wow. What a well-conceived attack with impressive execution. Hopefully, this helps more than LastPass when thinking about security.

This is also an attack that is possible against MacOS and Windows. My app can make the screen "go dark" or throw up an Apple-looking password prompt.

As I kept saying (and once emailed Steve Jobs about) the way to properly handle this is:

1. Establish a secret phrase or icon when the account is created, that the user can recognize

2. Show it in the iframe when the user places their keyboard focus into the password field

3. Do not allow outside code to grab it -- in browsers, use the cross domain security model, in MacOS use the anti-DRM preventing screenshotting a certain window.

Now, it's true that on the web, the secret phrase or icon has to depend on the user already having a session they've logged into. This authentication prevents an attacker from simply getting the secret phrase or icon.

I have 1Password on Mac and the 1Password Chrome extension. But for typing my master password in, I always use the Mac application. That's because I'm worried that the Chrome extension might be vulnerable.

Are you running a 1Password version <5.0? In 1Password 5 AgileBits added 1Password mini, which is a small helper app running in the background. The point of this is to say that one no longer enters passwords into the extension - toggling the extension merely brings up 1Password mini, which is where passwords are entered. Once the 1P mini is unlocked, it then enters the relevant login info into the browser (by using the extension's functionality, all of which is transparent to the user.

I suggest using the desktop app with global hotkeys for Search and Vault. I got used to it, and actually prefer how I can now seamlessly access login details from a Terminal window.

In my Lixux/Firefox credentials are requested in a popup window. Looks quite different than this. It is worrying that 2FA can be compromised so easily though.