jpgoldberg

6 ms·

1.
by jpgoldberg 5y ago
To elaborate on what my colleague, Ben, said, we have been in the process moving to more common cross platform code. A it more than a year ago we had - 1Password for Mac and iOS written in Objective-C and Swift - 1Password for Android, wri
2.
by jpgoldberg 5y ago
Another reason for the local hosting is so that we (I work for 1Password) are never in a position to acquire secrets can be used to decrypt your data.
3.
by jpgoldberg 7y ago
Interestingly Microsoft presented EverParse designed to produce verified parsers for these sorts of data formats at USENIX Security 2019. https://www.usenix.org/conference/usenixsecurity19/presentat... But it&#x27
4.
by jpgoldberg 7y ago
I'm hoping that parser generators get more usable. I completely concur that using parser-generators to create safe parsers that will accept all and only valid input is a way to eliminate a large class of bugs. But getting developers to
5.
by jpgoldberg 9y ago
[Disclosure: I work for AgileBits, the makers of 1Password] I'd like to elaborate on the two points made by @epistasis 1. Ability to deliver of a malicious client does not depend on where your encrypted data lives. If you sync over you
6.
by jpgoldberg 9y ago
[Disclosure: I work for AgileBits, the makers of 1Password] Thanks. I (as you'd expect) agree with both points. The second one is particularly challenging. Deterministic builds are possible for some categories of software, but it will
7.
by jpgoldberg 10y ago
It is important to separate three security concerns: 1. Crypto delivered to the browser over HTTPS depends on the integrity of HTTPS. 2. A browser is a very hostile environment (injected JS, other browser extensions, etc.) 3. JavaScript may
8.
by jpgoldberg 11y ago
And now my reply to your first point. Thank you for letting people know that this interprocess communication is readable by something running as root on the user's machine. For those interested in this, please see an article we posted
9.
by jpgoldberg 11y ago
I'm giving a separate reply to each of your questions. This is "Couldn't you just pair it once and then be done with it?" To pair it once would mean that a long term secret would need to be stored. Now we consider oursel
10.
by jpgoldberg 11y ago
You've asked multiple questions. I'd like to give you a separate reply for each. I really really don't like talking about how our competitors might do things. (I work for AgileBits, the makers of 1Password). But I can talk ab
11.
by jpgoldberg 11y ago
Right. This would be unauthenticated with all of the problems that that entails.
12.
by jpgoldberg 11y ago
And where would you store the keys for that communication in a way that an attacker with root privileges couldn't get it? "Encrypting" with keys available to the attacker is mere obfuscation. In this case, it would provide no
13.
by jpgoldberg 11y ago
And where would the secret part of the TLS key be stored? As I've said before, encrypting with a key that is available to the attacker would merely be obfuscating. The only "value" of such obfuscation would be to conceal the
14.
by jpgoldberg 11y ago
You are correct that we are vague about the threat model in this case. But please keep in mind that encrypting local data at rest defends against a whole category of "compromise" (i.e., the data stored long term on the local disk
15.
by jpgoldberg 11y ago
Are you suggesting simple DH without any long term secret? Hmm. I'm fairly sure we thought through that option, but at moment I can't see see/recall why we rejected it.
16.
by jpgoldberg 11y ago
The browser would have to hold on to the shared key long term. Where does it put this? Encrypting with a key that is available to attackers (who have the same set a privileges needed to run localhost sniffing) is not encryption. It is obfus
17.
by jpgoldberg 11y ago
[Disclosure: I work for AgileBits, the makers of 1Password] We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-proces... Th
18.
by jpgoldberg 11y ago
Oh that would be nice. The difficulty is in keeping track of "supported services" and making sure that they haven't changed their password change forms yesterday. Standardized password change forms would make our lives (and o
19.
by jpgoldberg 11y ago
For your second question boils down to "item sharing" versus "vault sharing". Item sharing is more flexible than vault sharing, but it requires more work to see who has access to what. It also involves many more public k
20.
by jpgoldberg 11y ago
Well spotted about the revocation and password change issue. At the moment, the way we address this is through server policy to prevent the user with rescinded access from getting any new vault data from the server. But as you correctly not
21.
by jpgoldberg 11y ago
I remember doing that in the 90s. There was the "password book" locked away in a location I won't disclose in case they still do it that way. We all used SSH public keys (this was kind of new back then), so really only needed
22.
by jpgoldberg 11y ago
It's more of a threat to us than you describe. If a potential team of N people have k members who need a Linux client, then that might cost us N customers, not just k.
23.
by jpgoldberg 11y ago
The web app runs in Chrome, Firefox, and Opera. But nothing native yet.
24.
by jpgoldberg 11y ago
Oh. Never mind. I somehow had it confused with a JavaScript implementation. Not sure how I had that misconception in my head.
25.
by jpgoldberg 11y ago
Notice I said " almost every other crypto library". I had NaCl specifically in mind with that qualification. It's no secret how you feel about crypto delivered over the web and run in the browser, but one of the the factors
26.
by jpgoldberg 11y ago
At the risk of sounding "markety", let me point out the first three bullet points in the overview of our security doc. \item[True end-to-end encryption] All cryptographic keys are generated and managed by the client on your devi
27.
by jpgoldberg 11y ago
Ah, that is better. No promises (and nothing in the immediate future), but this does certainly remain in the realm of possibilities. I don't want to speak for the down-voters (I'm not one of them and I think your comment is was a
28.
by jpgoldberg 11y ago
I think that there are three issues with WebCrypto that people often conflate. But they need to be looked at separately when judging the security of any particular things. 1. Limited algorithms. This is what has use using GCM instead of a s
29.
by jpgoldberg 11y ago
Yep. There is very definitely a reason. You might not like it, but there is. For the moment we need a client that runs reasonable well in web browsers. As libraries become more available or the nature of our clients change, we can switch. W
30.
by jpgoldberg 11y ago
The 1Password For Teams web app runs in Chrome, Firefox, and Opera.

More ›