Maybe I'll be the only 1Password fanboy in here. I use 1pw personally and LastPass for work (shared between team of a dozen or so technicians).
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.
Unfortunately 1pw is absolutely terrible on Android. So I was forced to switch to Lastpass even though 1pw is generally superior because I need something that works on all my devices.
Specific Android issues:
- The Android keyboard doesn't autofill fields - in ios I could use the share extension and it would attempt to autofill
- the search is hidden behind a menu and isn't present at all in the opening screen - have to go into a category
- search is broken - doesn't return a list of searched for items as the ios one does, it displays suggestions instead
- if I click on a search result and go back to select a search result I have to search again
- design is dated. The ios app looks great the Android one looks really old and dated even compared against last years apps
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.
Sorry to hear that you're unhappy with it. I think you'll be happy with the progress when you see the next updates. There's some work being done to modernize the interface and some of your list will be tackled by that. I would encourage you to take a look at my other comment in this particular tree of comments about Android. It might offer some perspective, not that it's an excuse but it explains things a bit more and might just help in understanding.
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 for the detailed reply. I do like 1Pw - it is so very well thought out on mac and ios that I expected something similar on the android side too. Good to see it is being worked on and will hopefully become a first class app alongside your other apps.
I recently switched to Android from ios and literally everything on 1password Android is vastly inferior to the ios version. It's like the ios app is developed by a crack team of experts while the Android app is developed by a part time intern working for free.
With respect to our Android developers they have an uphill climb to catch up to iOS. Our iOS application has been in development for something like 4 years now, and several years before that as a previous incarnation (version 4 was a complete rewrite).
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 :)
Hi Kyle, thank you for participating in this conversation. I am sure everyone here appreciates it.
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.
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.
Happy to participate. I read Hacker News regularly myself so getting a chance to jump in and be involved is always fun :)
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.
I actually had this idea back when I first started at AgileBits and had to really start maintaining ssh keys for work purposes. Prior to that it was mostly just side projects and my own personal stuff.
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 :)
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).
Sounds good. You're welcome to send any thoughts to me privately. My email is my first name (see the username here and remove the first two characters, ag is our shorthand for AgileBits). Then @ company name .com.
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.
Hi - have you tried Keeper? We have 9M users - and as a benefit for someone like you we're platform-wide with native apps across all OS's, devices and browsers - our users love our Android experience. www.keepersecurity.com
Interesting - lack of active directory integration, and lack of on-prem solution is disappointing though.
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.
Really don't want to see anyone get down voted here for having an opinion. Different opinions are what drive conversation, so, I won't ignore your concerns here.
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 :)
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 :)
Hey, thanks so much for that. Seriously, means a lot to come in here and know full well you're not really the right person to answer the question but give it a shot anyway and the other party is gracious enough to explain it.
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.
Recommend including LDAP integration in addition to Active Directory. With such a large Mac userbase, you're likely to have more customers using LDAP than AD.
1pw user here and long time AD architect. If you have any questions around AD/LDAP, I'd be happy to answer what is 'common' when dealing with AD-integrated solutions.
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 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.
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.
We already use something like this product but with a vastly worse UI / UX from CyberArk. That's the kind of feature set you'll need to sell to companies that aren't already Mac users or larger than 1000 employees on a consistent basis. Unfortunately, you'll probably need to hire 5 new people per F100 customer at a minimum but if that sort of growth is what you want I assure you it's mandatory.
Please try, please help make the enterprise security software market suck less :(
Key points for that specific page from a UX perspective that may be a little off-base, but I'm trying to put myself in the shoes of some of the folks that have the purchasing power and are very much imperfect people.
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.
I realise you may not want to do Active Directory, however it is quite common even in small companies -- and you can even get AD via Azure nowadays. Even lots of Mac-only shops have AD.
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)
I'm sure they do, that doesn't in any way invalidate my statement. I can't say I have a single customer using either one. They're all using either secret server, or one of several other apps they can run on premise with AD integration.
Have you tried Keeper Enterprise? We have AD/LDAP integration - it was a mandatory feature for us too. In regards to on-prem, Keeper uses zero-knowledge encryption - which means the encryption keys are stored locally on the end-user device. We have over 3k businesses signed up, many of them in the Global 2000 (and 9M consumer users). Our enterprise customers are happy with our cloud architecture because of the zero-knowledge encryption and regular SOC-2 audits.
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.
Is there a reason why you're using RSA over Curve25519? RSA is old and rusty at this point and there's no good reason that I know of to be using it in new cryptosystems. To a much lesser extent I also have the same question about using AES-GCM over Poly1305/ChaCha20.
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. 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.
Thanks for the answer! WebCrypto is obviously a disaster, it is very unfortunate that new systems are being stuck with legacy crypto if they use it instead of non-native libraries.
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 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.
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 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 had hoped AgileBits would step up their Windows offerings.
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.
I rely upon 1pw on iOS and Mac, so I was really happy with the Windows Store version of 1pw.
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.
We actually have different teams working on each platform, mostly anyway (our iOS and Mac teams have people who rotate between the two in addition to having dedicated members for each). The drop in noticeable forward momentum (at least publicly) on all of our projects over the last several months has been due to getting Teams implemented, everything seems calm on the surface but underneath there's a lot happening.
Our Windows developers will get their day to shine soon enough as well and we hope you'll enjoy the work they've done. :)
Why is it an issue that LastPass was sold to LogMeIn? Does that company have a bad reputation, or...? This is a serious question. I am not familiar with LogMeIn.
I'll repost what I commented on the LastPass sale. LMI basically just skirts by, doing just enough not to drive their users away -
"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."
LogMeIn has a history of buying useful products and then raising prices on them without much warning. I was a faithful customer of Hamachi until LogMeIn purchased them, upped the price, and then tried to lock me in to a subscription.
If anyone doesn't know enough to put comments like this in context,
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.
Out of curiosity--have they been successful with this strategy?
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.
Apart from the pricing plans --makes it difficult to invest in uploading all our company secrets if I don't get a clear return--, what about Linux based desktops? Will this be only Mac/Windows centric?
Are there single-sign-on options for Google Apps for Work?
There is absolutely no "lock in" if you try out the beta.
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.
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.
In fact, probably the guy responsible for storing most passwords is your friendly sysadmin, and a lot of them won't get caught using a GUI on Mac or Windows ;)
There's a fair bit missing. For now, the web client is read-only but we have full intention to make it able to edit, it just wasn't something we had time to do before the public beta.
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.
"eventually" doesn't allow me to use it now though, unfortunately.
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.
I know this isn't a complete solution, but 1Password for Windows runs OK under Wine, and with some registry tweaks as the browser plugins work OK too. The exact details are documented here: https://discussions.agilebits.com/discussion/42126/making-1p...
I verified this afternoon that this works with Ubuntu 15.10.
Remember this is all still in beta. Adding support for editing items within 1Password for Teams is definitely on the must-do list. It's not one of those "we'll see how it goes and maybe we'll add it" features. :)
Really exited for this - was literally just looking to put a vault on a shared drive (yuck)...
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.
1password has always been pricy and I've been a happy user. But please please entertain having realistic enterprise pricing. If so, I can get an org of several hundred people on it.
Heck, if you offer a good enough deal, I might be able to get a whole bunch of sister companies on it too.
This is pretty awesome. Super excited to try it out.
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.
A nice addition, we are currently using LassPass Enterprise, and the UI is absolutely terrible, but being the only game in town kind of forced our hands... now there's options!
Hi! I can tell you our experience at company I work. We were looking for any tool to make simple share "but not deliver control of password" because we wanted to show customers that "we take care" about their passwords.
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.
Auditing who accesses credentials is pointless, IMO. So you know that Tom, Jane and John have all accessed the domain admin credentials since they were changed last week, what good does that do you? They all have reason to do it, and any one of them could have written them down so it's not like you can audit who pulled them up 15 minutes before some huge security incident and know who was responsible.
Not necessarily. If you have an organization with 100 users and most systems are accessed rarely, an audit log can show you things like "Steve accessed ALL the credentials."
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.
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.
... provided your team doesn't include anyone using Linux. I asked them whether they had any plans to support Linux recently and got a disappointing "no comment" type of reply. Not impressed.
Sorry you were less than impressed. We can't really discuss future plans, but we are working to mature the 1Password for Teams web client into a fully functional client that can add, edit, and delete items. The whole thing is still in beta right now, but it's definitely on our must-do list.
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.
We're eagerly awaiting an alternative to LastPass after the recent sale. 1Password is the best on OS X, but really lags everywhere else (Win, Android), but the total lack of support on Linux (for writing) is a non-starter. It'd be great to see something, even a simple CLI app to provide basic password read/write without a GUI. The threads in AgileBits' forums referencing this topic are really depressing. Is there another way to express a "vote" for basic Linux support?
Duncan, the reason we try not to discuss future plans is because until something ships we can't 100% for sure it'll make it into the wild. We've had instances in the past where we discussed future plans and due to unforeseen issues couldn't follow through with them.
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.
We really could’ve used this at the startup where I worked a few years ago. We were using the, uh, analog equivalent: a manila folder full of handwritten passwords locked in the founder’s filing cabinet.
I work for a password manager that has had teams for a while. We have an encryption key per record with fast search. An open source command line SDK and Java desktop client which is great for linux. A great Android app with autofill, material design UI (more to come), which has been in the Google Play store since day 1, etc.
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're getting down voted and unfortunately that's a bit disappointing. That said I am happy to discuss with you how Teams is setup so that you can fully understand how it works and realize that we (AgileBits) can provide zero access to your data to anyone, including yourself, without the proper credentials (Email, Account Key, and Master Password).
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:
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.
I'm actually a huge 1Password fan - my comment was joking but accurate to the point that no-one can guarantee data security in the current climate. How are we to know that any provider has not been coerced by their nation's security services into weakening their own security protocols - and then been slapped with an order forbidding them to discuss said changes (all within known current NSA practices).
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 :-)
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 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.
And yet another app that would rather become an OS on its own rather than stick to one thing but 'do it well'. 1Password.app has already been taking ages to load since the shiny/pointless redesign a year ago, and now we're getting even more features…
However this is a pretty significant feature - I really wouldn't tag it as bloat, but as the next logical step for 1Password and judging by the comments here I'm not the only one who has been waiting for this.
You will be pleased to know that 1Password for Teams does not use Dropbox for syncing and has what we call Better Than Two-Factor™ through the use of an Account Key. From our "Understanding the Account Key" article (https://support.1password.com/account-key/):
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.
When you remove a user from a team (or even a vault) the vault or team is effectively removed from the user's computer. The account will still "exist" in the preferences but it'll be suspended and their only option is to delete the account or have the admin restore the account.
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!
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. :)
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 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.
Ah got it. I think implementing it as a server policy is fine for now.
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.
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 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.
Agreed. The lack of standards around this makes it very challenging and the implementation will be against a constantly moving target. We all know how this ends. :)
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.
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 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.
Yes, it definitely has cons and introduces complexity. But maybe if a proper REST API is built around the concept it can reduce some of the complexity at the surface.
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.
They can't seem to fix a simple bug that prevents the mini 1password menu from not being behind the menubar. Really pathetic or maybe its fixed now hopefully. Please FIX OMG
Hey, thanks for the feedback. I'm not sure I know which issue you're referring to. I've not seen the menu show up behind the menu bar. Could you follow up with us on our forum? https://discussions.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.