No longer possible to specify amount of numbers and symbols in random password since 7.7 update
Can somebody from AgileBits explain why this regression in functionality was deemed necessary or even desirable? I need to regularly make a new password that has particular requirements for the number of numbers and symbols it needs to contain, and since the new 7.7 update I can now no longer rely on 1PW to do this easily. Seriously, what was the point of excising that possibility? :|
1Password Version: 7.7
Extension Version: Not Provided
OS Version: 10.15.7
Sync Type: iCloud
Comments
-
@Timolution - yep, happy to! In fact, let me refer you to a past thread where our Chief Defender Against the Dark Arts (AKA: security team lead), Jeffrey Goldberg, did exactly that. Let us know if you have any questions.
0 -
Well, thanks for the link and given that that discussion is closed, I'll just answer here.
That Agilebits want to have a solution that is simple and eliminates potential non-randomness pitfalls for Joe average is understandable, but the fact that by doing so you a) have now supplanted that lack of functionality to both the mini and the main app, and b) that you flat-out refuse give advanced users a possibility to have more fine-grained control over how passwords are generated, despite users in that thread explaining why they still would like to be able to do so, strikes me as almost fundamentally disrespectful to a certain segment of your customers.
I saw you and some of your colleagues commenting to some of the posters in that thread that you want to understand why this control is wanted, so I'll give you my reason below, but first allow me to latch on to a part of your response in the thread:
Our user base is now large enough at this point that nearly any change we make will result in delighting some users and enraging (or at least disappointing) others. Since there will be users themselves whose wishes are in 180° opposition to the wishes of other users, it has become literally impossible to make changes to 1Password just because someone articulates their reasoning/use-case
That argument imo would be somewhat valid if you were asked to change or remove existing functionality, but in this case you (as in Agilebits) decided to remove functionality, while users there (and here) were merely asking to provide a way to reinstate the existing functionality. So I don't see how giving the option to re-exposing what was already there before would annoy your customers more than what you did: a complete excision.
Coming back to the 'why'-question your colleagues and you kept swinging about in said thread, first allow me to remark that I find it bizarre that paying (possibly long-time) customers would need to provide justification in regards to wanting to keep existing functionality, as opposed to requesting for example a new one. And I personally find the attitude of some of your colleagues in that thread rather haughty, especially in the way that they demanded users bend over to justify themselves. And again, I could fully understand said demands if those users would be asking for complex new functionality, or if there was a huge security issue with the existing way of things, but the request was merely a preservation of an existing option that as far as I know doesn't really have inherent security problems if used correctly.
As for my 'why'; my company's internal network requires monthly changing of multiple passwords with strict requirements regarding the exact amount of letters, numbers and symbols in each password (don't ask me why the ICT guys want it like that, but it is what it is) and this used to be quite easy and done in no time with 1PW, emphasis on 'used'. But thanks to the removal of recipe options in the newest software version I can now go have fun every month with generating multiple passwords, editing each one manually so it fulfills the requirements (thereby ironically enough completely nullifying the so-called randomization protection this regression claims to strengthen) and then copy them back to the PW update forms.
Is this a major life-burdening problem? No. But it does make my professional life ever so more annoying and that leaves me with a bit of a bad taste in my mouth, especially given the way you all (as in Agilebits) reacted so dismissively in the linked thread to users asking to merely preserve what was already there and functional (even if it meant you would put it behind a hard-to-find option in the preferences).
0 -
Hello!
Could you tell me if it is possible to add one more type for the password - "custom" where can I regulate the number of characters and numbers as before?
0 -
I read the post from @Lars with @jpgoldberg 's response. It was very informative, and I agree with the overall premise and the drive behind 1Password. The honest truth is that I'm an IT Geek and my family is not. I want them to be able to easily and securely create and use good passwords. The removal of the controls from 1Password mini made sense to me, as that is how most people likely use the tool and most of the time those features were not needed by them, but I never thought the functionality as implemented would be removed entirely!
The main thrust of the other thread appears to be "Why?", which as an IT Geek I also understand. Even if something already exists, it costs time and effort to maintain. Technical Debt is a real thing and we want to focus our time and resources on what is actively needed and used.
So the main answer to that question is because there are still a lot of websites out there that require bad password policies. We all know the drill - no repeating characters, a single symbol from an accepted list, no repeating letters, etc. With no number or symbol controls we are left strictly with manual remediation of those passwords. This is definitely a lesser user experience - the app has no way to generate a compliant password now. It may also be worse on the security side too, since manual remediation is likely not the same as randomly generated.
As the family IT Guy and 1Password account manager, I'm the one that gets the phone call with the person on the other end saying "I'm trying to make a password for this site and the 1Password generated one isn't accepted. I've tried to generate it a few times...". Previously I would walk them through the process of going into the main app and exposing the sliders to generate a password. Other times, depending on the frustration level of the person on the other end, you're stuck simply generating an alpha password and then manually tailoring. It's likely a less secure outcome, but sometimes your options are limited.
Normally when I encounter this I go into the main app, set the sliders as close to the password recipe as I can get, and regenerate until one meets the criteria. Sometimes this can take a few rounds, especially with the more narrow restrictions like a limited number of accepted symbols or no back-to-back repeating characters. From a time perspective the regenerating cycles were likely equivalent to entering an exact recipe, but the process is a lot simpler, so I was always OK with that trade off.
Another "why" is that, per the post, shorter passwords (< 12 characters) can benefit from symbols and numbers. Sometimes I'm looking to generate a short password for something due to the repeated pain of entering it. An example would be a streaming password where the only password entry device is a remote control arrow pad. In these cases where length matters the cheap bit gain from a symbol and a number might be worth it.
The last "why" is that, like @timoolution, there are also times that the professional in me needs to generate passwords that meet specific criteria. They come from all over the place - audit requirements, contractual requirements, "the other system can't accept" requirements, etc. But I also understand that this is IT Geekery and not the mainstream use of the product. I've always expected that my password manager could meet my professional password generation needs, but I've never expected it to put my professional needs front and center against other more common uses.
It makes sense that for 1Password to achieve it's future vision of passwords, like no symbols/numbers and form over function, that it would place them front and center for the users they benefit the most. My whole family pretty much uses 1Password mini and the "Random Password" option, setting the length, and checking the symbol and numbers boxes as necessary. It makes sense to focus on that audience and leverage that area as the driver of change/innovations. As an IT Geek I don't mind a little extra effort and putting the many first, I just want a place I can retreat to get the work done when I need to.
To that end, I really like @dguskov 's suggestion of a "Custom" type being added that reveals the previous controls. Perhaps the "Custom" option is only displayed when inside the 1Password main app, like before. This gives us a place of refuge when we have a website that isn't working with the "Random Password" generator, or we have custom password requirements, but for everyone else they get a more streamlined, generally applicable, and forward looking experience.
Also, one question for @jpgoldberg if I may:
You say in the post that you wouldn't use numbers and symbols at all, but they persist as an option because sites require it. Why not just randomly place a single symbol and/or number in the password to meet the requirement, as opposed to the current behavior where it generates multiple of each?
0 -
In this new version, how do I control the quantity of numbers and quantity of symbols in the password, as I used to be able to do?
1Password Version: 7.7
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:quantity of symbols and numbers in password0 -
Removing this fine-grain control of password generation was a mistake. Please put in back. If it is somehow confusing or unnecessary for many use then, fine, "hide" it under an expansion error, a "custom recipe" choice, an overall preference, or whatever. But do not remove it as some of us actually do rely on that to meet password requirements for some systems we use!!!
0 -
Eek, my apologies for the mess. I tried to make edits to fix errors in the post and then they disappeared from the forums so I attempted to re-write them. When I went to bed only one was left, but it appears they all have returned now. It doesn't look like I can delete, so if a mod wants to spring clean by all means do so.
I can definitely reproduce the bug if there is a bug tracker for these forums somewhere :-).
0 -
Welcome to the forum, @aligas! Thanks for taking the time to state your case so thoroughly and positively; it's much appreciated. I've removed the multiple nearly-identical copies, for clarity.
I definitely do understand the needs that some people have to generate multiple passwords with very specific requirements at once. We're aware that exists in our user-base for some people who are perhaps sysadmins or even just family assistants for all things digital. If you've got unusual requirements like Timolution mentioned, where you're having to change multiple passwords on a monthly basis, then the additional work of having to manually adjust what 1Password generates is magnified from something relatively trivial to something more burdensome.
We can certainly explore the idea of adding a "custom" feature like the one mentioned by dguskov; it would be a time-saver for those of us confronting such requirements. There are two main issues with it, from our perspective:
- Bad website password requirements. We all know these, and (surprisingly) they are often financial institutions who ask for a password between 8 and 12 characters, or the like. As what constitutes good password practices changes and also becomes better-understood by not only the general public but also by the people who create website forms requiring passwords, these will become fewer and fewer (and already are, to some degree).
- Leaving generator settings in a bad state. This has always been a pitfall, and I don't know that we'll ever be able to rid ourselves of it completely, but we're doing what we can to reduce its likelihood. You may have experienced it yourself: you come across a site that has very unusually weak password requirements (or maybe you're just trying to generate a random 4 or 6-digit PIN code). So you set the generator settings for that, generate your password/PIN...and then you leave the app, with the settings set that way. What can happen is: if you don't check your settings again the next time you go to generate a password (maybe you're in the browser extension, and in a hurry), you simply generate and go -- and you've just generated a very weak password for a site. Or at least one that's not nearly as strong as it could or should have been. Maybe you've now generated a dozen or more this way until you realize it one day, but now you have to go back to multiple sites and change your password -- if you remember which ones you did this for.
We've taken multiple steps already to help minimize the chance of the latter possibility. A while back, we created a separate option for PIN codes, so that no one would need to reduce the settings on the password generator to unacceptably low levels just to generate that one PIN code. And that's also one of the reasons we removed the adjustable sliders on the generator as well: not just because human-created passwords are less random than passwords generated by a competent CSPRNG, but also because if you've set the sliders to accommodate some website's unusual/poor password requirement and then forgotten to change it, you can wind up with multiple weak passwords. Creating a "custom" category with full adjustability, while it might be helpful for the unusual 1Password user who's tasked with changing multiple passwords a month with very exacting requirements, would also allow for not only the scenario I described above, but for less-technical users to discover that setting and use it for everything, thus eliminating the gains from the new generator and its randomness.
My colleague jpgoldberg touched on the idea of a "standalone" password generator, which is something we may still pursue at some point because every time we make a change to the existing generator, we hear from a small but vocal contingent of users who had managed to set up the old one exactly the way they like it and now have their workflow impacted or broken by the changes. I can certainly add everyone's wishes to that idea, if it would be helpful for you.
Less likely are changes to the main 1Password apps which expose greater configurability to millions of users who, as you say, mostly just want to generate strong passwords they don't have to remember and rarely need to tweak or configure those settings beyond length and a checkbox for digits or symbols. We'll keep evaluating to see whether there's a way to satisfy the wishes of this user group without running the risk of lowering password strength and security for other users as we move forward. Thanks for the conversation and the ideas.
0 -
@Lars Thank you for the equally thoughtful and insightful response!
I completely agree that #1 should hopefully be a diminishing problem, though until its really gone I think we still need to deal with it. It's a bit like stopping the manufacture of a drug before you eradicate the disease it treats. At a certain point you're keeping the drug around more than you are using it, but you still need to have some of it on hand until the disease is really gone.
I also agree with the issue of leaving the generator in a bad or weakened state. I believe this falls directly into the area where I'm happy to take on that extra effort to get my quirky stuff done in order to best accommodate the masses.
As an armchair designer, this strikes me as potentially a good approach to have our cake and eat it too:
1) The "Custom" option is only available in the 1Password main client, and not in mini. Most people I know primarily use Mini, and thus are unlikely to ever encounter the option, this protecting many (if not most) people from using it when they should not.
2) The "Custom" option resets to settings equivalent to the current best practice settings for "Random Password" at each access. Each time I select the "Custom" option, it starts with the best practice settings and I have to adjust it. Since it would now generate the same results as "Random Password" at each initial access it would prevent leaving the generator in a bad state.
Would it be more work for me to adjust the settings each time - sure - but I think that juice would be worth the squeeze to best protect everyone else. Even in the worst cases I can think of, I think this would work without an unbearable amount of pain because I can use one access of "Custom" to generate a bunch of passwords.
Everyone is a winner there, I think!
As for a standalone generator, the availability of a password generator where you can really dial in the settings would be something I would be interested in. Even if it was just a CLI implementation. Again, I get we're in esoteric territory. I'm not looking for it to always be the easiest, I'm just looking for it to be possible.
0 -
@aligas - I think those are some good ideas, and I'm happy to pass them along to the development teams. I can't guarantee any sort of timeline for adoption, or even that they will be adopted, but I certainly will add them to the mix of ideas we're constantly evaluating and prioritizing. Thanks again for the suggestions. :)
0 -
Hello!
I want to add one more thing to @aligas proposal.
Do not remember "Custom" type in the password generator. For example, if I generate password with type "Memorable" and then with "Custom" - the type option for the next password must be "Memorable", not "Custom".
0 -
I would just like to show my support for bringing back more customizable passwords. A number of government websites have very strict password requirements and frequent changes. I was hoping for even more customization of passwords (for example one website I use requires a symbol but only selected from a list of 5, so “~” is ok, but “-“ isn’t). The current direction is very disappointing and makes 1Password a much less appealing option.
0 -
Thanks for weighing in, @MBR. We've reduced the set of allowable symbols pretty far, to the ones that are most commonly accepted in the greatest number of sites. I don't know that we'll be making any changes to that in the immediate future, but it's something to keep in mind as we move forward.
0 -
Why not provide a choice between a normal (the default) and an advanced palette of symbols and rules available for use in constructing passwords? The (vast) majority of 1Passwords users would likely be satisfied with the restricted set, but those wanting and needing greater flexibility could still find it within 1Password.
0 -
@williakz - earlier in this thread, I linked to a previous post by our Security Team lead which goes into the reasoning. That should give you a pretty good idea.
0 -
Thanks for the response and link, @Lars. Unfortunately, I saw many differing, and even opposing, opinions expressed by both users and members of your Security and Technical Support Team Members. Based on my previous experiences in this area, I remain skeptical that a one-size-fits-all password generator "solution" (which 1Password appears to be pursuing) is more about serving users than slimming the codebase.
0 -
@williakz - you're quite welcome. The changes to 1Password's Strong Password Generator definitely weren't about "slimming the codebase." The new version is considerably more powerful than the old SPG - it's just (as jpgoldberg mentions) that "...we have exposed less of that power to the user."
0 -
While exposing MUCH less of its configurability. Are you claiming that as a net increase in "power"? Whose?
0 -
@williakz - it isn't the changes in the interface, it was the changes in the generator itself that increased the robustness of the entropy which jpgoldberg shorthand-ed as "power."
edited to add: feel free to have a look at the source code for the SPG for reference.
0
