CLI - security?

telephoneman

Hi guys, just a question regarding that CLI. I think its a great thing with that CLI you can even use this for automated scripting in professional scripting environments. (Automation, Login Automation and so on)
But isn't this also easing hackers to try to access the 1Password Database with brute force attacks? And once you are logged in its also easier to "suck" out all data of 1Password database?
Im a bit concerned here if this CLI offers for hackers a better base to steal 1Password Data?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

AGAlumB

@telephoneman: Thanks for reaching out! That's an interesting question. Certainly you're correct that the kind of scripting that the 1Password CLI app enables for users could also be leveraged by someone malicious using tools to automate attempts to break into 1Password.com. But I think it's important to keep in mind that 1Password.com is a public-facing site, so competent attackers can try to do that on their own anyway. And while offering an official app like this allows anyone to "bypass" the GUI in order to try to brute force accounts on the server or a database locally, that's really an artificial limitation and 1Password's security doesn't depend on that.

It sort of reminds me of a question we get fairly regularly: "Why doesn't [the 1Password native GUI app] lock you out after so many failed attempts?" The reason is that would be a purely superficial security measure; the data is still there after all (unless you want us going to extra step of nuking your data...but that opens you up to an easy DoS attack: someone other than you can easily get your data deleted). So having an "incorrect password: maximum number of attempts exceeded" mechanism does little to thwart an attacker who isn't a moron; it's important that 1Password withstand attacks from the most sophisticated attackers.

In that spirit, apart from our own efforts, we've long participated in external audits and cooperate with independent security researchers to find any flaws so we can fix them, before a CLI app was more than just a dream. And the CLI app is also now available to researchers as a means to test our security architecture in new ways. So ultimately the existence of the CLI app benefits 1Password users much more than bad actors trying to attack them. We're focused on not only security, but also giving people control over their data and workflow in as many ways as we can. And this is just the beginning. :)

telephoneman

Are you going to add further security in future? Eg. Sms 2factor, Open auth, certificates etc?

Ben

Possibly. But we want to be sure if we do such a thing that we’re not just introducing “security theater” which can easily be bypassed (like the example brenty gave above re: the app locking you our after a number of attempts).

:+1:

Ben

telephoneman

Yes sure - in my job I also deal with some of this questions

But some proposal

1. the login email is somehow part of the login and without know the email it’s also not possible to access the account -> but emails are probably known by everyone - you introduce an email independent login alias which would make it harder to even know which is your username
2. you could notify the user via email and app push notification when System detects a failed login - if you do step 1 this offers the user the chance to change its username which will lead to unknown to be attacked account (currently the user doesn’t notice when someone is trying to hack his account)
3. Furthermore you could also offer optionally somehow like Apple does with iCloud 2factor that Other devices are required to access the account - this does not essentially mean to be part of encryption - just to access the account. If user is in trouble your support might be able to unlock this. If user doesn’t know it’s masterpassword or account key - ok he is lost then

cohix

@telephoneman Let's look at each of these:

1. The email is not related to the account encryption in any way, so having a login without an email address would not improve the security of the system in any meaningful way

2. That's absolutely something we could do, and I think we have considered it, we just haven't decided definitively to do it yet.

3. This is also something we've toyed with, we haven't put together any sort of plan yet, but it's not impossible.

Thanks for the suggestions, it's glad to hear your concerns and I hope you've been put at ease!

telephoneman

deleted

AGAlumB

:sunglasses: :+1:

jpgoldberg

Hi @telephoneman, I'd like to just sort of pull many of the answers together from this and try to present it in an overall framework.

Your suggestions about notifications on failed login attempts is a very good one. This, indeed, is one of the most valuable benefits of many systems that call themselves 2FA. And we are certainly looking at ways to do this. Likewise, seeking authorization from an already enrolled device to allow a new device to log in. People often don't explicitly understand what the security benefits are and aren't of 2FA. But these sorts of notifications among the most valuable side-effects of some 2FA systems.

On brute forcing, guessing, or scripting

We have to design 1Password under the assumption that attackers are scripting attacks whether or not we build a CLI. Likewise, we have to design 1Password under the assumption that they know our API. As @brenty said, any competent attacker can reverse-engineer those; so we feel that being open about our security design is the best policy.

The design elements we have for the kinds of attacks you describe are in our Key Derivation Function (KDF) and our authentication protocol. With our Two-Secret Key Derivation (2SKD), there is no way an attacker can try guessing a Master Password (even if they obtained the information stored on our servers).

Even if an attacker has their target's Secret Key, there is an enormous amount of computation that is required to test a Master Password guess.

1. First there is the 100,000 rounds of PBKDF2 to process a password guess locally.
2. Then there is a dialogue with our server in which the attacker will need to perform several modular exponentiations of very very long numbers.
3. Finally, if an attacker can really make many fast guesses against our server, our server will refuse to respond to too many attempts per second.

The sophisticated attacker gains very little or perhaps nothing from the CLI. The naïve attacker isn't someone we need to worry about at all.

telephoneman

@jpgoldberg thanks a lot for this explanation. Have a nice New Year’s Eve and happy new year for you all ...

jpgoldberg

You, too! Happy New Year!