[Feature Request] - site specific password generator recipe
First, I love 1Password.
Second, if I wasn't clear; 1Password is awesome!!!
Now... When I periodically go thru and update passwords, I often get stuck when my default password recipe contradicts the requirements/limitations of a particular site's password requirements.
I propose, as an advanced feature, since less than savvy users might be confused is:
Allow defining a site specific recipe so generated passwords will work without modification.
Example.. my password recipe
xyz.com allows me to use any password with a minimum of 8 characters; great, my default password recipe will work fine.
however, efg.com says I have to limit the password to 16 characters and use only symbols in the set of "*%#,.;()" excluding the double quotes.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @mlfinusa
Thanks for the kind words! So glad to hear you're getting good value from 1Password. As for your suggestion... That is a situation we'd like to do better with. One of the difficulties we find is that sites can (and do) change their password requirements without any notice. You may end up in a situation where they have changed and now the saved recipe doesn't meet the requirements (putting you back where you are now), or worse, if they start allowing more secure passwords (longer, more special characters, etc) you may continue generating less secure passwords for that site because that is what is saved in the recipe. I don't think those are necessarily insurmountable challenges but they are the kinds of things we have to consider when thinking of building something like this.
In short: it is a problem we'd love to solve, but I don't think there is any consensus yet as to the best way to solve it. It is something we're looking at. :)
Thanks!
Ben
0 -
Hello @mlfinusa. Thank you.
There are even more complications and difficulties with this than what Ben pointed out
- Sites' stated password requirements are often vague
- Sites' stated requirements on a page don't actually match their actual requirements
- Sites may have different requirements on different pages (such as a registration page and a password change page)
- Sites change these without notice (as Ben pointed out)
There is some collaborative work aiming to get better data on what sites actually require so that we can move in the direction. Previous attempts to do this have failed, but maybe we will have better luck the next time around.
0 -
I have a feature request that is of a similar nature to this previous request, but broader in scope - in that it is not site-specific.
I love the memorable password option of the password generator. Even though I almost always have passwords entered automatically, sometimes I have to enter them by hand - and that usually on my phone. Typing in recognizable words is easier than a string of random characters.
The issue comes when sites require a combination of capital letters, numbers, special characters.
I would like additional options when using the memorable words generator.
Specifically:
Total # of characters limit
Include one capitalization (am happy for 1P to choose which word)
Option to include 1 number (either as an addition or as one of the separators)
Add $ sign to list of separator options - In my experience this is a common one accepted by sites; valid options often do not include the options provided by 1P.
Thanks for your consideration0 -
@Dan234: Thanks for chiming in. While we do not have plans to try to limit number of characters for word-based passwords*, we're experimenting with options to add some capitalization and/or numbers to those. I can't say that I've had the experience that
$
is a good option since many sites I encounter just in testing things to help 1Password users specifically disallow it. It's something we can consider though.*The reason that word-based passwords can be secure is because of randomness and overall entropy. Having 1Password try to choose only combinations of words that fit within a certain length causes problems with that, in requiring it to throw out perfectly good passwords which were chosen completely at random to meet some arbitrary requirement -- the opposite of random. There are two things I'd suggest instead:
- Use word-based passwords only where necessary -- for example, in cases where you regularly will need to remember/type them. Character-based passwords will always be stronger than a word-based password of the same length, so you get more bang for your entropic buck there, since each position can be one of a large number of characters.
- Truncate a random word-based password that's too long and use that. It's still random and easy to type -- in fact, easier than if you had to type the whole thing, since you're cutting it off prematurely. ;)
0 -
Hi all,
New user to 1Password and have been loving it for the last few months. Thought I'd start throwing in some feature requests, and did a quick search to see if what I'm thinking of had already been put forward, which has led me here...
@mlfinusa - great idea, but I think you've made your requirement a bit too wordy.
@Ben - this doesn't have to be as complicated as you seem to be making out, either.
I appreciate that I don't know what 1Password is doing under the covers, but my suggestion would be that there be a mechanism (checkbox or similar) to enable saving of the setup of the password generator per login item, with the config retained alongside the rest of the metadata for that item. This would provide the functionality that @mlfinusa and I are after with (conceivably) minimal changes.
You also may already be halfway there - it would seem that 1Password retains an echo of the password generator setup, as it remembers how it was last used. i.e. if I set a requirement of 17 characters with numbers but not symbols, it caries this configuration over to subsequent logins I create or edit until I change it again. If this is the case, it should be relatively straight forward to move this saved config from the page and into the database when the toggle I mentioned above is enabled, and then retrieved the next time the item is loaded for editing.
@Ben - I do hear what you're saying re the risk of a "set and forget" option for this, but I personally think your concern is unfounded. The 1Password user community is (hopefully) one of above average awareness of security, and would appreciate needing to check that a site's password requirements haven't changed from time to time. You could even build in a reminder to do this, similar to the existing "ID expiry" functionality.
@jpgoldberg - I also feel that you're taking the feature request too far. It would be awesome for password protected sites to offer some kind of RESTful service advertising it's password requirements (which would be great if it wasn't such a potential security vulnerability), which applications such as 1Password could leverage. Short of that, I can't see how what you're pointing out would be possible without maintaining some kind of register of password requirements by URL. I suggest that this would be administratively heavy, and almost always out-of-date, and scraping the password requirements at run-time problematic.
I'd be happy to help assist in testing this feature in the wild if you give it a go and have a UAT branch available for public testing :)
0 -
@chamaelion: Maybe "complicated" is the wrong word. But certainly if you're talking about collating and maintaining a database of password requirements for websites -- which are legion -- it's going to be a lot of work no matter how it's done, given there's no API or anything where we can query them in an automated fashion. The 1Password "community" in the sense of those who seek out forum discussions like this is certainly very savvy, but you're kidding yourself if you think that everyone who uses 1Password is represented here. Everyone needs security, not just us nerds. So I think it would be better for us to come up with a solution that scales, not spend a lot of time developing, testing, and supporting a feature that benefits only a relatively small number of users who are into this stuff, rather than just wanting to secure their digital lives without having to essentially build their own personal database of website password requirements -- especially when in most cases a strong password never needs to be changed again. What's "unfounded" in your view does still impact millions of other users, so we have to consider it. It's a problem we'd like to solve, but for all 1Password users, not just for the few passionate folks we have here. :)
0 -
@brenty - Fair call - I may have spat out my comment when I wasn't in the right mindset :) You're absolutely right, if it's a feature that won't benefit the bulk of 1Password users (which you folks would be in a far better position to gauge than I), then it's certainly not worth the effort pursuing.
Thanks for taking the time to reply, I'll get back in my corner now :blush:
0 -
@chamaelion: Nah, I didn't mean it that way. I'm sorry if I gave you the wrong impression. It was good of you to share your thoughts on this! I just don't want to give you or anyone else false hope. It's something that could have especially bad consequences for security and privacy if done wrong. So we'll continue to exercise caution in this area, and, for now, focus on the areas where we know we can do more good. Hopefully we'll be able to find a good solution down the road though. Thank you for your encouragement! :)
0