another breach of lastpass user data / pwds etc all cloud based

fabianfabian

@tomatoshadow2 can you stop ignoring that this discussion is happening in the context of an unauthorized party gaining access to LastPass cloud storage.

If an unauthorized party gains access to 1Passwords billing page server, they can put up a fishing login and happily collect keys until they are caught, which could take weeks or months.

We should never have to enter our keys in a browser, ever. That includes 1passwords billing login page. The secret key should be offline, and stay offline, only used in case of emergency, as a back-up to recover. Going to the billing page is the opposite of an emergency and exposes the secret key to all kinds of attacks, from vulnerable browser extensions, to compromised 1password billing servers.

Tertius3

@fabianfabian

End to end encryption is useless if the attacker has all the keys, the billing page requires me to enter all my keys online

The secret key (as well as your account password) is never transmitted to the website, even if it appears as if you were entering it online. The website is a Javascript app that performs all cryptographic computing in your local browser's sandbox. The secret key is cached only locally in the "local storage" of the web browser and used to decrypt/encrypt any downloaded vault data, which is stored in the browser local stoage as well - still in encrypted form, only decrypted on the fly in memory if you enter the account password, and is forgotten if you close the browser. The key is never sent to the webserver, neither clear or encrypted. The same is the account password: it's never sent to the webserver as well. Both are never known to any online 1Password service, not even on account creation.

I recommend you revisit the referenced security whitepaper from 1Password. If you cannot understand why this design is secure according to current state of the art, I recommend you browse the security audit reports. And if you cannot understand or trust the security audits, I recommend a different password manager. However, if you don't trust what is presented by 1Password, you probably cannot trust anyone else as well, since there isn't much more one can do.

fabianfabian

@Tertius3

The key is never sent to the webserver, neither clear or encrypted.

I can guarantee you that when the billing login page server is breached it WILL be sent. If you don't know how such an attack can happen I don't think anyone should take any security advice from you.

if you don't trust what is presented by 1Password, you probably cannot trust anyone

In older versions of 1Password, much less trust was required, they didn't require entering keys in the browser for a billing page and they didn't require syncing to only their servers. The fact that very little trust was required made it secure in the past. But now they are not much different from LastPass, with similar potential problems ahead.

Tertius3

@fabianfabian It seems you accept a password manager with local storage only. I propose you find one, since 1Password doesn't offer this any more. I'm sure 1Password cannot be talked into offering this again. The thing with the website breach only for the billing page is not relevant, because as soon as you accept integrated cloud storage and sync, the kind of login to the billing page doesn't matter at all.

Zatara214

On the subject of using 1Password on the web, I believe the answer you're looking for comes in the form of Secure Remote Password. Using SRP, secrets like your account password and Secret Key are never transmitted to 1Password's servers.

If you're worried about phishing attempts, it may actually be useful to use 1Password itself to fill your credentials into 1Password on the web. Each 1Password account, when first created, comes with a Starter Kit. One of the items included with it is a Login that contains both your account password and Secret Key. That item can (and should) be used to fill your credentials into 1Password on the web. This way, even if you somehow make your way to a fake copy of 1Password on the web, 1Password will refuse to fill your credentials without a URL matching the one contained within your item.

This actually applies to every Login in your vault, not just the Starter Kit. But it's how 1Password protects you from phishing while you're browsing the web.

jpgoldberg

Happy New Year!

I am joining this particular discussion late, but there are a few things that were mentioned which I would like to comment on.

"hack" v "breach"

My colleague @GreyM1P very nicely pointed out some key security facts that make us different and ensure that even if all the data we hold were to be captured in some breach, it would be uncrackable to the attackers. This is what the Secret Key does. I [wrote about such a hypothetical]https://blog.1password.com/what-the-secret-key-does/() a bit more than a year ago. He correctly pointed out that we have never been breached, but that doesn't mean that we assume that we never will be. As I like to say, we don't plan on being breached, but we have to plan for being breached. I think there are a number of reasons why we have never been breached. I think that the fact that the data we hold is of little use to an attacker means that we are less of a target. But to be perfectly honest, some of the reason may simply be due to luck.

"local vaults" still need to sync

@fabianfabian, wrote

1Password could easily provide a more secure alternative by just allowing standalone local vaults again.

