Two apps, two keychains?
It'd be fantastic if my wife and I could each keep our 1Password keychains on her iPad (which she allows me to borrow on occasion), and I'm thinking that it may be possible now that there are two 1Password apps on the device (assuming that one is set up to sync to her Dropbox account and the other is set up to sync to mine).
Comments
-
Just thought I'd mention that this is working extremely well for me. Indeed, I am enjoying the ability to do in iOS two things that I cannot do in 1P/Mac or 1P/Win: keep two different keychains on my device (one in each app), and, in either app, change keychains with no apparent side-effects or problems by resetting the app and then connecting it to a different Dropbox account.
I understand that the architecture of the Desktop apps, where the app must coordinate with the browser extensions, is radically different from the architecture of the iOS apps, so that what is pretty simple to implement in iOS would be anything but on the desktop. I'm just saying that, in this respect, 1P/iOS is a real pleasure, and that it really highlights what we users of the current desktop apps have to do without. As you know, I have another solution for the desktop that works reasonably well for me, but it sure is nice not to have to resort to such work-arounds on my iPhone or my wife's iPad.
Flag 0 -
Hi @Benfdc,
That's great to hear, thanks of writing back and letting the folks know here.
I generally create a separate OS X or Windows account on my Macs to switch between two different databases, but it won't fit everybody's need as my separation is due to one being for personal use and the other one for work, so they can easily be separated for my needs.
Flag 0 -
I use multiple user accounts too, but it's not a good solution for when you want to connect to a keychain on an ad hoc basis and can't really justify maintaining yet another user account on your machine. I have considered using a guest account for this sort of thing but fear that it could mess up Dropbox, which likes to keep track of all of the devices that sync to any given account. So for ad hoc lookups I use 1PasswordAnywhere, but of course that is a read-only solution.
Which is why I find LastPass to be such an excellent complement to 1Password. It is just fantastic for situations where one needs full read/write access to different keychains (vaults in LP-speak) on an ad hoc basis.
Flag 0 -
Hi @benfdc,
If you just need to read the data on the fly and not make changes, you can use 1PasswordAnywhere instead. Log into the other account via Dropbox.com and access your data there for a quick peek or copy/paste action.
Flag 0 -
The "problem," if you will, is that I help a good number of people with their password managers, and in that context read-only access is of limited utility. If the person on the other end is using 1P/Mac, screen-sharing sometimes works as a solution, but If the person on the other end is using LastPass, I can get into their vault at any time with no problem.
What I am now seeing very clearly (thanks in part to our back-and-forth in this thread, which has focused my thinking) is that 1P/iOS provides me with a way to manage somebody else's 1P keychain without having to create a dedicated user account on my Mac. It's not a perfect solution given the limitations of 1P/iOS (e.g. no support for tags), but it is definitely going to come in handy. Especially since I can load someone else's keychain into 1P/3 without sacrificing access to my own in 1P/4.
Requests for keychain switching, support for multiple keychains, and support for shared keychains are a staple of the 1P/Mac forums, and I would be surprised if the same were not true of the 1P/Win forums. Agile's response in these threads is almost invariably some variation of "we don't discuss new features before we release them.” I have sometimes mentioned LastPass in those threads, and indeed have sometimes openly questioned (but can understand) Agile's reluctance to do so. Now you have an in-house solution!!
Flag 0 -
Hi @Benfdc,
Yep, that's a very ingenious workaround for now. The other thing I can think is that if you're working with the same folks a lot, you could create a small virtual machine that connects to their data files via Dropbox and use the full 1Password for OSX app to modify their data as needed.
There's a cool app called Switchup, where it can let you switch Dropbox accounts in the same Mac and 1Password can switch to it. You just have to avoid enabling the browser extensions there.
Flag 0 -
Keeping my "support user accounts" in a VM is a very interesting idea—it would allow me to work on someone else's keychain without the disruption of having to log out of my own account, and I am pretty sure that it would be kosher under Apple's Mountain Lion license and both of my 1P/Mac licenses (family & App Store). I already run Windows 7 in a VirtualBox VM, but frankly 1P/Win sucks at keychain management (or at least it did the last time I tried to work with it, which was over a year ago—no tag support, no 1PIF import of anything other than login items, no equivalent of ⌘D, etc.) so it wouldn't be of much use to me. I've never built an OS X VM, and I'm not sure it's worth the effort to build one just for this purpose, but I am definitely going to keep it in mind. Thank you very very much.
I'm not enamored of your Switchup solution. If I am following you, the idea is that instead of having a separate user account for each keychain that I maintain, I can maintain a single "1Psupport" account in which I juggle multiple keychains. It's a cute idea, but without enabling the browser extensions my ability to test and troubleshoot would be badly compromised.
Flag 0 -
Hi @Benfdc,
The full 1PIF import has been added in the latest beta for Windows app, it's coming soon in the next stable version.
The idea is that you build the items in your regular OS X account, export the selective items and drag it into the VM to import it, that way, Dropbox'll sync it to the other side. However, I found out that Parallels doesn't seem to support dragging items into the OS X VM, so it's a bit of a hassle to move files in there. Windows VM would work fine, so if you update your Windows client to the latest .318 beta, you'll be able to import any items.
Flag 0 -
That is great news. If I had a lot more time on my hands than I do right now I would spend some of it beta-testing (I'm good about pushing limits and giving feedback), but I don't so I won't. But once this enhancement is released I'll be able to send out 1PIFs to my peeps rather than having to work with their keychains on my Mac. Big improvement, and should reduce (although not eliminate) much of the need for the stuff we've been talking about here.
So, how much longer are we going to have to wait until encrypted 1PIFs hit the beta channel? (Just kidding. I know you wouldn't tell me even if you knew.)
Flag 0 -
Hi Ben,
Encrypted 1PIF would be very nice to have. At the moment, the nature of it being a safe export/import format requires it not to be encrypted but having a separate encrypted format for sharing is something we'd like to do.
Be sure to use a secure channel to send the 1PIFs to your peeps, something like iMessage/Skype rather than emails which would place the data at risk.
By the way, keep your eyes out for the next update to 1Password 4 for iOS, it's going to have a nice feature related to something like this.
Flag 0 -
Will do. But the lack of encrypted 1PIFs continues to be a very sore point with me (you suggest that it is technically infeasible, but I can't conceive of why that would be the case), and reading the words "having a separate encrypted format for sharing is something we'd like to do" makes my blood boil. YOU HAD ONE UNTIL YOU ELIMINATED IT.
The one and only thing that Agile has done over the years that really ticks me off was dropping the File > Export Selected > Encrypted Web Page function in 1P/Mac 3.6 without providing your users with encrypted 1PIFs or some other reasonable alternative means of secure data exchange.
Export to Palm/Treo, which I suppose could also function as an encrypted format for sharing although I never really thought of it that way until just now, was also dropped in 1P/Mac 3.6. This annoyed me too, but by that time the Palm platform was already in its death throes. I also understood the failure to include Palm export in 1P/Win—it would have been nice, but it also would have made no sense for Agile to prioritize it.
But taking away 1Password's only built-in tool for secure transmission of passwords, credit cards, and the like? I didn't understand it then, and I still don't. Maybe encrypted web pages weren't entirely bulletproof given the increased power of cracking hardware over time, but surely they were still far, far better than leaving your users naked. Thank goodness for LastPass is all I can say, but I also keep a copy of 1P/Mac 3.5.9 on my laptop, and I fire it up every now and again when I need the old export functions. I expect I will still use them even after we get something like encrypted 1PIFs, because not everyone that I communicate with has 1Password. A pity, to be sure, but true nonetheless.
I don't consider sending plaintext 1PIFs by iMessage or Skype to be an acceptable practice. Transmission may be secure, but it leaves the data in the clear on the sender's computer and on the recipient's computer. Both sides have to securely delete the 1PIFs, which is a pain in the neck for me and something over which I have no control on the other end. Sorry, but I don't think there is any tenable argument that File > Export Selected > 1PIF represents an adequate replacement for File > Export Selected > Encrypted Web Page. Neither does 1PasswordAnywhere, because at the present time there's no easy way to use it to share a subset of your keychain [hint, hint].
Somebody here (Khad, maybe) suggested printing stuff to an encrypted PDF, which can then be safely emailed and is in a secure format on both the sender's and the receiver's systems. This actually works quite well in some contexts, and is almost certainly the best option available to the average user of 1P/Mac 3.6 and later for secure transmission of data stored in 1Password. But most users wouldn't think of it on their own (I know I didn't), it still leaves 1P/Win users in the lurch, and to the best of my knowledge Agile doesn't generally promote it.
Flag 0 -
Hi Ben,
We removed it because it was using an outdated encryption library which is why the Palm app could read it. We were not confident that it was secure enough in the current age and time, so we removed it completely. Not because of Palm but because we couldn't say it was encrypted.
People assume when we say encrypted, it's strong enough, so we can't leave it like that and people would practice using it without knowing that it wasn't strong enough. You might as well go with the unprotected format in this case.
I'm not sure what the encryption is used in Preview's PDF encryption right now, I believe AES but I'll ask Jeff, our security guy, who might know. In the past, it was using a weak encryption protocol that it could be broken in minutes.
I wonder if you could use something like TrueCrypt to store 1PIF files in and email it over. Jeff might have some better ideas.
Flag 0 -
Yes, I can use TrueCrypt. Heck, I can use PGP (actually GPGTools, but whatever). But can the person on the other end? I can also use an encrypted DMG, with or without Knox, but 1Password doesn't automate the process [hint, hint] and besides it only works if everyone else is using Macs. I could use Encryption Wizard, which is actually very slick, but it requires Java and I will never ever encourage people to install Java on their machines.
My understanding is that encrypted PDFs created in the last few versions of OS X are secure if you choose a good enough password, and that the same is true of encrypted DOCX and XLSX files. But Jeff would know those things better than I!
If Agile had encouraged the use of encrypted PDFs when it dropped Export Selected > Encrypted Web Page, I imagine that I would have been OK with that. Not thrilled, maybe, but OK.
But that's not what happened. Agile's stance was (and so far as I know continues to be) that 1PasswordAnywhere and Export Selected > 1PIF were adequate substitutes. And they are not.
Flag 0 -
Thanks for letting me know that .pdb files are not to be trusted. Maybe that has been said here before, but if so it didn't sink in. I retired my Trēo a few months ago, so I don't imagine I'll be needing them any more. I kept them in my Dropbox. I guess I should purge them now, eh?
Flag 0 -
Hi, Khad! If I need a fresh .pdb file some time down the road I would just fire up 1P/Mac 3.5 and generate it. But now I am wondering how the devil one securely deletes a file in one's Dropbox. If I securely delete it on one device, I don't think it will be securely destroyed on the others. My best idea at this point is to overwrite the file, let that propagate to all of my devices, and then go to Dropbox.com and do a purge (delete all stored versions of the file). But I don't know if that works—is there really any such thing as overwriting a file in a modern, journaled file system? Maybe it would be better to take each device offline, do local secure deletions everywhere, and then purge it in the cloud.
Is there a settled "best practice" for this sort of thing?
Flag 0 -
Hi benfdc!
You are absolutely correct that we don't have a nice solution for securely exchanging 1Password data with other people (or other accounts). 1PIFs leave your data unencrypted, and secure erasure can be tricky. I honestly don't know of a recommended Dropbox procedure for that. Secure Erase is even getting tricky without Dropbox, as it may not do what you expect on SSDs either.
You really hit the nail on the head with your observation that you can use GPG or whatever, but you can't guarantee that that is what your recipient uses. GPG is what I would recommend for cross platform encryption, but even with GPGTools (which is great), it isn't the easiest cryptographic system out there for people to use. And so, you would have to teach your recipient to be able to use it.
The things that make GPG hard to use would also affect an encrypted export in 1Password/ Back in the mid 90s I was a huge GPG (well PGP in those days) enthusiast. I believed that we could solve a huge number of problems if people just started to use PGP. Furthermore, I was an email administrator at a technically oriented post-graduate university.
I had the best imaginable situation for getting people to use PGP. I could provide official support, encouragement and training. I had really smart people who were concerned about email and file security. Despite these ideal circumstances, I failed. Now some of that can be that I wasn't the best of teachers. But I think it shows that this stuff gets hard or at least annoying for people quickly.
(OK the circumstances weren't completely ideal. I was hampered by the fact that I couldn't actually give anyone any of the software or do the installations, as I'm a US citizen and this was in the UK. So a colleague could hand me a disk with PGP or an SSH client on it, it would be a serious crime for me to hand it back to him. Still, one of my colleagues and I used to make a show of that. We had a routine where he would hand me the disk, but then I couldn't hand it back to him or use it to install stuff on our victim's computer. Of course, he had a second disk with him that we used.)
One of the things that was both hard and terrific for me to learn when I started working with AgileBits (then Agile Web Solutions), was to keep things simple. Too many power options lead people to use things poorly. PGP was written for people who were a lot like the people who were writing it. It was written for people who wanted to understand the subtleties of trust models and session keys. What I love about what we do here with 1Password is we bring top notch encryption and security to people who don't need to know the inner details to have it work for them.
So with that said, we know that there is demand for secure exchange of 1Password data, but we also know that we need to get it right. I can't make any promises about any plans, but it is something that we know people want.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.comFlag 0 -
Hi, Jeff! Great to hear from you.
Question 1: What are the pitfalls of using "Print-to-password protected PDF" as a sound solution to the problem of "how do I to securely circulate information from my 1Password keychain?" For example:
- Is there a rule of thumb along the lines of "Yes so long as you are using OS X 10.x.y or later."
- Are there easy-to-use and readily-available tools that can inspect a PDF file and tell you whether it was encrypted with RC4-40, AES-128, or AES-256?
- Are there APIs that 1P can hook into that would allow you to add "Encrypted PDF" to the File > Export Selected > menu, making the process somewhat[!] less error-prone than hoping that the user manages the OS X print-to-pdf dialogue boxes properly?
- Can we please, please have a preference pane that allows us to choose the font used when printing from 1P/Mac? Why should iOS users have all the fun?
Question 2: Unless and until you come up with an encrypted 1PIF file format, why isn't the default behavior of File > Export Selected > 1Password Interchange File… to create a password-protected .dmg volume into which the data is written?
- It seems to me that this is something that Agile knows how to do.
- I'm envisioning that the Export dialogue box would have a checkbox for creating a .dmg for the 1PIF that is checked by default, with the program popping up an alert message if the box is unchecked emphasizing the need for secure handling and disposal of naked 1PIFs.
- I know it's a Mac-only solution, but the perfect is the enemy of the good.
- If at some point down the road you guys come up with a way to create a password-protected .tc volume, the .dmg checkbox could become a .dmg / .tc / no container radio button.
—Ben
p.s. I'm somewhat familiar with "Shabbos goy" protocols, but yours is the first "crypto goy" story I've heard!
p.p.s. I've never worked in a production environment where PGP was in common use, but my wife does, and it is appalling how often she receives files that are packed or ASCII-armored but not actually encrypted.
Flag 0 -
Jeff—
I seem to recall you or someone suggesting at some point that the security of Encrypted Web Pages was seen as eroding. Maybe because they didn't use PBKDF2 or something.
If secure deletion is becoming problematic on account of the proliferation of SSD-equipped Macs, then one might argue that export of naked, non-containerized, plaintext 1PIFs has become unacceptably insecure and should be dropped from 1P/Mac.
My point is not to advocate that Agile drop plaintext 1PIFs, but I am suggesting that, net-net, maybe it would make sense to revisit the security argument for dropping File > Export [Selected | All] > Encrypted Web Page. Especially if File > Export [Selected | All] > Secure PDF is infeasible.
Flag 0 -
People assume when we say encrypted, it's strong enough, so we can't leave it like that and people would practice using it without knowing that it wasn't strong enough. You might as well go with the unprotected format in this case.
You could look at it that way, but here is another way. By taking away File > Export Selected > Encrypted Web Page without supplying or suggesting alternatives, Agile relegated its users to "roll-your-own" approaches. Not good. You now send 1PIFs via Skype. This is better security-wise than Skyping (or even emailing) an encrypted web page? I think not.
I suppose one might say that, with Agile having removed encrypted webpage export from the product, my launching 1P/Mac 3.5 to encrypt passwords and such for distribution via email or whatnot also qualifies as "roll your own." To that I would reply "point taken," but that only serves to reinforce the point that we users have now been left to fend for ourselves.
Flag 0
