Open 1Password 4 attachments without saving?
Hi,
Just bought 1Password 4 for Windows.
In my 1Password for Mac, opening an attachment doesn't save it to disk first - so if I have an image with secret codes, I can just open it.
Window version wants me to save it to disk first - emmmm - I do not want to save to disk. :(
Why can't 1Password 4 for Windows just show me the picture (jpg) without having to save it to disk first? It's a potential security risk to have to save it first.
Thanks
Morten
Comments
-
It's a potential security risk to have to save it first.
Actually, it is potential security risk to decrypt it in a temporary location unknown to you. This is why we ask you to save it. So that you can delete it in a secure manner when you're done with it.
0 -
I do not want to save it - because then an unerase program can easily restore it. Why would you store it? Why not just open a new window inside 1Password and show the image? It's peace of cake to look for the extention and if it's an image, show a new window ... it doesn't have to leave 1Password???
0 -
How do you do it in Mac version? You don't ask me for location??
0 -
Why would you store it? Why not just open a new window inside 1Password and show the image?
https://discussions.agilebits.com/discussion/comment/124953#Comment_124953
0 -
I do not agree with your link - png, jpg etc. is "standard" ... PDF, Word, Excel etc. is owned by companies. It takes under 5 minutes to create a window that would show a standard picture.
You didn't answer me on how you guys do it on the Mac version?
0 -
On the Mac, the files are actually saved to a temporary location before being displayed. The directory used for this is
~/Library/Group Containers/2BUA8C4S2C.com.agilebits. Unless permissions on~/Libraryare changed, only your user account can enter this directory. Files displayed through Quick Look from within 1Password stay in that directory until 1Password is closed or the vault is locked. With a scheme like this, I would assume that the deletion is performed securely.Windows does not prevent developers from doing this in a similar fashion. (Albeit without Quick Look, but presumably the user already has a viewer application installed.)
0 -
@svondutch: is it correct that you actually (on a Mac) saves to a temporary location unknown to me? I thought you said it would be a potential security risk? @Zr40: what if 1Password crashes before cleaing up, will my files not be erashed then? That would be epic fail.
0 -
If 1Password crashes, the files will remain there, but the next time you exit or lock 1Password they'll be deleted.
0 -
@Zr40 and that's a security breach in 1Password imo. I put my files into a secure app like 1Password and expect them to be secure. If my files leaves a secure area (1Password) without my knowledge, then I want a confirmation dialog first, so I know my files suddenly are unsecure.
0 -
and that's a security breach in 1Password imo. I put my files into a secure app like 1Password and expect them to be secure. If my files leaves a secure area (1Password) without my knowledge, then I want a confirmation dialog first, so I know my files suddenly are unsecure.
And this why 1Password for Windows will ask you where to decrypt your attachments. So that you know where and when to delete them. In a secure manner (using Eraser, for example).
0 -
If my files leaves a secure area (1Password) without my knowledge, then I want a confirmation dialog first, so I know my files suddenly are unsecure.
Hey, thanks for the feedback, Morten! I'm sorry this isn't made clearer in the application. I'll make sure we get this passed on to our developers on the Mac side.
0 -
It's a shame there isn't an inverse memory mapped file capability.
0 -
@Morten Jonsen Hmm. Continuing that line of thought, the clipboard is another place where decrypted data can live, which can be read by any application. Same with auto-type, if some other window steals focus while the password is being typed. Would you require confirmation for those actions too?
If you're already explicitly choosing to open an attachment, you know it is going to be decrypted and saved, just like when you're explicitly choosing to copy a password to the clipboard. 1Password handles cleanup in both cases: clipboard is cleared and decrypted files are removed (and erased, I assume). In both cases other programs running under your account can access the decrypted data before it is removed.
Choosing where to store the decrypted file doesn't prevent those programs from accessing the file, and the application you're using to open the file is most likely not designed to keep your temporarily decrypted files secure. And I would argue that when you just want to view the file once (instead of permanently saving it), the temporary location would not matter. In that case, why not let 1Password manage the secure erasure? If you have to do it yourself, it's possible to forget.
0 -
How Mac does it: https://discussions.agilebits.com/discussion/comment/120566#Comment_120566
Previous discussion for Windows: https://discussions.agilebits.com/discussion/comment/110586#Comment_110586
0 -
Notes:
You can configure 1Password to clear the clipboard under several different circumstances.
1Password for Mac automatically deletes the temporary copy of an unencrypted attachment (though "secure delete" is not currently used); 1Password for Windows does not (which is why we still think it's a good idea to ask you where you want that copy saved).
0 -
1Password for Mac automatically deletes the temporary copy of an unencrypted attachment (though "secure delete" is not currently used); 1Password for Windows does not (which is why we still think it's a good idea to ask you where you want that copy saved).
Is there some feature of OSX that means that the deletion of the temporary file that 1Password Mac performs is guaranteed to complete? Or is it subject to the usual risk of the program dying before it has a chance to clean up and thereby leaving orphaned files lying about?
0 -
@svondutch and @DBrown ... why the difference between Mac and Pc version? In Mac I don't have to bother with erasing the file afterwards, while I have to do this in Pc? I'm pretty annoyed with that extra step. 1Password should of course not have to save an image to show it - making it vulnerable, when 1Password easily could show the image.
0 -
I hope we've addressed this in the parallel thread.
0 -
You didn't address my question. In the other thread you said that:
If you double-click an attachment, 1Password calls the default app for the file-type. In either case, 1Password is decrypting the attachment first, of course, and saving a copy to a temporary directory. The temporary copy is deleted, the next time 1Password is locked.
This leaves a security hole if the system crashes (or is hard powered down) before the 1Password lock functionality executes. I was curious as to whether OSX had some sort of built in tidying up that would cover this. If not then why is such a scheme not suitable for Windows?
0 -
I was curious as to whether OSX had some sort of built in tidying up that would cover this
As far as I understand, there is no other mechanism tidying up.
If not then why is such a scheme not suitable for Windows?
On Windows, we do not decrypt your attachments into a temporary directory that is probably unknown to you. We leave these decisions (where to decrypt your attachments and when to delete them) up to the user.
0 -
On Windows, we do not decrypt your attachments into a temporary directory that is probably unknown to you. We leave these decisions (where to decrypt your attachments and when to delete them) up to the user.
I understand that. However, there is a problem here, either in the Windows client or the Mac one. If the "temporary file risk" is acceptable then the Windows client is missing useful functionality? If it's not acceptable then the Mac client has a security flaw that should be corrected.
0 -
Hi @RichardPayne,
These are the decisions we made based on how the apps work on both platforms right now. For now, we've deem it as not acceptable on Windows and acceptable on Macs based on the cleanup process we've built on Mac. Just like we've deem auto-type acceptable on Windows but not on Macs.
Are these decisions permanent? No, we revisit topics like these often and we're listening from customers' feedback on these features. We'd like to find a solution to provide a better experience on Windows that doesn't require saving locally, maybe we can use your memory instead of disk to view the files if possible. Just as we'd like to find a way to offer Auto-type on Macs that bypasses the keyboard events.
0 -
@MikeT that is a cop out answer. If @svondutch is correct and there is a no OSX specific assistance to the tidy up process then there is absolutely no reason why the Windows client could not implement it in exactly the same way.
This issue was brought up a couple of times during the beta period when you had plenty of opportunity to implement it. The reason given for not doing so was that it was insecure and yet we now discover that you're using the exact same insecure method in the Mac client. All I want is a straight answer. Is the current Mac implementation considered secure enough or not?0 -
Hi @RichardPayne,
Is the current Mac implementation considered secure enough or not?
I've asked Goldberg to follow up, he's the best person to answer your question with the technical details on how this works on Mac and why we feel it is safe to use on Mac.
@MikeT that is a cop out answer. If @svondutch is correct and there is a no OSX specific assistance to the tidy up process then there is absolutely no reason why the Windows client could not implement it in exactly the same way.
That's the point I was making but I guess it didn't come across as such.
The simple answer is that we don't have the resources to implement everything at the same time. We have a very small development team for Windows and we're still working on expanding the team like we've doing with other platform teams. It may be possible to do this when we have a much bigger team and everybody can work on several things at the same time. At this point, we're not there yet.
Just because the Mac app have this feature, it doesn't help the Windows team to implement it in one day. It just doesn't work like that. There are some features on Mac where it can take a few weeks to implement but on Windows, it can be much longer than that.
We're having some internal discussions to figure out the best way to add this quick view capability, since we're hearing from a lot of folks here that we didn't anticipate before. Keep in mind that with a small development team, it takes us a lot of time to prioritize with the best resources we have. This feature was not high on our list for the initial 1Password 4 development, even though we've gotten some requests for it during the beta testing.
For now, we're asking customers to save the attachments to the drive to view their attachments and to secure delete it afterward if they have no need for it on the disk. It's not always going to be like this, we do want to make this effortless and do it in one-click. It's just we need more time to figure this out.
The strong usage of the insecure wording is because we don't have the mechanism in place for 1Password on Windows to handle what happens to files after it is decrypted. That's basically because we never had any need to do this, we don't want to decrypt anything of your data on disk, period. If we open this up for quick attachment viewing, we better be ready to handle several challenges this come with, and right now, we're not there yet.
On Macs, we were ready and had a mechanism in place, thus, more secure. We also have a bigger team there, naturally.
0 -
Hi, forgive me for not having read the full discussion.
Attachments, because of their potential size can't be treated like items in general. They are saved to disk on both Mac and Windows, although this is more transparent on Windows. To do anything other than save to disk for files that can in principle be up to 4 GB in size (though we cap these at a few megabytes) would involve developing our own security swap and virtual memory system.
We've chosen different approaches on Windows and OS X because both user expectations differ on these systems and because the systems offer different tools. For example, OS X offers a sandboxed cache for temporary files that an app may need to create, but this is written to a disk cache on OS X. Having these cache folders within the 1Password sandbox in OS X makes it harder for other sandboxed applications to get to them, and also provides a reasonably reliable clean-up mechanism, so that we can (usually) delete these even if 1Password exists abnormally on OS X. So it is easier to implement a clean-up mechanism on Mac than on Windows. What comes for "free" in OS X development (containerized temporary files) is something we would have to implement manually on Windows.
It sounds like what @Morten Jonsen is asking for is that when the attachment is small, we handle these like we do the other contents and only write to disk when we absolutely need to. I'm not ruling anything like that out, but perhaps what would be more useful is for us to be clearer in our documentation and presentation, particularly on OS X.
As @miket correctly pointed out, we aren't able to keep 1Password in perfect feature parity across platforms. 1Password for Windows, for example, offers Diceware-like password generation, while we don't (yet) have this on Mac. Some of these just has to do with demands and resources of the different teams, other differences have to do with the fact that user expectations are different on different systems (e.g., Windows users often prefer more direct control and reject containerization), and others have to do with the fact that the different environments offer us different tools (e.g., explicit containerization on OS X). it's really a combination of this last two that leave us where we are with the differences in where decrypted attachments are written.
0 -
That's the point I was making but I guess it didn't come across as such.
The simple answer is that we don't have the resources to implement everything at the same time. We have a very small development team for Windows and we're still working on expanding the team like we've doing with other platform teams. It may be possible to do this when we have a much bigger team and everybody can work on several things at the same time. At this point, we're not there yet.@MikeT Here's what you said:
For now, we've deem it as not acceptable on Windows and acceptable on Macs based on the cleanup process we've built on Mac
While you certainly did say "for now", the rest of the sentence implies that the reason is not a lack of development resource but some fundamental problem in the security of the systems. This does not imply something that you may change later.
Still, as it turns out there is a platform difference (thanks @jpgoldberg for explaining that) and so I can see why you'd not implement it as you did on the Mac.
In lieu of a generic solution, I'd still ask that you allow an inline viewer for images.
0 -
I'd still ask that you allow an inline viewer for images.
I have added this to my list of things to do.
0 -
Hi,
I'm currently using the demo Windows version of 1 Password.
All technoshe****t aside I agree it would be great to be able to open attachments on the fly rather than saving them first.
Any progress on this subject?0 -
Thank you for your response,
By points you mean:
Security issuesKeeping 1Password lean and mean and not adding the functionality of a viewer for all sorts of filetypes?
Well I can appreciate that of course.
At the same time I see the technology is there for a generic kind of viewer (something like Google uses)
So I will keep my hopes up, It's a competitive line of business you guys are in so that could also quickly become an incentive.... ;)Nothing is pertinent in this life, you know that DBrown B)
0