I'm sorry, but I have to disagree. For the overwhelming majority of users "standalone local vaults" reduce security. Unless you are using 1Password on a single device, you have to synchronize your data. The realistic alternative sync mechanisms are simply going to be far less security than using the 1Password service.

For example, users need to authenticate one way or another with their sync service, and that processes is not going to have all of the security measures we have built into authentication with ours. If you send an authentication token to, say Dropbox, it is both known to Dropbox and to anyone who can capture it. This is not the case when you use 1Password, which uses a zero-knowledge authentication protocol. Your 1Password client and the 1Password server construct a new mathematical puzzle each time that allows them to prove to the other that they possess a secret without ever transmitting anything about their secrets. In addition to that never transmitting secrets, the server also proves its identity to the client. This holds up even if the secrecy of TLS fails, and it provides an additional layer of transport encryption (on top of the 1Password data encryption and what is provided by TLS). This is also true when using the 1Password web-client. The processing of your account password and Secret Key is all done within your browser running on your machine. It might look like you are giving those secrets to our server, but the web-client is acting locally in the same way that the native clients are.

It is also designed for our sort of data with APIs tuned to what we need. Instead of having to grab whole files, which may contain much more information than is needed for the particular action, we can make more minimal data requests. In securing the back-end data we can more tightly control who has read access to your encrypted data than a general synching service is likely to do. Let me give you an example.

In the OPvault data format there was a file called keys.js. This file was essential as it contained salts and encrypted keys. It also contained account password hints. We ended up lightly obfuscating those password hints, but not for the reasons you might think. Some people had lines from movies or songs in their password hints, and so their keys.js files were getting removed in the DMCA sweeps that Dropbox was compelled to do. This wasn't Dropbox's fault, but it illustrates the kinds of problems (and there were others with different systems) that come from using a general synching service instead of one build exactly for what we needed.

To the typical user, folder synching is supposed to be transparent. The data appear on "your local disk" just like data that really is on your local disk. But the reality is much harder. For example, we could never get 1Password on Windows to successfully use data stored on a NAS or any sort of network file system. In principle it should have worked without us having to do anything special, but things just didn't work out that way.

I don't know if you ever trying to share a vault with another user before we set up our own service. People tried, and we offered suggestions, but it was a nightmare, including substantial opportunities for security failures.

So maybe you are actually the one in a million who would actually set up your data syncing in a way that is more security than the 1Password service. But my experience in talking to people is that even if they had ideas of how to do that, they never actually did do it.

So for the overwhelming majority of users (including users who might believe otherwise), our synching and service is more secure than the alternatives they would actually use.

PBKDF2 protects your local data

PBKDF2, whether 100 iterations or 100 million iterations plays no role in defending your data if it is captured from our servers. This is not true for other systems, but this is a consequence of our design with the Secret Key. If we were only concerned about data captured from us, PBKDF2 would be entirely unnecessary. Indeed, your account password wouldn't matter either. PBKDF2 in combination with your account password is your line of protection if data is captured from your devices.

Future GPUs and Quantum Cryptography

@noraar wrote

but that doesn't mean it won't be feasible in the future - either via a major advancement in current GPU architecture (which are great for brute forcing things)

Actually it does. If every computing device currently on Earth were turned into the most powerful supercomputers known and they all put all of their efforts Into cracking a Secret Key it would take billions of times the age of the universe to make a dent in the problem. If you were just talking about things like PBKDF2, then I would agree. But the defense that the Secret Key offers is massively asymmetric in the defender's favor.

or the advent of quantum computers (which have already be shown to easily thwart current encryption techniques).

That is a whole other question. I think it is very unlikely that quantum computers will pose a practical threat to cryptography within the next 35 years. But even if I am very wrong about that, if quantum computing does introduce practical breaks of modern cryptography then the threat to 1Password is going to be the least of your problems. Why would an attacker go after 1Password for your banking credentials when they could break into the bank directly. And with the tools that they have, there would be no real difference for such an attacker whether your data was "in the cloud" or not. As your devices would also be targets. In the very unlikely event that quantum computers break 1Password's cryptography, it would break all cryptography. And that includes the places where you don't even know that cryptography is happening.

GaryE55

Part of what was hacked at LastPass was non-vault, unencrypted customer info, like names, mailing addresses, email addresses, phone numbers, and IP addresses. Since the vaults are encrypted, this customer info, IMO, is the more serious issue with the breach. It's identity theft material.

How is 1Password keeping customer info protected from hackers?