What is the future of local/standalone vaults?
Comments
-
@neil_laubenthal - I perhaps should have mentioned earlier before you went to such lengths to explain things that I'm a member of the Security team here, so I'm relatively familiar with password creation/entropy/attacking issues. ;) I hope you won't feel as if you wasted your time. Honestly, many discussions here that dig more into the details of issues are often of interest to other community members who may read them, so thank you.
The statement that local backup is “coming in a future release” of v8…is simply obfuscating the issue
I'm not sure quite how? I've been very clear with you in saying that local backup/restore capability is indeed on the list of items scheduled to be coming prior to the public release. The current Early Access release of 1Password 8 for Mac that you downloaded and installed is exactly that - an early access release, which is not (all of) what will ultimately be shipped when 1Password 8 for Mac is released publicly -- that's the point of a beta: to gather feedback and help identify issues. If local backup and restore is critical to your workflow currently, it should be entirely possible to simply resume use of 1Password 7 for Mac, and we'd be happy to help you do that if you're having trouble. You can write in to support@1password.com and any one of my colleagues in Customer Support will be happy to help get you back up and running on version 7. :)
0 -
@neil_laubenthal Part of the reason I keep distinguishing between local and stand-alone vaults is that, even when the person who posts knows the distinction, someone reading the discussion may very well not know.
I consider they are different, as a stand-alone vault to me means one that does not communicate with 1password.com (for syncing, etc) at all, whereas a local vault can be used without a link to 1password.com, but will go there for syncing and other functions.
As to your comment that releasing version 8 without local backup is unacceptable I agree with you. Where I disagree is that you, and others, seem to be treating the current 1PW8 as if it were a release version rather than the beta it is. I can't see any reason except curiosity, and perhaps a wish to help AgileBits with development ,not to stick with 1PW7 for at least six months and possibly as much as eighteen months.
0 -
@lars - Perhaps it wasn’t you specifically…but somewhere on the forums I saw a post from somebody at the company indicating that local backup and restore capability was a future thing and not a before release thing. Sorry if I sounded accusing but having read a bunch of 5hreads here it’s hard to remember precisely who said what and when and which thread. If having local storage backup, restore, and recovery/replacement of the online vault with the backed up data is in the pre release plan then my statement might have been a bit of an over reaction. I would still personally prefer local vaults and DropBox sync…as would others…but that’s just me. I can live with losing those and a non native client as long as the client works better than most of the user comments I saw the other day…but then it’s an early public beta so I imagine a lot of those will get fixed. Will the local storage backup ability be automated (I.e. daily) as in the current v7 macOS client or just as an on demand thing…or do you know? Automated is clearly a better backup scheme as you know…and while I’m pretty sure that whatever backup stuff y’all are doing on the server side are just fine…nothing replaces an independent user side backup and restore capability.
Yeah…it wasn’t obvious that you were part of the security team…and while in a math sense double encrypting is probably better than two individual single encrypting with say the DropBox password…it wasn’t clear that you were getting my point that the latter is really good enough for just about everybody and if a user prefers it that way then IMO y’all should support that. It doesn’t use the Secret Key…but if a user is willing to accept the lifetime of the sun as opposed to the heat death of the universe for more of the user preferred method then it seems to me at least to be more customer friendly to allow both approaches while explaining that in the company’s view it is a less secure option. Not all users will want local backups of course…but any that were in the sysadmin biz for 20something years like I was are likely to have complex multiple backup schemes in place that work for them they play they want them too.
We got sidetracked a bit in our discussions re better vs good enough I think…no offense on my end at any rate…vigorous discussions are always good IMO…I’m on a photo forum named Ugly Hedgehog and you should see the arguments they get into there, especially in the Attic anything goes forum…the reasoned debate train left the station there long ago.
A couple of suggestions about v7 assuming that my suggestion about retaining those capabilities in v8 doesn’t meet with management approval.
First…on iOS make the new version 1Password 8 so that it’s a separate app in the store to make things easier for those users who want to stay on v7. On the Mac App Store it’s already named 1Password 7 so just name it 8 there as well and keep both versions in the store. Making it easy for users who want to stay with 7 is good customer relations. I’m currently in that camp but will wait to see what v8 has local backup/restore wise before making a choice and until I se3 how the released macOS client works…although I prefer a native client it isn’t a dealbreaker for me.
Second…some sort of commitment from the company that v7 will be supported for future os upgrades would likely keep those customers around rather than driving them elsewhere…because elsewhere doesn’t currently exist. You can get native clients, DropBox, local vaults, Secure Notes and file/image attachments as well as iOS/macOS/iPadOS cross platform but I’ve not found anything yet that gives all of those without doing a sort of roll your own combination of packages. Obviously forever support isn’t something you can promise…but for example a statement that v7 will be supported through 2025 and that the following set of capabilitwill be restored to v8 by then would calm a bunch of folks concerned that abandonment is nigh unless they change the way they work.
I’m actually interested in the self hosting option at least from a curiosity standpoint. If it is a low or no cost user accessible option sort of thing…I could see myself using it. If it’s a more costly you need a corporate IT department sort of thing aimed at enterprise then users aren’t going to be interested or qualified to run it. I’m guessing it’s more of the latter than the former. And as I said…I’m not morally opposed to subscription license, no DropBox, or no local storage even though I would prefer all of that…but if the local backup/restore functionality is part of the v8 release plan I have fewer objections.
0 -
@danco - I get your point about local and stand alone vaults…it isn’t the way I think of them as vaults that don’t sync don’t make much sense…and in the current implementation of v7 a DropBox or iCloud vault is both of those since 1Password.com isn’t involved. I understand the beta process of course…and @lars later post indicates that it’s wa before release feature…but someplace here on the forums I saw a 1PW person that said it was a post 8.0 release feature to be added later…at least that’s the way I interpreted the statement. @lars statement this afternoon seems to agree with both of us. I tested the beta myself…and it’s IMO not really ready for public beta testing…but that’s just me based on other beta stuff I’ve used in the past. I certainly wouldn’t trust it as it is now with my vital password data…too many missing features and things that don’t work…in addition to the impact it would have on my current usage which is local storage DropBox sync. @lars and sort of talked past each other a bit in our discussions of better vs good enough as you see in my reply to him. And as I also said to him…I think they should have both of those capabilities in v8 for users that want them and just accept that some users are willing for good enough instead of better than good enough security. Of course…some users would then choose local vaults and not bother with backups and lose data with subsequent blaming the company…but make the limitations clear in the docs and in say a dialog box when they click the local storage vault option or Dropbox sync option.
0 -
I am a longtime 1P user, since v3 I believe and like many others have recommended it to countless clients and family members. The decision to drop support for local vaults is a deal breaker for me. I have no interest in uploading all of my most sensitive data to yet another cloud service that will increase my exposure to malicious actors. The 1P.com service presents itself as an irresistible honeypot to bad people looking to score a trove of sensitive data.
This is a sad day. I guess we should have seen the writing on the wall with v7, but hoped that security concerns eventually prevailed. Seems that is not the case.
Not looking forward to evaluating alternatives to 1P, but I feel like I have no choice.
0 -
Hi @jpons
The Secret Key was designed to mitigate that concern:
About your Secret Key
If you have any questions we'd be happy to help.
Ben
0 -
Hi @Ben
Thanks for your reply, I understand the Secret Key and looked at it when v7 was first released and just looked at the information you provided again.
The issue I have is that the 1p.com service presents itself as a very LARGE trove of ultra valuable information, hence making it extremely attractive not only to hack into to steal the data, but also to break the encryption since the payoff would be so astronomically large. One only has to look at cases like LastPass. I trust Agilebits systems implementation much more than that of LastPass but still having all that sensitive info in one place makes me very uncomfortable.
Local vaults are also encrypted and could be hacked into and the encryption broken, but because they are distributed the payoff of hacking into all if our individual devices is exponentially lower and therefore nowhere near as attractive as ONE location that holds the sensitive data for hundreds of thousands if not millions of users.
Think of this scenario, a malicious actor figures out a vulnerability of the 1p.com Secret Key, all they would have to do is hack into one system 1p.com to gain access to the sensitive data for so many people. Where as using local vaults even if a malicious actor was able to break your Secret Key encryption they would still have to locate individual vaults of users, hack into those systems, download them, and get the data. You may say well most people have their vaults on Dropbox or iCloud, and that is true, but while those systems could be vulnerable to hacking, they are designed, developed and implemented by a totally different team and most likely design and security philosophy making it more difficult to implement a breach using the lessons learned from one vendor.
Having distributed vaults makes the economics of hacking into and breaking the encryption on individual vaults far less attractive, hence why I used the term honeypot when describing the 1p.com service.
Hope that makes sense.
Thanks,
-J
0 -
That's the thing about the Secret Key: it is unique to each account, and is never known by the server (so it can't be stolen from it). You can't decrypt the data 1Password.com has without it. Even if someone were able to steal all of the data 1Password.com has, brute forcing even one account's secret key would be impractical, let alone brute forcing all of them.
Part of the beauty of it is that it protects you even from those who legitimately have the highest levels of access possible to 1Password.com.
Ben
0 -
Thanks again for your responsiveness, but perhaps I am not making myself clear. No software is infallible, and neither is AgileBits. If there was an error or deficiency in your encryption systems and/or software that a malicious actor was able to exploit then the 1p.com system would be a major goldmine. The impact of such a deficiency would be much less severe in the case of individual vaults.
You may say that your software has been tested and proven to be safe, but there are countless examples of implementations by many different entities, including commercial ones as well as governmental ones, that have proven to be deficient despite assurances.And that is not even considering the issues with the infiltration into encryption algorithms by entities such as the NSA which have been proven in the past.
Every individual has to make a decision as to what risk they are wiling to tolerate in this (and many other circumstances) and for me the fact that humans (developers) and the software they develop are not perfect and the honeypot that the 1p.com system presents in case of such an exploit is too much for me.
I need to keep my information as safe as possible and uploading it all to some web service is just not secure in my eyes.
Thanks,
-J
0 -
@Ben The issue of standalone/local vaults vs. cloud-synced vaults is fundamentally one about risk and risk surface. It's not just a question of "do we trust AgileBits"- I honestly, totally, genuinely, no-sarcasm agree and believe that 1p.com is well-built, well-designed, well-maintained and well-administered. You folks clearly know what you are doing, and have the necessary financial and technical resources to run a system like 1p.com in a responsible manner. I have also read the security whitepaper and agree that the design seems cryptographically solid and, assuming the implementation is actually in line with what the whitepaper describes, is about as good as something like that is likely to get. And obviously (to me) we have no reason to believe that the current implementation is anything other than what it claims to be.
However, no matter how good the system is, and how on-the-ball you all are about maintenance, security, etc., it is a simple fact that going from "everything lives on my local machine" to "everything is on somebody else's machine" represents a big increase in risk. People make mistakes, systems and organizations get compromised, software supply chains get corrupted (especially in the Node ecosystem), etc.- it's a basic fact of nature, and it is not an indictment of any particular organization to say so. And that's why I would much, much, much rather have a standalone vault: it makes me as a user very uncomfortable to have to even have to think about "how much can I rely on AgileBits's security and devops process" and "how do I know if the cloud syncing thing is actually built as described in the whitepaper"- I just don't have the information I need to make that kind of risk assessment in a serious way, and as an outsider I can't, which is why I really would rather just avoid the entire problem altogether by keeping my data under my own control.
Obviously, different users in different situations would make different risk assessments. In my professional life, in a regulated industry, I work somewhere with entire departments whose job it is to make those kind of risk assessments. There are also teams that design and implement mitigation strategies, and deal with the legal and practical consequences of things going awry. In my personal life, I don't have that level of support and thus my level of tolerance for taking on extra risk is decreased. Hence why I keep bringing up the question of why 1P8 can't have an offline-only/standalone mode of some sort.
0 -
@StevenBedrick well said
0 -
@m4rkw - I had a longer reply to you drafted up when you posted that original comment, but looks like I never finished it, and Ben has covered it frankly with a lot more economy of words than I was using.
You're correct that the web app introduces some risks that are not present anywhere else (such as ALL of the 1Password apps using 1password.com accounts). Indeed, we document this in Appendix A of our 1password.com security white paper. Page 53 (I think it is) states:
The authenticity and integrity of the web client depends on the security of the host from which it is delivered. An attacker capable of changing the web client on the server could deliver a malicious client to the user.
Ben is also correct, though, and it bears repeating: there is no possibility for (paraphrasing one of your earlier posts on it) credentials to be exfil'd en masse for tons of users and companies all at once. It just doesn't work like that. Credentials could not be grabbed "en masse" because they are not stored on the 1password.com servers. What could potentially be gathered, at best, would be credentials for any user who signed in via the 1password.com web app (i.e. - in a browser at https://my.1password.com, NOT the browser extension) between the time of the successful deployment of the malicious JS and our discovery/remediation of it. While such a breach would obviously be far from ideal, compromising our server to that extent would be a very heavy lift, and under no circumstances could it be effectively targeted at specific users -- an attacker would just get what they get during that short window.
How would you update your billing information securely? I suppose that gets into the fine details about what "securely" means, functionally. Will we warrant it's impossible for such an attack to occur? Of course not; responsible disclosure of potential risks - however remote - would insist we don't do that. That's why we included it in the white paper. To be very clear, we think the real-world possibility of such a thing remains very unlikely. But it is theoretically possible.
Absent such a (successful) attack, however, in terms of security, the web app is delivered securely (modern TLS only, with appropriate cipher-suites and HSTS to protect against downgrade attacks), and there are multiple server-side defenses in place to prevent (and detect) such an attack as well. It's also worth considering: how often are you updating your billing information or performing other administrative tasks that can only be accomplished via the 1password.com web app? I suppose answers will vary, but I rarely update payment information; only when a card I use is expiring, or in the infrequent and uncommon event that the payment method itself has been compromised and needs to be changed.
Ultimately, the way forward with this will be adding more administrative capabilities to the codesigned apps that currently only exists in the web app, and/or adding a PKI structure that includes a certificate chain which is external to the browser's, to check the delivered JS content in the web app for tampering. In the meantime, just like at all times, in fact, each user should perform their own threat modeling, including their own risk tolerance. Concluding that only local data with no sync whatsoever is the best solution for one's situation is as valid a strategy as any other, depending on circumstances and preferences. And if that is your - or anyone's - conclusion/preference, there are solutions out there which will meet that need -- 1Password is just no longer among them, currently.
0 -
To add, if an individual user wants to completely avoid the web app, they can do so today if they're willing to use Apple or Google as a payment provider. You can create an account in one of the desktop/mobile apps, manage billing with Apple/Google, and never use any of the administrative functions exclusive to the web app. I think that puts one in the weeds a bit in terms of paranoia level (due to the items Lars hit on), but we're all entitled to our own risk tollerance and assessment. I just think one should be informed when making those assessments.
Ben
0 -
@Lars That's exactly the scenario I'm envisioning, a motivated attacker would be able to collect credentials for anyone who logged in while the website was compromised. Maybe it's highly unlikely, but with a standalone vault it would be impossible.
Perhaps you could start publishing hashes of the javascript on github when it gets changed so that paranoid users could independently verify it hadn't been altered before logging in.
0 -
I appreciate the amount of detail that’s coming out of this thread - both from those with misgivings, like me, and also from the very in-depth responses from the 1Password team. It’s helpful to me, and hopefully to others too. In that spirit, and as a non-technical user, here are two other issues that bother me a bit about the new direction:
1 - As I understand it, the electron framework you’re using in 1Password 8 is (very roughly) a 3rd party wrapper that takes your web app and makes it look and behave like a native mac app. Is this correct? If so, how much control do you have over the security of the electron framework? Also how is this more secure than the web app - if they are both fetching the same data from the 1password server?
2 - For now, standalone vaults are going away. What is better - from a user POV - about having all the data centralized on the 1password server (as opposed to stand-alone vaults)? What functionality does this bring that was not there previously? Or is it more about efficiency of software creation and maintenance?
0 -
@Questulent - Electron is an open-source software framework. We've discussed its use quite a bit here on this forum, on Reddit and in other forums since the launch of 1Password for Linux in May (actually, to some extent going all the way back to the initial beta in October of last year). Using Electron does not mean that your app is a "web app" in the sense that anything "wrapped" with Electron is nothing more than a web page. It could be that, but it certainly doesn't have to be.
And in our case, it is not. We spent a good deal of time thinking about how to harden Electron for use with our purposes and the Rust back-end where all the real work is done (Electron is essentially UI, Rust is the back-end language). I'd recommend this section of the 2021 NorthSec conference, where our Mitchell Cohen discusses the hardening we did to Electron to make it suitable for our purposes.
In terms of the difference between the web app and all other 1Password applications, a couple of things up front:
- This issue has nothing at all to do with 1Password 8 or our decision to use Electron for part of it. It has existed as long as browser-based access to 1password.com accounts has existed - in other words, since the beginning of 1password.com accounts (late 2015).
- The potential vulnerability doesn't have to do with the 1Password data that's being exchanged (which is encrypted), but with the potential theft of credentials. As we state in Appendix A of our white paper, an attacker capable of changing the web client on the server could result in the ability to deliver a malicious (fake) client (website) to the user. But ONLY to a user who has opened their browser (Chrome, Firefox, etc) and typed "https://my.1password.com" into the URL bar. The difference between that and all 1Password apps - including 1Password 8 - is one major thing: SRP (AKA: Secure Remote Protocol).
You can read about SRP in considerably more detail in our 1password.com security white paper if you wish, but essentially when a 1password.com account is created, a verifier is the only thing shared between the server and the client. It allows each, through the magic of math, to be 100% certain that the other is the genuine article and not fake or tampered with. For every successive connection between the server and any 1Password app which has already signed into any given 1password.com account, only that verifier is used to determine whether the server is authorized to exchange encrypted data with the client, and vice-versa. In other words: no credentials which could be "harvested" by a malicious web page (not Account Password, not Secret Key) are used when you use 1Password in an app, only this verifier. This is true for all platform apps (Mac, Windows, iOS and Android, as well as for 1Password in the Browser (the extension). Only the web app (not the 1Password browser extension) has the potential to be hijacked by a malicious JS client served by an attacker who manages to breach the 1Password servers. It's important to note that this has not happened in more than five years, and we mention it in the interest of transparency because it is theoretically possible, not because it has occurred or we consider it a leading attack vector possibility. I've discussed up above some potential additional remediations and verifications that we've been considering that we may be able to employ to help secure and/or verify the integrity of the web app.
If you're asking about what's better about having your data on any cloud-based sync service as opposed to either only on a single device or only synced locally, I would start with ubiquity of data and changes/additions to it. If you don't sync your data at all, you will only use it on a single device. If that's all you ever need, then that might be a good solution. Most of us use multiple devices, however, from our home desktop or laptop computer to our smartphone to various tablets, work computers, and other devices. Having your data everywhere you need it is certainly a usability advantage. Your credit card details don't do you much good, after all, if they're only resident on your home computer, and you're out somewhere. If you sync only locally (via home wi-fi, etc), you also can't get changes to your data unless you remember to sync while you're home. If you add new items and happen to forget to open your phone and sync the changes/additions while both devices are still on your home WLAN network, well, again -- that data won't be on your phone when you leave. A cloud-based sync solution also means that whether you have one device or half a dozen, if they are lost or destroyed or stolen, all you need is a new device, download the app, enter your password, and re-sync up your data in seconds. Losing a device (or forgetting to copy the data elsewhere before selling, etc) doesn't equal the likelihood of also losing your most-important data.
If your question is in regard what's better about 1password.com specifically than 3rd party sync services, where do I start?
- The security advantage of the Secret Key
- Individual item history and restore (make a change to an item you need to revert? Now you don't have to replace your entire database with a backup - if you even have one with the proper info you need)
- Travel Mode
- Account Recovery (it used to be: forgot your 1Password? Data is lost (can't be decrypted). Now, there's a secure way to prevent that possibility.
- Command-line interface
- Secrets Automation (if you use 1Password in an organizational/group account)
And that's just some of what we've built so far (and there's a lot more coming!) that can only be built on 1password.com because we can work with both ends of the data connection - on individual users' devices and on the server. With 3rd party cloud sync, we're limited by definition to the sync capabilities of the specific platform (iCloud, Dropbox) offer. Both those services are great -- but they are not customized for 1Password sync, and we do not own or control them. We are limited to the published APIs, and they have to sync your cat photos, your videos of your kids, spreadsheets -- in short, it's a much less tailored experience, and hence more limited...and the options for us to innovate are correspondingly fewer. On 1password.com, we can build what we - and more importantly, our customers - want. Yes, we're aware there is a small number out there who primarily want to have local vaults and the option for manual 3rd party sync (or no sync at all), and as this 1Password 8 early access launch has made clear, that won't be a part of 1Password going forward. We wish those folks well and we will be here for them should they decide they want to return at any time in the future. In the meantime, we'll continue to make 1Password the most secure - and usable - password manager available, for everyone. I hope you'll join us. :)
0 -
Can I add that, as far as I can remember, there was a period of time ages ago when Dropbox changed its APIs and so 1PW lost its ability to use Dropbox sync for several months. That's a disadvantage of any sync method not controlled by AgileBits.
0 -
Forgive me if this has been answered already, but I haven't had time to check the full 5 pages of discussion: for those of us with local vaults in iCloud who remain on 1P7, what happens when the iOS app gets updated to v8? Will the iOS version lose the ability to stay synced with the vault?
0 -
1Password 8 will be released as a separate SKU (essentially a separate app) on the App Store. 1Password 7 will not update to 1Password 8. It'll be a separate download.
I hope that helps!
Ben
0 -
I wish I could answer that aspect with more certainty. I'll do my best but please understand some of this is undecided and some relies on behaviors outside our control.
- There may very well be an overlap in the period between the release of 1Password 8 and the discontinuation of the listing of 1Password 7 in the App Store
- Once the listing for 1Password 7 is discontinued customers who have already downloaded the app on their Apple ID will be able to continue to do so using their Purchase History through Apple: Redownload apps and games from Apple - Apple Support
- Whether updates to the app after that point will even be possible is a bit hazy. In speaking with one of our product folks we both vaguely recalled a situation with 1Password 3 for iOS where an update was required after retirement. In order to get this update customers had to follow the same procedure as above, going through their purchase history. The update wasn't delivered automatically like updates are for currently listed apps. That was many years ago. It is possible things have changed since then or will change again in the future, but either way that bit is outside our control.
I'm sorry I can't make more specific promises than that, but there are a lot of moving pieces.
Ben
0 -
you always could ... you know ... not drop local vaults?! 😒
0 -
Sorry @ingorenner, that’s simply not an option. My (admittedly long-winded) post earlier in this thread tried to explain why this is a necessary change. If you haven’t had a chance to take the self-hosting survey yet, please do so we can better understand your needs.
++dave;
1Password Founder0 -
I think it's just a matter of whether you want it or not. Clearly you simply don't want it.
I don't see the benefits. All the things I personally need are available in P1 7 already. I can see the need to sometimes share passwords, especially in business settings. For my personal/private use cases I will never share any passwords though. All the other features like Watchtower don't need cloud functionality.But alas, it seems you made up your mind and so that means I will be moving on from 1Password when the time comes where 1P 7 goes away. It's been a good time for 12(?) years...
0 -
@ingorenner : well said, and I agree. It is written in stone - for AgileBits. And it is written in stone that many Mac users will move their passwords to a different app and stopp using 1Pwd (v7m or never use v8).
The Mac users, mostly the private ones, were ignored from the beginning since the alpha v8 is available.
Why did AgileBits release first alpha v8 for Linux and Windows, and not for Mac? The "protest" would have been to strong, now they say the final v8 will be released soon. Too late too stopp or switch.
Apple did the right thing with their last big project (CSAM detection) - to stop it and analyse the feedback - because they realised and saw something coming up. AgileBits never wanted to see it. Apple listens to the "protest". AgileBits listens only to "here is a bug, and there a small one".
@dteare : Please, Dave, if you have not understood the needs of your customers during the last years, then you will not understand it better with survey. I am sorry, but you worked for many, many years for a wonderful app, you got so much great feedback and won awards. But now you wonder what the needs of the users is?!0
