Backing up Teams data?
Comments
-
I have read through this thread and would like to add my self to the list of people not completely satisfied with the current scenario. I second the opinion of tfordmq. Another use case where having our own local backups is very important, is the unlikely (but not impossible) event where agilebits pushes a software update that, for one reason or another, screws up the syncing process and corrupts or erases the data - I can't sit around and wait for you to fix the situation - I know that you will fix the situation eventually - but I can't be in a situation where I am waiting for you to do something before I can access my infrastructure / accounts etc. If I had an offline copy of the vaults that I can open in some manner until the situation is rectified this would appease the one MAJOR feature that is lacking if you really want to get large scale enterprise (and even security savvy SMB) use. This backup really needs to be able to be automated as well. I would be prepared to pay an additional monthly fee for this feature if required.
Whilst we are on wish lists, I'd also like to see some sort of TOTP or TOTP like 2 factor authentication on the web based interface for teams, as well as on unlocking the vaults locally - integration with something like a YubiKey would be even better, such that if the YubiKey was removed from the machine, the vault couldn't be unlocked. Again I would be prepared to pay more for these features.
0 -
I think about something similar, and I see what you mean. Lots of things are possible, and backups provide some peace of mind if any of that were to happen. :) I'll let the team know you're interested in them.
Whilst we are on wish lists, I'd also like to see some sort of TOTP or TOTP like 2 factor authentication on the web based interface for teams, as well as on unlocking the vaults locally - integration with something like a YubiKey would be even better, such that if the YubiKey was removed from the machine, the vault couldn't be unlocked. Again I would be prepared to pay more for these features.
We have this right now in 1Password Teams. :wink: Using Duo, you can set up multi-factor authentication for your team. Learn how: https://duo.com/docs/1password
Hope that helps!
0 -
Thanks, I must have missed the Duo integration part, however I would much prefer a more open solution, one that implements open standard such as TOTP as defined by the IETF here https://tools.ietf.org/html/rfc6238 That way I don't have to sign up to yet another multi-factor authentication service and can use the one singular solution for everything - whether that be google authenticator implementation, the microsoft implementation, the amazon, the yubikey implementaiton or any of the multitude of other applications avail for smart phones and/or PCs that have implemented the open standard. On top of that its a free open standard that I don't need to pay (used by all the big boys for MFA authentication to there services - google, microsoft, amazon, godaddy etc etc the list goes on) - again make it part of your 'enterprise pack' and that would be another reason for me to want to pay for it.
0 -
@chwright: That's definitely something we'll continue to consider. Just keep in mind that while TOTP is easy to implement and free to use, it is also a code which can be intercepted. That's one of the reasons we're using Duo right now. Another consideration is that Duo uses a separate app. But wait — you don't want that! While I appreciate that, we've already added trained 1Password users to use 1Password for their TOTP codes...so you see where I'm going with this. It's much less insecure (and insane) to use a separate app for multifactor to authenticate 1Password itself. Perhaps we can add other options in the future though. Cheers! :)
0 -
Some questions
- does the Duo MFA approach work for the 1password app on the computer - I can't seem to find any instructions on this, so I am assuming not?
- Can you explain this bit in your response 'it is also a code which can be intercepted'? the exchange of authentication information should always be over a secure channel so Im not sure what 'interception' you are referring to...
Ill expand on how we use 1password simply as fuel for thought...
Right now (unless external multi factor is supported in the desktop apps) 1password is completely vulnerable to host compromise, for example, if someone where to be able to install remote control software, and a key logger on a host machine (it happens, all it takes is clicking on the wrong link in an email - I have seen time and time again even seasoned systems admins fall victim to this) an attacker could simply remote control my machine, retrieve the password to unlock the 1password database from the keystroke log and then access everything. This would be especially problematic if I also had the 2factor codes in 1password.
My protection against this at the moment is, for all services that support 2FA, I keep the second factor of auth (generally TOTP) in a seperate device (mobile phone, or yubikey that requires physical touch to release the 2factor code) meaning, that for all my accounts that support 2FA if someone were to compromise the 1password database they would still be unable to use the accounts.
Keeping password and the second factor of authentication in a database that is locked by only a password (no matter how secure the password) is actually defeating the 2 factor authentication on those accounts in the first place.
Now I imagine your going to say, 'even if we implement 2 factor on the app your still at risk, because the only thing needed to decrypt the information is the master password so a crypto savvy attacker, if they captured the master password in a keystroke log, could decrypt the database directly' thus defeating the 2factor auth on the desktop app. Now that is a pickle that I'm not sure how you are going to solve, you obviously can't encrypt with an ever changing 2FA token - which brings me back to the YubiKey (or any smart card really) - you could set it up in such a way that decryption of the data requires the master password and a key securely stored in a YubiKey or some other read only media, something that requires physical presence to unlock (such as the touch required in a YubiKey)
Given all the above, I don't accept your 'insane' statement about not using 1password for 2factor codes, in fact in the current state I would say its the opposite - for any real security - it is insane to store both factors of authentication in the same location on the same device especially when that location itself is only protected by password - its the same thing as when I see people use desktop TOTP/HOTP apps, as soon as desktop is compromised so is your authentication. The second factor of authentication has to be stored separately to significantly lower the risk.
If you implement 2factor support for the desktop app I will want to use it, but I'd like to see it done properly - as I said I will pay more for it, and if you do it properly I predict this will be your biggest differentiator in the market.
0 -
does the Duo MFA approach work for the 1password app on the computer - I can't seem to find any instructions on this, so I am assuming not?
@chwright: Sorry for not being clearer! Duo authentication is not for unlocking the app; it's for logging into a 1Password Account. When unlocking the app, you've already authorized it previously. A lot of people (myself included) like being able to access our 1Password data offline, so having to authenticate each time would be at best annoying and at worst impossible. Not having an internet connection makes 1Password a lot less useful with regard to logins, but folks keep a lot of other important information there. :)
Can you explain this bit in your response 'it is also a code which can be intercepted'? the exchange of authentication information should always be over a secure channel so Im not sure what 'interception' you are referring to...
As I'm sure you're aware, you can have a "secure" (SSL/TLS) connection to an impostor. Your data will be encrypted, just...it's going to someone you may not want it to. If you're using a device or network you do not control, you need to verify the chain of trust to ensure that you're connected to who you would otherwise assume you are. Never assume. :scream:
Ill expand on how we use 1password simply as fuel for thought...
Right now (unless external multi factor is supported in the desktop apps) 1password is completely vulnerable to host compromise, for example, if someone where to be able to install remote control software, and a key logger on a host machine (it happens, all it takes is clicking on the wrong link in an email - I have seen time and time again even seasoned systems admins fall victim to this) an attacker could simply remote control my machine, retrieve the password to unlock the 1password database from the keystroke log and then access everything. This would be especially problematic if I also had the 2factor codes in 1password.
1Password doesn't purport to protect you from a compromised system. At that point, all bets are off; and anyone who tries to sell you otherwise is probably not someone you should trust. 1Password does, however, use encryption to actually protect your data. So someone with full access to the machine still wouldn't be able to access your 1Password vault(s) without your help. And 1Password (to the extent that it can, in the event of a compromise) can prevent your Master Password from being captured using SecureInput (macOS) or SecureDesktop (Windows). And you only enter the Account Key when authorizing a device for the first time, which significantly limits the window for an attacker to try to capture it. Otherwise it is rarely used and never transmitted.
Given all the above, I don't accept your 'insane' statement about not using 1password for 2factor codes, in fact in the current state I would say its the opposite - for any real security - it is insane to store both factors of authentication in the same location on the same device especially when that location itself is only protected by password - its the same thing as when I see people use desktop TOTP/HOTP apps, as soon as desktop is compromised so is your authentication. The second factor of authentication has to be stored separately to significantly lower the risk.
I agree, which is why I'm confused why your first question was about using Duo on the computer. You totally missed my point though, which was poorly made, I guess. I believe this is the sentence you're referring to:
It's much less insecure (and insane) to use a separate app for multifactor to authenticate 1Password itself. Perhaps we can add other options in the future though.
What I was trying to say is that using 1Password to store a TOTP secret for 1Password would be an insane thing to do, given the recursion. It's like a 1Password Matryoshka Doll. I wasn't asking for acceptance, just hoping you'd crack a smile. :p
0 -
Thanks for the response, Lots to pick on there but for now I think we will just have to agree to disagree :)... For now, my solution of keeping the TOTP tokens out of 1password and in another device is the best I have for now (for sites/interfaces that offer 2FA) and 1password, on balance, is the currently the best solution I am aware of for securely sharing passwords in a team. I'll settle for yet another app for 2 factor authentication on the 1password web interface, though not really happy about having to pay for it. I will keep looking for a full solution that meets all our requirements though and I eagerly await to see what agilebits does next with the feedback from this thread (especially the backup piece) and others, hopefully progressing towards a more enterprise ready solution.
0 -
Hey, thanks for all of your feedback on this! We're not "finished" with 1Password in general or the new subscription services by any means, so it definitely helps us to get a clear sense of what you and the rest of our (current and, hopefully, future) customers are looking for. Backup is important, and there are a lot of interesting multifactor solutions out there. But we defnitely don't want to try to tackle too much at once. For now, Duo is a great option, and we'll continue to evaluate others. Cheers! :)
0 -
I like the Idea about export and best would be in command line so I could gpg it or something else.
You should really make the feature request public and show if and when do you work on it and when do you plan to be finished.
It is not helpful to state hear that you will do it some where in the future.
0 -
@random_31731ec7aea : I honestly don't think public feature request lists are useful. We try to be honest when a feature request is on our "not going to happen" list. Our favorite example of this is the idea of syncing via WebDAV servers. It's not "maybe happening later", it's simply not happening.
Sometimes ideas go into development, then we put the work aside for months at a time. Sometimes we stop all together because we don't like the ideas we have for implementation and we need to come back to it with a fresh mind. Considering how messy the process of development tends to be, I really don't think it's productive to tell you whether work is actively being done on the feature. At the end of the day you don't care whether we're actively developing it, you care about whether you have the feature. Until you have the feature, you're free to keep putting pressure on us to build it.
I'm in agreement with you that it would make most sense for such a feature to be a CLI app and if it provides you with decrypted data that you be able to easily encrypt it using gpg or something else.
Rick
0 -
I thought I'd weigh into the 'export' concern people are having. There is a export function in the windows application that does a export to a .txt file. Yes this isn't encrypted and is plain text but my plan around it is this file will be stored on only on a usb stick offline and stuck in the bosses safe offsite and easily accessible in the event of ultimate failure.
If being stuck in a safe isn't 'safe' enough, a third party encryption tool for the file could also be used.0 -
You're right, that would be an option for some people. The Mac app has an unencrypted export as well. In neither case does it export file references (Documents and Custom Icons), which is probably the biggest down side that I can think of.
I want us to do something better here.
Rick
0 -
I need to play devil's advocate. 1pass for Teams (web) has the ability to have a "personal" vault, so I am assuming that this is strictly for "personal" business related logins (domain accounts, etc) and NOT for ACTUAL personal logins (banking, etc) as there is no way to export a vault from 1pass for teams. Say for instance, you leave your job, you aren't able to export. Is this correct?
0 -
Hi @patrick_keeler,
You're right that we recommend that the Personal (now called Private) vault in 1Password for Teams is intended for use not for your personal data, but for data that belongs to the company but is limited to you (i.e. all of the AgileBits logins I have because I work here).
There is the ability to export data from 1Password Teams vaults. Our apps, for example the Mac app, has an Export function to export to 1pif or CSV files. This is not controllable for the Personal/Private app though, as the only manager of that vault is the user themselves.
I hope that clears things up.
Rick
0
