Feature Request: Auto-Change Passwords
Hello,
I have been using 1password for awhile and it's amazing. There is one feature though I wish I had. That is automatically going out and changing my passwords for me. Apologies if I am stepping out of bounds by mentioning a competitor... but LastPass does this and advertises it here https://lastpass.com/features/ :smile: .
It would be nice if the major ones were tackled like Google, iCloud, Github, etc. But then it would be even better to be able to define how to change custom site passwords. One idea may be to have a "record me change my password" button. I click that, and 1password starts watching the requests on the site I am currently on and records that for later use.
But aside from a magic button, I'm sure if I had to write a python/bash script that's far more than sufficient. Or have the site owners submit some form defining their password reset procedure that can be automatically pulled in. I currently have a recurring calendar appointment where I go through and change all my passwords. So anything improving that is a step in the right direction.
Thanks!
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
@joshault3: It's something we've experimented with in the past and may be something we do in the future, but there are a few reasons it isn't in 1Password now:
- So far, we keep pretty busy improving login filling, which is by far the thing most people use 1Password for every day.
- Automatic password changes need to be supported on a per-site basis, and then we get into not only keeping up with changes, but also playing favourites, since my "top sites" may not be the same as yours.
- Reliability is crucial. A failed password change can lock you out of your account. So having
- Password changes are rare.
But that last one, I think, is the crux of the matter: You really don't need to change passwords regularly. Research has shown that, in many cases, frequent password changes are worse for security, since many people use weaker passwords as a result.
But while I suspect you don't fall into that group, it just isn't necessary to be continually changing passwords. It doesn't offer a security benefit, and frankly, even if we had an "automatic password change" feature for certain sites, you'd still be doing them manually for many others. And ultimately, the uncompromised, unguessable password that 1Password generates for you today is no better (or worse) than the one it generated for you last year (or...last month?!) So while I don't want to presume to tell you how to spend your time, changing strong passwords isn't something I do without good reason, and I wouldn't expect you or anyone else to take on that burden either. Unless an account has a duplicate or otherwise weak password you chose yourself, it almost certainly doesn't need to be changed.
That said, this is something we'll continue to look at, and it may be that someday 1Password will be able to help make password changes more efficient. But so long as we're each using long, strong, unique passwords for each site (which is why we're using 1Password in the first place), we can take it easy. Unlike tires on a car (both cheap and expensive ones!), a good password doesn't wear out, no matter how often it's used. Cheers! :)
0 -
A recent security development highlights why changing all of your passwords at once may be necessary at times. I hope 1password is working on this now, because not only LastPass, but also Dashlane can do it. See this article from WordFence as to why it's absolutely necessary for some people: https://www.wordfence.com/blog/2017/08/chrome-browser-extension-attacks/
The first comment and its reply addresses this issue:
Jonathan Kamens August 17, 2017 at 12:12 pm • Reply
Is there reason to believe that anything other than Cloudflare credentials may have been stolen?
In other words, if I poll my employees to find out if any of them have these extensions installed, and it turns out they do, then what do I need to do other than rotate all our Cloudflare credentials if the employee(s) who had these extensions had access to our Cloudflare account?
Mark Maunder August 17, 2017 at 12:29 pm • Reply
If they have one of these installed and had it installed while it was compromised, then all bets are off. You need to do global password changes for that user along with revoking any keys that user may have and issuing new ones.
I am a website developer and have over 1,100 items in my vault. I can't possibly go through and change even a fraction of them manually, but if I don't, I'm putting my client's websites at risk.
Thanks,
Fran0 -
Your point is well taken, Fran. Thanks for the feedback. We don't have anything to announce at this point but we'll certainly take it into consideration as we move forward. :)
Ben
0 -
Thanks, Ben!
0 -
You're welcome. :+1: :)
Ben
0 -
I have never used this feature in LastPass, but automatic password change might be a great start for new users that have been using the same password (or multiple insecure ones) everywhere before using a password manager?
Yes, this will take regular effort from AgileBits, but isn't that what we can expect from you now that you're offering software as a service via subscriptions?
0 -
I have never used this feature in LastPass, but automatic password change might be a great start for new users that have been using the same password (or multiple insecure ones) everywhere before using a password manager?
Indeed. The difficulty with such a feature is that any error that occurs in the process could be very detrimental. For example, a password could be changed for a site but not properly recorded. If the site does not have an automated password reset procedure this could be quite time consuming to resolve.
That doesn't mean this isn't worth perusing, just that if and when we do we'll need to do a lot of testing with a large array of different websites to make sure situations like that are minimized.
It might be more reasonable to support this feature for a specific set of websites (say, perhaps, the top 1000 websites) which we regularly test against to make sure they haven't changed their process and that the feature still functions as expected.
Ben
0 -
It might be more reasonable to support this feature for a specific set of websites (say, perhaps, the top 1000 websites) which we regularly test against to make sure they haven't changed their process and that the feature still functions as expected.
Top 1000 seems completely unrealistic. I checked the help pages of one of your competitors and saw their list of supported sites for the automatic password change feature. They had less than 80 sites supported. Checking against my own sites I found only 10 that would be useful for me. To be honest I think the competitors are over-selling this feature.
0 -
The other thing that don't see mentioned here, which is a much bigger issue I'd say, is that we don't want people sending their passwords to us (or through us) — and frankly as a user I and many others don't want this either, but it would be necessary unless there were a common standard that websites used for password changes which would allow them to be negotiated with zero knowledge (not sure if that's even technically possible given the constraints). Even with good intentions and doing our best not to collect data, mistakes could be made by us or an attacker could utilize a flaw some part of this multi-party process to compromise our customers. It's something we've explored in the past and we'll continue to do so as technology moves forward. Heck, if you'd told me 5 years ago we'd be hosting users' data today — even in encrypted form — I would thought you were nuts. So it's possible that this may be feasible in the future, but we're not going to do it if the integrity of users' security and privacy cannot be maintained. And, as a user myself first and foremost, that's why I chose 1Password in the first place.
0 -
The other thing that don't see mentioned here, which is a much bigger issue I'd say, is that we don't want people sending their passwords to us (or through us)
Of course, we expect the client (iOs, Mac, Win, etc.) to be able to talk to the site directly to change the password, and not go through agilebits or 1password.com in any way. :-)
0 -
Oh, absolutely that's what we want, but the reality is it isn't currently possible to "broker" (for lack of a better term) a password change without the actual password and URL being sent. We could say we don't view/log it, and mean it, but that still puts us in a position where we could do that, or someone malicious could use us to.
0 -
Hi @brenty
I wasn't thinking that agilebits or 1password.com would broker any of these changes at all...the local clients (on macOS, iOS, etc) would talk directly to the websites to change the password...i.e. client logs in to accounts.google.com, invokes change pw link, etc. Of course this is why it would be limited to top sites only as you would need to build this functionality directly into the clients.
0 -
@steven1: That's a fair point. But in order for that to work, we'd have to release even more updates for the apps (and there's a lot more development/testing/deployment overhead with that than with a server-based approach, to say nothing of the burden on users), which would be necessary for this feature to work, with new "recipes" as individual sites changed — and even covering 1000 sites that's going to be very, very frequently. It's a logistical problem, and one which others have solved by handling this process themselves. Either approach has significant downsides for users, and at this point the tradeoffs are far too large with either for us to do something like this.
0 -
I am wondering how your competitors managed to do this and most importantly: at what cost? What are the risks that comes with their approach?
0 -
@Catalin1P: I'm not going to point any fingers or badmouth anyone, because certainly some people may feel that there's an acceptable tradeoff of privacy/security for the added convenience of an automatic password change feature. I just don't agree with those people. And as I alluded to earlier, the competition that I am aware of who are offering this feature do so by serving as a middleman between the user and the website. Even if they are not storing them permanently, login credentials are sent through them and they could therefore be used to get to users if they were compromised. Regardless of their efforts to minimize risk, we don't see this as being an acceptable risk for 1Password users, including ourselves; so, as with things like Watchtower and Rich Icons (which arguably pose a much lower privacy/security risk to users, since they don't involve actual login credentials), our strategy is to never have this kind of sensitive information in the first place.
0 -
Thank you for answering my question @brenty! I had a feeling that there was some kind of tradeoff but I didn't know that it involved a middleman between the user and the website At least I know that with great features comes great responsibility and possible some tradeoff of privacy/security. I prefer 200% security over fancy features. I don't mind changing my password manually even though my vault is quite big.
0 -
Well, I think we can do both in many cases. But we haven't yet found a way to solve the logistics, security, and privacy issues with automated password changes. Perhaps we'll be able to in the future, but for now we're focused on login filling, since that's by far what gets the most use by 1Password users. I hate changing passwords too though, as often it's difficult to even find where to do this on websites. I hope we'll be able to do something in the area in the future, but for now I'm glad that I generally don't have to change passwords, since I'm already using unique, randomly-generated ones for each site. Cheers! :)
0 -
I don't believe that LastPass sends credentials to LastPass servers for their auto-password-change feature. LastPass actually takes control of your browser and changes the password for you locally. Dashlane does seem to send credentials through Dashlane servers, which I agree is not an acceptable tradeoff of security for convenience.
I don't know how LastPass deals with the logistics and mitigates the risk of incorrectly saving changed credentials, but if I had to implement the same feature myself, I would do it like this:
- Each client has versioned "recipes" for password changes on a selection of common websites. Recipes define how 1Password should control the user's browser to change passwords. Exclude websites without a straightforward way to reset forgotten passwords.
- Maintain a CI server that runs through all of these recipes repeatedly with test accounts so that you know as soon as any of them stop working. Offer an API that reports which recipe versions are still valid.
- Clients check the API to determine if a particular recipe is valid before attempting to change a password using the recipe.
- Let the user know that they need to update the client (or update the client automatically, depending on the platform) if the user selects a recipe that is no longer valid.
- Post MVP: Use Chrome's new headless functionality on supported platforms to avoid popping up a bunch of browser windows/tabs.
I'm not suggesting that this would be easy to implement and maintain, or that it should be a priority for 1Password. However, it would be helpful for my use cases.
0 -
Yeah, I wasn't able to find enough information on their implementation to be definitive. The list of supported sites though is very short. I don't mean that in a defamatory way; it's simply a big problem to do this at all at scale since there is no standard, especially since a mistake or website change could cause people to get locked out of their accounts just be using the feature. That's not the only reason we never released something similar but it was a big one. We can simply help many more people by improving login filling than password changes, as this is something probably all 1Password users do multiple times per day. I couldn't tell you the last time I had to change a password, and I doubt it was for a site which is in anyone's top 100 or even 1000. I like the ideas you mention, and that's similar to our thinking in this area. I think it would be great if we can do something like that in the future. Thanks so much for the feedback! :)
0 -
My opinion is that this would be an awesome feature. I have over a thousand passwords in 1Password, so updating them every year would involve manually updating four passwords a day - I'm not going to do that. I have passwords in there to sites I use regularly which I have not changed in ten years.
I appreciate your concern that sites update their password reset process and it breaks your integration, and also that you'll be eternally locked into a game of catch-up. I have two ideas:
1) While I have a lot of passwords, there's a limited number that I really care about. A couple dozen sites should cover it. Of course my critical sites will differ somewhat from everyone else's, but I think getting 80% of the way will not require support for two many sites.
2) Why not create and support an open standard password reset process. Just publish it to the internet... Then you'll get all sorts of random sites supporting your password resets and over time I can see this list growing. Of course you'll get die-hards that never support your process, but the approach feels fundamentally better than being locked into an eternal game of catch-up.
0 -
Maybe take another approach. Instead of user centric (top lists) approach it by systems used on the web. For instance 29% of all websites are WordPress. By supporting just one system you support 29% of all websites. Figure out the rest and I'm sure you'll be able to support 80% of all websites with minimal effort (Pareto principle).
0 -
Which version of Wordpress?
;)
Your point is taken, and well received, but I hope you see my counter point that it is easier said than done, and that “minimal effort” simply doesn’t exist when implementing any sort of feature in a widely used product like 1Password.
Ben
0 -
Clearly, for the level of security you intend to provide, this would have to happen on the client. So it sounds like a set of API calls from the client (unique per supported site.) But having a set of integration tests running on your side (on a regular basis) with a single test account at each site you support would cover any changes to the workflow that you can't foresee. Clearly, this is time and money to build. But would give you the best approach to keep all users running cleanly. I don't know what your concurrent device count is, but I doubt password changes would happen at a large percentage of time per each user. Admittedly, there is a chance that something could go wrong for the user (albeit, a low percentage of scenarios.)
I'm not currently a 1password user. I've heard good things, but this is the one feature that I'm not sure I can purchase your subscription. I have passwords from a large number of sites that are not setup well. I'd like to change most/all to unique passwords. However, the hours of work that will incur on my daily workflow isn't one that I might be able to accomplish.
So I feel that I might have to go to a competitor just to be able to satisfy this need. Perhaps I'll come back to 1password as a user, but if the other company works well for me...
0 -
Thanks for you feedback on this. I think you summed it up pretty well. Our biggest concerns with doing something like this are privacy and user experience: both would need to be maintained, and when you're changing people's passwords for them, there really isn't any room for error. It's one thing if I do something dumb and get myself locked out of an important site. 1Password isn't perfect, but the stakes are much lower for what it does currently: filling issues mean some inconvenience, not catastrophe. Each time 1Password does something delicate like this for the user, it's an opportunity to either slowly build trust or immediately destroy it, so anything we do in this area needs to be undertaken with great care.
0 -
I just read through the comments because it's also something I was hoping for for years and just searched for it again.
While some of the points are well taken I think there is a room for some middle ground. Of course this feature might not be needed that often - but my Watchtower list of passwords keeps growing because it is so terrible cumbersome to change all the passwords. Having some help form 1password would make the world a more secure place for sure.
I guess a first start would be to maintain the list of URLs where to go for a password change. I guess with the proper security measures in place this list could even be crowdsourced (and kept up-to-date) by all those 1password users out there. I am sure that could be a way to at least cover the 80% of the sites.
Or maybe get in touch with the right person at Google. I am sure they might appreciate an open standard password reset process initiative. And they might even have the data to create this with little effort. So a big +1 for that initiative from me as well. I think it would make the web a better place.
The update process does not have to be fully automated (which indeed can be very fragile and lead to lock-outs) but just some guidance to easy the burden would be super awesome. Just being able to have a link in 1password that directly opens the "change password" URL would be super helpful.
And the zero knowledge argument I don't fully get. 1password by definition has full access to all passwords - at least on the client.
0 -
Hi @tcurdt
Thanks for the feedback! We certainly aren’t saying “no” here, we’re just saying that implementing such a feature does require a fair bit of forethought and we want to make sure if we’re going to do it that we do it right.
As far as zero knowledge goes — 1Password on your device does of course have access to your data, once you’ve entered your Master Password, however AgileBits does not have access to any of that data and we want to keep it that way. The less we know about customers, unless we absolutely need to know it, the better. :)
Ben
0 -
@Ben sure - totally understand. I wouldn't want it any other way. Some forethought is a good thing.
And for the zero knowledge: that confirms what I thought the status quo is.
But I don't see any technical reason this has to change to implement this particular feature - even with the full the solution.Just starting with some intermediate solution would be great.
Because while the Watchtower is a nice feature, without people actually fixing the passwords from that list it becomes a useless feature. Not sure if you have any customer usage data on that.Anyway - I hope this feedback will trigger some internal discussions. Thanks!
0 -
Not sure if you have any customer usage data on that.
We don’t, because:
The less we know about customers, unless we absolutely need to know it, the better.
;)
Your feedback is well taken though and I’m sure conversations on this subject will continue.
Ben
0
