Introducing 1Password for Teams
blog.agilebits.com
blog.agilebits.com
To compare the two - 1pw is basically one of my favorite programs. LastPass is um... adequate? We have a lot of items in our LastPass vault and anytime we search it, add or change an item there is a 5-10 second lag. This according to LastPass support is unavoidable. Something to do with each item being individually encrypted/decrypted each time.
In anycase if 1Password for Teams is half as good 1Password I assume it will blow LastPass out of the water. And my experience with the Agilebits team gives me confidence that they'll work on actually improving the product instead of just looking for an exit.
Rob
AgileBits
What were the issues you had with the Android application?
Feedback is most certainly welcome here so we can try to focus our attention on the areas that are seeing the most sad faces from our users.
Thanks!
Kyle
AgileBits
Our iOS application also shares a great deal of underpinnings with Mac. That means when our Mac team implements something super great our iOS team gets some of that grunt work for free. Then it becomes an interface deal in many cases which may not be easy at all but at least some of the work was done.
The Android team, well, they have to implement everything themselves and it's simply going to take time. Combine this with UI changes and stuff that mean we have to rewrite existing things to match up with that and it just becomes very overwhelming sometimes. I work on our iOS application and it's incredible the amount of stuff you can do in a short period of time because groundwork has been laid for years. I don't envy our Android developers because they have none of that to work with. I'm sure it's both overwhelming and exhilarating for them.
I guess that's a long answer but really, it's simply going to take some time for our Android developers to catch up. I know it's tough as a user to see one so far ahead of the other but I hope the above information puts some of it into perspective. They'll get there :)
Thanks!
Kyle
AgileBits
It is true that as an android dev one has to implement many things themselves. It's an unpleasant part of developing for Android that Google does very little to address.
The simplest approach you could take would be to copy and implement the design patterns presented in Google's material design guidelines. Yes, it is unfortunate they are guidelines and not SDK. However, there are enough patterns to provide a superior experience to the jumbled mess of an application that it is right now.
https://www.google.com/design/spec/material-design/introduct...
- Use the FAB for "search" since it is the most frequent user action. - Use the navigation drawer https://www.google.com/design/spec/patterns/navigation-drawe...
This is just a 1 minute recommendation and of course open to argument. However, simply redoing the app in a generic style adhering to these guidelines would be a drastic improvement.
Thank you in advance for doing an android app in the first place.
A design overhaul is definitely in the works. I think, but can't confirm, that it will alleviate some of your concerns. I don't have a time frame for it but given we're saying that the 1Password for Teams beta is going to last about 3 months we'd like to have Android ready to go for that launch as well. They're hard at work on making it happen now.
Thanks for the feedback! We're always happy to receive it and pass it along. It's how we drive development in a lot of cases. Teams came about from requests from our users. Multiple vaults came about from requests from our users. A lot of it is driven by user feedback so don't be afraid to send it in. No promises everything will be done but the more people that say they want a particular feature the higher that gets bumped up the priority list.
Kyle
AgileBits
I'd also love to see it do something like Facebook Messenger where it provides a button on top of whatever active app is currently running.
https://blog.agilebits.com/2015/05/28/fingerprint-unlock-com...
That's fairly old, from May, but it does give a bit of a tease if you're familiar with Android and the look and feel of things.
Kyle
AgileBits
Overall seems to be a low effort app. Not worth the money I paid for it. Considering switching to an alternative which is more Android friendly despite having laid almost a hundred bucks for ios and Mac apps.
We really do want everyone to love our Android application. Personally, I feel they've made great strides given the time they've had. It's just a matter of time and our Android application will be right up there with our iOS application. We have some super smart people working on it and they're very passionate about what they do. I can't help but be inspired by a group of people who fight tooth and nail to catch up to a product that's much older (our iOS application).
I showed your comment to our Android developers so they've seen what you're requesting :)
Thanks!
Kyle
AgileBits
Kyle
AgileBits
Imagine if ssh private keys could be stored inside 1Password. It would become a ssh-agent replacement.
No real reason to leave ssh private keys scattered on different user directories anymore.
Maybe we'll have to kick this one in the pants and see what we can do. No promises of course but I'll be passing this along again since I have a personal investment in that idea :)
Kyle
AgileBits
I'm the technical head for our cloud business so I've got some pretty specific ideas on how to make this more useful from a day to day operational standpoint (multi-tenant infra support has lots of interesting use cases).
Feel free to ask if you want more input.
Having some information I could make sure is in our bug reporter as a feature request would certainly be nice to have around in case we did implement this at some point in the future.
Kyle
AgileBits
Edit: since someone is apparently upset over my comment - those two features are absolutely mandatory in almost all corporate environments. If you have a comment to the contrary, feel free to share it. Don't just downvote my comment because you don't personally need the features.
I'm not super big on the terminology, but I assume on-prem is on-premise, meaning you'd like to self-host. If I have that correct then unfortunately I can't promise anything here. I will most definitely pass this along to our team though so that they know there are some requests for it.
As for active directory integration. I'll be completely honest here and say I'm not totally sure how we can support this one. We use both an email, an Account Key, and a Master Password to access and decrypt your data. There isn't just a password to decrypt, we also use your Account Key combined with the Master Password. This could potentially provide some roadblocks to providing single sign on support. If you're looking at it for group integration (i.e. User X is in Group Y in AD/LDAP then they are in Group Y on 1Password for Teams), that might be a different story. I'll also pass your concerns and feedback for this one along.
I hope those are at least something, though I can certainly understand that it might not be to your liking. But if you have feedback or can help me understand things more I would certainly appreciate it. I'm just a developer and have never been a system admin, nor have I worked in a corporate environment. That leaves me a little green on those topics :)
Kyle
AgileBits
AD integration meaning yes, ability to tie users/groups between 1password and existing AD infrastructure. The idea there being that if a user is terminated, and their AD account is deleted/locked out, everywhere else is locked at the same time. Having to go to 20 different systems to try to clean them out is a great way to miss accounts :)
I will definitely be passing this along so we have some proper request information on hand. My bosses are reading this, one has even interacted in this discussion already so they're seeing this already but I'll make it a bit more official tonight when I write up a summary of what I seen requested.
Thank you again for taking the time to make sure I was on the right track.
Kyle
AgileBits
I don't want to speak for the down-voters (I'm not one of them and I think your comment is was a valuable contribution), but when I first saw AD integration requests I assumed that people wanted AD managed Kerberos authentication to 1Password for Teams; and so imagined delegating 1Password for Teams authentication and authorization to a third entity.
Don't get me wrong. I love Kerberos. And in very early planning stages we looked at it quite a bit. But Kerberos is only about authentication. We need client derived encryption keys as well as authentication tokens to achieve our security goals of end-to-end encryption.
Delegated user admin/sync would be what I'm looking for. Centralized user management along with RBAC makes it much easier to set policy.
I have no issue checking Keeper out but two things to note:
1) It's considered good form to clearly disclose your affiliation
2) Repeatedly spamming/commenting a different product's thread isn't.
Comment once or twice. Feel free to submit your site to HN with something interesting (blog post?) and people will up vote accordingly if there is validity.
=)
Maybe v1.x doesn't need AD, however it's something the dev team should definitely consider for later versions. Beyond that, it's really upto AgileBits about how much of the large-corporate market they want to cater for (companies like Centrify seem to have found a niche there)
Thanks for listening.
Sorry for the delay in responding. Seems I managed to skim past your comment several times before noticing it.
I don't know if it's a "not want" so much as "technically difficult" due to the way we handle the encryption.
Your feedback will definitely be passed along to the team though!
Kyle
AgileBits
Maybe you can explore Okta integration as possibly a faster route to AD integration.
Please try, please help make the enterprise security software market suck less :(
1. Too much scrolling. Most of the people in these positions are in their late 40s, 50s and they are used to brochure-style pitches and just want to see some quick features on a single page probably. They are probably viewing this at work, not at home or even while commuting.
2. You need to emphasize compliance over the crypto standards - the compliance is what determines is "good enough" anyway for your crypto strength requirements and most execs don't care if you're using a more secure algorithm over another as long as it meets compliance and can be flexible enough to change in the future as requirements from a regulatory agency could change. Learn your acronyms to get attention from these folks (you have about 5 of the 30+ that Amazon Web Services is very informed about on their pages) - they won't care about a product unless they are confident that their vendor understands compliance very much. This is a huge reason for the shift by enterprise to AWS when people joked that it'd never pass enterprise muster - they started packing tons of alphabet soup and whitepapers along with reference customers at the right conferences. I might try to get a vendor partnership or something with someone to get a reputable logo namedropped onto that page or two specifically under compliance. The big win will be with an actual quote with a specific outcome from a reputable reference customer. That's hard in security space but perhaps a F1000 could work instead of a F500 / F100...
3. Cost doesn't matter generally when it comes to enterprise purchases because for most start-ups what they can charge is insane (but is a problem for people-centric tech vendors like old school software companies that are themselves very bloated and inefficient capital-wise), $1M is a rounding error for most F100 companies and POCs are paid maybe like, $100k for a few months or so maybe, which is easy to float most start-ups even with a regional account manager that commands a $600k / yr comp package. So don't bother with a pricing section, it'll go out the door in the middle of negotiations anyway.
4. Password management of endpoints is not mentioned and that's a huge reason that companies buy software like this, not for team / user passwords (the user penetration rate compared to shared sticky notes and tribal knowledge is pretty poor - trust me, I don't even do it and I just drop it in a private gist or something because just logging into a system is enough inconvenience).
5. No prominent "talk to a representative" kind of link. Most of these people want to talk to a human / sales person first (they want a throat to choke if things go wrong - they want a relationship, not a product / service), and they don't want to read a whitepaper probably either. Some rather technical folks will be interested, but the number of info security executives I've seen that are still technical to the degree they could understand a solid security paper in a F100 are countable on one hand from my experience.
From a more abstract level, it really doesn't sound the most friendly / human-centric of a pitch to me, it might as well be a set of bulletpoints. It doesn't look like a "here are your problems, here's how we'll solve them" narrative. Most successful enterprise and b2b pitches are based around demonstrating you have competency in solving the fundamental problem through using your product / service, not selling the technical product or anything at all. For example, Square had the problem where they were compliant, simple, and everything awesome after tons of feedback, but merchants didn't care. Then with some real-life reference users they broke through.
For a reference point of "quality," the Cyberark vault implementation in place where I'm now is horrifically bad - 8 character passwords rotated through maybe every day and passwords are locked when a user checks it out, and only administrators can break locks on "checked out" passwords. So it means single user mutual exclusion root access to a server. Supposedly we don't use anyone else because nobody else would bend to the really bad / insecure demands we asked, but I am no authority on the steps that led to such a poor system.
The enterprise security model is that every administrative access to systems must be gated somehow behind 2FA or a physical presence (ID badge swipe works). VPN counts perhaps, but then we're asked for 2FA again when accessing passwords. But even with this secrets store system most admins that are productive here don't use it because it's so restrictive UX-wise (it doesn't support ssh key access, for example). There's a separate effort going on for ssh key management that's being custom-developed with some partners, and that'll take so long it'll be 2017 probably before it's released.
Anyway, best of luck. Enterprise is a hard space to break into but once you're in you're basically in for life at this point even if your software is so bad that it directly causes the death of someone... unless a lawsuit is involved. Then you're out the door in less than a week. That's the only thing I've seen enterprise companies take swift action on that destroys start-up competencies - legal issues.
Thank you for doing this. Super into analyzing this for security. 1Password is my preferred single-client solution, but not having a good Team solution has been a serious drawback.
https://teams.1password.com/white-paper/1Password%20for%20Te...
Let us know if you have any questions after giving that a read.
Kyle
AgileBits
As libraries become more available or the nature of our clients change, we can switch. We certainly look forward to having the smaller keys that ECC will give us.
We are aware of tweet-nacl, but we are trying to avoid the number of external JS libraries we would need. This is why the Teams web app is limited to browsers that most fully support WebCrypto.(Of course our own browser extension for Desktop 1Password runs in more browsers as it does not rely on any crypto itself.)
I admit it is kind of weird using GCM where a stream cipher would be faster, lighter, cheaper. And so we definitely are looking forward to moving to something like that for our transport layer encryption. There aren't any security problems with our current ciphersuites, but we should be able to improve performance by using things like what you recommend.
1. Limited algorithms. This is what has use using GCM instead of a stream cipher for our transport layer. 2. It allows developers to shoot themselves in the foot by not enforcing best practices. 3. It encourages crypto delivered over the web.
If (3) is your concern, then it doesn't matter how good, modern, up to date, the methods are. This objection applies to tweet-nacl just as well.
If (1) is your concern, keep in mind that there is nothing wrong with the algorithms and modes we are using. Sure we had to forego some slicker alternatives, but this is a performance hit.
If (2) is your concern then what is true about WebCrypto is true of almost every crypto library out there. Whether we use libcrypto, CommonCrypto, MS CAPI, etc, we have just as great a chance of "using it wrong" as we do with WebCrypto. WebCrypto isn't worse than most of the alternatives, it is just new enough that we all hoped it would be better than the alternatives in this regard.
So given these three general concerns with WebCrypto, you need to make a judgement about how these play out when evaluating 1Password for Teams.
It's no secret how you feel about crypto delivered over the web and run in the browser, but one of the the factors in our choice involved speed and stability of WebCrypto versus <strike>tweet-nacl</strike>NaCl in JavaScript.
NaCl might be a good choice for our transport layer, but we do a lot of encrypting of keys and not just of non-key data. So we needed to make use of .subtle methods every now and then. So if we needed things that NaCl didn't offer, it was simpler to use a single other API/Library than to mix and match.
I am a huge supporter of efforts like NaCl. I'd obviously prefer to be denied the opportunity to shoot myself (and our customers) in the foot than to use tools that are prone to misuse. It would have also been really cool to show off using NaCl. It is the direction we'd like to see the world move. But we couldn't quite swing it this time around.
I somehow had it confused with a JavaScript implementation. Not sure how I had that misconception in my head.
I've recently bought the "real Windows application", since the Universal App doesn't allow to enter new logins (really?), only view existing ones.
Unfortunately, KeePass was much more useful with its Alt-A shortcut. In 1Password I need to manually copy login data from the application, since I'm using Edge and there's obviously no plugin, yet (Edge's fault).
Oh, and syncing must be a bad joke. Lots and lots of sync options, but the only one working across all platforms (iOS, Windows Phone and Windows are the ones relevant to me) is Dropbox. No OneDrive, no WLAN sync.
And don't get me started on vault management. I was using a non-synced vault without realizing it for weeks, and then I was pulling my hair out trying to sync the correct one. I finally only managed to do that by completely removing the Windows Phone app and starting from scratch.
At least they are moving everything to opvault. It was fun trying to get everything to sync, only to find out that the default vault format "agilekeychain" cannot be synced to Windows phone (or was it Windows desktop? I'm not sure).
We are working on adding Teams to 1Password for Windows. Hopefully we'll have more to show for that in the not too distant future.
I also hear you on the Edge front, we're excited to see what we'll be able to do with Edge once a plugin framework is available.
As for syncing, the Windows application does support Wifi sync to iOS and Android applications, in addition to Dropbox. Between computers, you could use any sync service that syncs like Dropbox, i.e. to a folder locally and then the sync service copies the data back and forth while the data rests locally. Keep in mind though that we've only tested and can support Dropbox for this so you might run into unforeseen problems, but we do have users doing this and it seems to work for them.
That said, I am sorry for the trouble you've had. If you have any questions getting things setup you're welcome to ask questions on our support forum at https://discussions.agilebits.com. We're always happy to help users get setup and running.
I'll certainly pass your feedback along to the proper people as well.
Kyle
AgileBits
It is billed as a work-in-progress, but on my terribly limited HP Stream 7 tablet (Windows 10), 1Password is no less stable than any of the other apps.
I suspected that Windows development has been delayed by the need to support iOS MDM (mobile device management) for businesses. And here we are!
I also suspect that Microsoft changes in development options - particularly "Universal apps" via HTML and Javascript - moved too fast for an indie developer to follow, at least over the past 18 months.
Our Windows developers will get their day to shine soon enough as well and we hope you'll enjoy the work they've done. :)
Kyle
AgileBits
Hamachi was a free VPN service most commonly used by gamers. LogMeIn bought Hamachi, and turned it into a paid service, earning the eternal hate of the gaming community.
None of these aspersions are worth considering if you're thinking about enterprise software.
I'm guessing there's some short term revenue gains, and maybe some initial fallout. But the question still stands of whether this works long term. A lot of companies underprice their offering, so this could very well work and an acquisition seems like an ideal time to raise prices while promising more down the line.
"A lot of folks only have experience with Logmein from the horrible way they handled transitioning users from the free to paid service.
My company has used Logmein Central for remote access to hundreds of PCs for years. The core software is great, reliable, and has been ever since we started using it.
The problem is that Logmein the company knows they're on top of the heap when it comes to remote management. They have no reason to innovate or improve where they can.
They added 2FA but otherwise we haven't seen a single new feature that we've taken advantage of in a very long time. Any features they do add hint at them wanting to be a RMM service but you'd have to be an idiot to trust them with more responsibility of your networks. Also a lot of those features require Logmein Pro which adds an insane amount of cost depending on how many systems you're managing.
Meanwhile there are bugs that have been around literally since we started using the software. For instance copy/paste while in a session will randomly break. The Logmein client software is very buggy on OSX, crashes often, search will randomly break. Their support is basically non-existent, although I haven't tried in a while if you opened a ticket it would take days if not longer for a response and they'd usually just direct you to some unrelated KB or tell you post on the forums.
We use Lastpass as well so this should be interesting. I've yet to see a merger that actually improved things from our end as a MSP. Cisco bought Meraki, Dell bought SonicWALL, at this point I assume any time we see a merger that its time to find a new vendor."
Are there single-sign-on options for Google Apps for Work?
Our sign-on process uses a modified form of SRP. (See the draft white paper). It is not a traditional "authentication" process and so can't use other SSOs.
The app also includes filling directly into webpages (via a browser extension) so you don't need to copy and paste. This also includes the ability to save new logins as you create accounts. Filling Credit Card and Address information as well.
Those are the two big features I think. The editing will show up on the web side but the filling part won't since it relies heavily on the client applications to do a great deal of the grunt work.
We're well aware of the demand for a Linux client though. I think all of us on the team would love to see a Linux client, but "love to see" isn't enough to make it happen right now.
I have most certainly written about this in my report I hope to send up the chain today so your voices aren't going unheard.
Kyle
AgileBits
Rob
AgileBits
I don't mean to sound petulant but I do own 1password on two devices and it's really frustrating to have no reasonable ability to use it on my main workstations at home or at work.
Rob
AgileBits
I verified this afternoon that this works with Ubuntu 15.10.
Lack of native Linux support (even just for an Ubuntu LTS) is holding back usage in both personal and professional use for me.
That there is an Android app makes the lack of a Linux implementation the more baffling.
The pricing does seem a bit high (the same price as google apps!). We're a startup with an engineering team of ~12 and only two or three of us pay for 1password right now. If we had 1password teams, I'm sure I could convince management to include pro versions of 1password for Mac & iPhone with every new employee as part of the "initial software package" that employees are allowed to expense. But another $100+/mo is a bit harder for them to digest. Regardless, looking forward to being invited into the beta/trial! :)
Note that pricing is not completely finalized just yet, and we will be offering different pricing tiers. In addition, a subscription to 1Password for Teams would replace the price of the individual apps, not add to it. So, you would be getting free upgrades for the client apps while you are subscribed to 1Password for Teams.
I hope that helps!
Rob
AgileBits
Heck, if you offer a good enough deal, I might be able to get a whole bunch of sister companies on it too.
What's not awesome though is how long they've been working on the refresh of the Android app with fingerprint support. Demoed in May, it's now November and they aren't even ready to launch it on their beta channel.
Really sorry about that. Our Android team is working as hard as they can to bring out updates. It's a tough balance because we've been hard at work on trying to bring 1Password for Teams to Android as well, which until today has been a secret project. This also means adding a lot of new features that are part of Teams, like multiple vault support.
For the fingerprint support it's important to note that this relies on Android Marshmallow so we couldn't ship that until then. It sounds like that has started rolling out though so that's no longer blocking us but a few other things are. I just thought that knowing it depended upon Android Marshmallow would help in seeing why that particular feature hasn't arrived yet :)
We're doing our best to get the Android application improved though.
Kyle
AgileBits
Kyle
AgileBits
Finally started use ZOHO Vault. It gave us why to create/manage/share to our developers "secrets" (passwords, PIN/PUK, Visa pin, etc) in webapp and mobile app. Now it is part of our "wellcome kit" to new worker. If you are alone you can use for free, and use to your personal or professional secrets.(Example code that was created to my profile by ZOHO Vault is like "x3Aq-JTyKg" -is not this! of course!)
Usually with any customer that see how we work... they copy "work method": if any other recommend us other better... of course we will test too to compare!! Cheers!
I'm not super excited about the use of WebCrypto, but it isn't any worse than storing passwords in the clear in a database.
My biggest question is does it support having an audit log of who accessed what credentials when? If that is supported I could see some our our teams switching over to this.
I've put this in a document I hope to send to the team this evening and I have added your comments on what is important to you. If you have any others please let me know.
This is just the initial beta and we fully intend to bring even more great features to 1Password for Teams. Requests can certainly help drive that direction a little bit so let me know what's important and we'll see what comes up on top.
Kyle
AgileBits
[Disclosure: I work for AgileBits]
I have been getting excited about Universal Two-Factor auth tokens. Sure, yet another standard, but U2F seems dead-simple from user perspective, and easy for developers to add to web apps.
If we rely more upon web-browser front-ends for 1Password UX, I'd feel way more comfortable with some kind of two-factor auth for the password vaults themselves.
I have inadvertently submitted my 1pw vault password to web sites, usually because keyboard focus changed and I didn't notice. Real people will inevitably do this from time to time, even in the absence of malicious phishing.
Good luck!
1Password for Teams has what we call Better Than Two-Factor™ through the use of an Account Key: https://support.1password.com/account-key/
The web client runs in Chrome, Firefox, and Opera, so Linux users will definitely be able to access it there. That's our immediate focus for now.
Rob
AgileBits
The mantra is more "under promise and over deliver" when it comes to these types of things. One of the sayings that has lived long in AgileBits (at least since I've joined nearly 4 years ago) is that no decision is ever final. So we might tell someone "nope, sorry won't happen" but then it could later, or vice versa.
So, future plans are something we try very hard not to discuss, and if they're ever discussed it's often by our CEO or founders :)
It's because we respect our customers that we do this. We don't want to lead someone on or misrepresent our intentions. Though, I can certainly understand how it might feel like we are avoiding the issue, we're not, we'd love nothing more than to tell everyone "yup, that's coming!" but reality is much different so we want to make sure we do our best by coming in level headed about things.
Hope that helps explain things a little at least.
Kyle
AgileBits
We all used SSH public keys (this was kind of new back then), so really only needed to consult the password book on certain reboots.
I'm obviously biased especially about the Android client :) but IMHO great iOS (and SDK), Android, Web Vault, browser plugins, Windows Phone, Surface, etc.
You would probably find our white paper on security and privacy very informative. If you'd like to give it a read you can find it here:
https://teams.1password.com/white-paper/1Password%20for%20Te...
If you have questions I'd be more than happy to make sure you get those answers. But this was a very important topic for us and that's why the white paper exists and I believe it should answer all of your concerns about security and privacy, if it does not then we will get those answered for you.
Kyle
AgileBits
Edit: I changed wording to "credentials (Email, Account Key, and Master Password)" from generic "data" which was sort of redundant and not clear.
None of this is directed at you guys, as I said, big fan. But at a climate that has left consumers concerned, cynical and distrustful of the safety of any of their data.
Remember my credit cards, alarm codes and personal data is within 1Password - the most precious of my data.
I have read the link and the other I have been sent and I will definitely continue using 1Password and I trust you guys as much as I anyone can be trusted at the moment. Certainly it's more safe than writing it down on a pieces of paper right now :-)
Of course one way to being even more transparent (but not necessarily more secure) is to open source your means of securing, transmitting and remote storage; not the whole product of course.
But with a highly funded secretive agency weakening protocols and strong arming companies, what are we to do :-)
Again great product!
\item[True end-to-end encryption] All cryptographic keys are generated and managed by the client on your devices, and all encryption is done locally. Details are in \nameref{ch:deep}.
\item[Server ignorance] We are never in the position of learning your Master Password or your cryptographic keys. Details are in \nameref{ch:SRP}.
\item[Nothing “crackable” is stored] Often a server will store the password hash. If captured, this can be used in password cracking attempts. Your locally held Account Key means that the data we store cannot be used for cracking attempts. See \nameref{sec:account-key} and particularly Discussion~\ref{aside:factor} for details.
A way of summing this up is that we've aimed to designed things so that our data store is not an attractive target. And that means not being attractive to LEAs.
With traditional two-factor authentication, an existing device is used to authorize a new one. But the existing device is only used for authorization. The one-time passwords are not used to harden the encryption.
Your Account Key works in much the same way. It is required to authorize a new device. However, your Account Key is actually used to improve the encryption of your data. Both your Master Password and your Account Key are required to decrypt your data.
More in that article. :)
Given the nature of passwords, if you've removed someone from the team you'll still want to change passwords for any items they have had access to if that's a concern.
Does that help answer your question? I'm happy to give you more information if you have more questions or if I somehow misunderstood your question. Just let me know!
Kyle
AgileBits
While in theory the passwords should be changed, but shouldn't a new vault key also get generated/encrypted and the existing passwords get re-encrypted with the new vault key?
The case I was thinking about is: If for whatever reason that revoked user got access to an encrypted password that got added after he was revoked, he can still use the same vault key to decrypt it.
On a different note, I was trying to understand the granting access part and so far (correct me of I am wrong :)) I think it has to be done in a 3-stage process. 1. invite user, 2. user accepts and generates priv/pub and pushes encrypted priv + pub to 1password, 3. admin confirms the grant by encrypting the vault key with the new user's public key. Did I get it right?
Lastly, would it be more secure if instead of using a master vault key just rely on priv/pub key of each user. When one member adds a new password, they encrypt it with each user's public key and provide it to them (can be considered as a big disadvantage to this approach). I think it makes revocation easier and denies access to future passwords since the user will be out of the team and won't receive new passwords created. But I am not a security expert, so I won't claim anything. :)
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 note, this isn't enforced by the cryptography.
There is a technique, called "lazy encryption" by some, to manage this sort of thing. What would happen is that any time there is a password change or someone is kicked out of a vault, a new key is created for the vault and all changes and new items are encrypted with the new key. The new key will also encrypt the previous key.
With this, someone who still has an "old key" can cryptographically decrypt things that they could have before (but they could have saved those things before), but would not be able to get at new or modified data.
I spoke about this problem (as it applies to things like a password change) in my talk at PasswordsCon 2014 in Las Vegas, which should give you some idea of how long we've been thinking about this problem.
We've got some of the underlying infrastructure in place for this, but as you can obviously see we didn't get this all working by the time of the release of our beta.
But I cannot make any promises whatsoever about when it will actually be implemented.
What would be nice is to have 1password regenerate and assign new passwords for certain supported services when a user leaves a vault. Not sure about its feasibility but if implemented correctly it can be a big feature win.
Standardized password change forms would make our lives (and our customers' lives) so much easier.
It's not impossible, but it it takes a lot of maintenance, to make sure that it behaves as expected. And when you are automating password changes you really want to make sure that it does work as expected.
But it can also open the door further(not that it cannot now) to have 1password team become central password store for your production environment. I can envision a 1password agent (with hsm support maybe) running on a machine to provide processes with required passwords/keys as a way to eliminate the need to store passwords on disk. If the box gets compromised, changing the password in one central location so that others pick it up can be convenient.
food for thought. :)
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 key operations. And it makes things more complicated in finding efficient ways of actually getting things to the right individuals.
But as things develop we may switch to something more in line with what you suggest.
The client will still have to encrypt for every user they need to give the password to and I don't know how expensive can this be in a large team but my assumption here is that people read passwords a lot more than write/edit them.
Rob
AgileBits