Hacker News Reader

Comment by devit | Hacker News Reader

It seems dubious that there is a real vulnerability here.

The authors talk a lot about how you can get everything if you compromise the client machine, but of course if you compromise the client you can compromise everything.

Just install a keylogger to get all typed passwords, send the decrypted hard drive image over the network and run it in a VM proxying network traffic via the compromised machine, no need for any targeted attack.

The fact that they focus on that rather than on an actual interesting attack makes me believe that there is no real vulnerability whatsoever.

"We also found how it is possible to abuse account recovery to ultimately obtain the encryption key for the vault" is really scary, but if it were accurate they would be talking solely about that, so maybe it's just a phishing attack.

View on HN

Sounds like one of those "It rather involved being on the other side of this airtight hatchway"

http://blogs.msdn.com/b/oldnewthing/archive/2014/12/17/10581...

There is an account recovery mechanism available to those with a LastPass extension that is or was logged in to the account in question. Dropbox is the same way - if you forget your Dropbox password you can use your logged-in copy to get an authenticated session and change your password.

It will be news if there's an account recovery mechanism that can be exploited by a total stranger without access to your copy of Chrome/FF.

You would expect that 2FA could be bypassed for the locally cached password database, since AFAIK there is no such thing as requiring an OTP to decrypt the ciphertext that you have, only to prove to a server that you know the TOTP secret.

Lastpass discloses that you can turn off 2FA for new logins by proving ownership of an email address. You can set a separate email address for this purpose, and I believe also turn it off.

The fact that it is still a central point of failure that contains the keys to the kingdom is worth noting.

It occurs to me as I write this that for most people compromising an email account would be just as disastrous, given how many services rely on a simple email for password recovery/resets.

> The fact that it is still a central point of failure that contains the keys to the kingdom is worth noting.

I think the difference between someone who uses a password-manager user, and the vast majority of people who don't, is that those who don't have HUNDREDS of points of failure that contain the keys to the kingdom, some completely insecure.

Hardly. "Keys to the kingdom" seems to imply that access to the key opens up a large number of other doors. That's the case for email (via password recovery) and password manager (via its function), but not for much else. E.g. while access to online banking is a catastrophe in its own right, it doesn't unlock many other accounts.

No, the point is, people without a password manager tend to use the same password for every account. So you steal the bank password, and it opens your email, facebook, and everything else. Hundreds of failure points. With a password manager, there is just one.

Human nature being what it is, a large fraction of password-manager users probably also reuse passwords, or nearly reuse them, which is nearly as bad. With the password manager being there for cases where some BOFH admin required two relatively-prime numbers, plus three non-adjacent capital letters, plus at least one special character that's not a star, plus a final character that's not a lower case letter, plus uniqueness with respect to your previous 100 passwords, plus a length of at least 12 characters, plus a change every 14 days.

Assuming that one stores top-tier passwords (banking, primary email) in the password manager. Which is to say, yeah, 99.9% of users.

Which would be fine it more banks used a two tier approach to bank operations. Checking the balance? Username and password should suffice. Making a transaction? SMS token or matrix card or RSA key, all seem fine.

One of my banks (BCR Romania) requires a login with a token for initial access (just seeing stuff, or transfers between one's own accounts) and another token OTP, based on the amount and the last four digits of the destination account, for transfers to someone else.

Royal Bank of Scotland and First Direct use a 2FA device that is authenticated first with your bank card pin (3FA?)

All the devices are the same (across customers and banks), so your card is the second factor, the device is just a reader for it.

I've decided to start doing that (banking at least, not yet primary email), since remembering many high-security passwords is hard, and my bank has 2FA anyway. A keylogger could easily get at all of my passwords anyway, so that doesn't make the threat any worse.

My email account is safe, with 2FA it's doubtful you could access it. My phone in the other hand, is often easily accessible, his password can potentially be broken by looking at grease on it or simply waiting that I unlock it once (which I do really often) to memorize it.

And yet it may be interesting to compare it to competing password managers such as iCloud Keychain. Is it less vulnerable to "master password decryption" part of this attack due to its deeper OS integration?

Not that it doesn't have its own vulnerabilities.[1] But perhaps those are more bugs (e.g. not enforcing sandboxes properly) than architectural weaknesses.

[1] http://arstechnica.com/security/2015/06/serious-os-x-and-ios...

I agree. It doesn't sound so much like an actual vulnerability in Lastpass as much as it is a reminder of how crypto works.

Not everything, my 2FA wouldn't be compromised and if I'm lucky, I would find the keylogger before using the passwords I use less often (bank accounts, servers key passwords, etc...). Personally I would like some sort of hardware password manager, it could even take care of my private keys. Hackaday tried to build something similar but it was too expensive and too bulky.

So it's the old story that desktop operating systems lack process/application separation aka sandboxing.

I prefer hardware separation: just use old smartphone, without connection to internet, as password vault. No connection — no risk of stealing (except physical stealing, of course, so use _old_ ugly smartphone, e.g. with broken screen).

Keep your important passwords encrypted with GPG on flash card, with backup on an another flash card. Regular GPG works flawlessly in terminal. Small shell script, which will ask for password and site name to display site password(s), will do the job on any Linux-compatible smartphone.

This would be really painful. Many of my passwords are more than 20 characters all over the keyboard, and I probably fill in passwords 20 times per day.

Instead, I just use KeePass, which I protect with an offline SSH key as well as a strong password. In order to compromise my passwords, you'd need my KeePass database, access to one of my devices (laptop, desktop, but not phone), and my password.

I think you are right. I am sorry to say I have fallen prey to this flawed argument. I need to migrate to LastPass something I am not happy with and have been stopped a few times because of articles like this one. I'll ascribe it to a lazy approach to evaluating what is being said.

LastPass is pretty sweet. It even has a CLI widget that deploy scripts like Fabric can use to check out credentials and log into remote servers.

What do you mean by >run it in a VM proxying network traffic via the compromised machine?

Yes, of course if your live machine is owned you lose.

However, this means you can potentially recover vaults from unattended / stolen / lost / unwiped hard drives, phones etc.

Only if they told the browser plugin to "store my master password." That shouldn't surprise anyone -- if the master password is stored somewhere that the plugin can read it without any additional decryption keys, so can an attacker.

I guess you could setup two factor auth. locally without a third party...

Reply on news.ycombinator.com