Can 1Password Generator Support http://passphrases.peerio.com Algorithms?
The engineers at peerio surprised the security researchers at the bsides conference (including the dicewords folks) with their session and algorithm for strong memorable passwords. I have linked the materials below.
Could 1Password support this algorithm? If it did, I would need the option to add capitals, numbers and special characters so that some legacy password policies can be made happy ;)
Memorable, High Entropy Passwords
https://blog.peerio.com/how-to-build-a-billion-dollar-password-3d92568d9277
Memorable, High Entropy Passwords - much more detail on how they developed their approach
https://www.youtube.com/watch?v=vudZnjp5Uq0 starts at 5 hours 19 minutes
Generator that complies with the above.
http://passphrases.peerio.com/
1Password Version: 7.3.657
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: Not Provided
Referrer: forum-search:peerio
Comments
-
Hi @djsdjs
Thanks for the suggestion. I'll be happy to pass it along to our security team for their review. I believe our Chief Defender Against the Dark Arts, Jeff Goldberg, was at that conference, so he may already have a pretty good idea of what this is all about. That said I do know there is a resistance (with good reason) to adding a lot of options to the password generator. If we were going to be included it would likely need to replace one of the existing options... which maybe it can.
Thanks!
Ben
0 -
@djsdjs: The link you provided doesn't seem to work, but from what I could gather on my own it looks like what they have is very similar to our own "words" password generator option, which has higher entropy due to our larger Wordlist, and perhaps some preference for positioning in their case. Have you tried that? A 5-word Wordlist password offers more than 70 bits of entropy...but generally we recommend 4 since even that is overkill, at 56 bits. Even 3 has taken more than six months to guess with hints and a cash prize at stake. So 4 seems to be the "sweet spot" currently. It's really great to see so much effort in this space though, as I'm sure there will be even more innovation as time goes on. Thanks for bringing it up! :)
0 -
Here's a non-broken link to the Peerio blog post in question. Also a link to the YouTube video, starting at the beginning of the talk.
[Edit: Note that the blog post is from last May, and the video is from 2016.]
0 -
Could 1Password support this algorithm? If it did, I would need the option to add capitals, numbers and special characters so that some legacy password policies can be made happy
We already support the algorithm. Our word list algorithm does the same. But perhaps you were asking whether we could use their wordlist.
I loved this talk! Quite frankly they did a better job at constructing a wordlist than I did for our generator. The use of words from film captions was brilliant.
There are a couple of reasons that we haven't just switched over to their list. The passphrases that their list was created for serve a purpose similar to our Secret Key. They are only entered when setting up a new device. Also so they can have very long generated pass phrases. We are recommending our wordlist generator for creating your 1Password Master Password, which is something you will be typing multiple times a day. So we what we generated to be useful when not quite as long. This means a longer wordlist of shorter words, which is why we opted to allow unfamiliar words to stay on our list.
I would need the option to add capitals, numbers and special characters so that some legacy password policies can be made happy
Before I actually answer the question, I'd like to remind everyone that for passwords that you will never need to type, memorize, or transcribe, you are better off with the character based passwords. Use of wordlist-based systems is a compromise between human usability and strength. But if you don't need the password to be human usable, you don't have to compromise. A 15 character character based password, like `tTpn#K42iFiHR is already going to be stronger than their "billion dollar passwords". So if you don't need a human usable password (because 1Password will remember it and fill it for you), then go with the character based ones.
But if you really need a human usable password that meets various character requirements, you should take a look our new improved strong password generator which is being slowly rolled out to different clients. It is much more flexible about the separators that it can us, it can capitalize words. (And if you really want to see it in action, you take take a look at its source in all its glory at https://github.com/1Password/spg
0 -
For anyone who's interested in the details of the research they did, and doesn't need the general background, the meaty part of that talk starts here.
@jpgoldberg – I'm interested in
spg, but the only documentation I see is how to get it. Is there anything written on either how to run it or how it works, without needing to learn yet another programming language? Also, which client(s), if any have this generator built in?0 -
Sorry @gedankenexperimenter, at this point it is very much a go package. Note that the documentation for the package itself is best read at https://godoc.org/go.1password.io/spg. As with our SRP go package, this is something we built for internal use, but can be made use of by others who use go.
The first client to use this was 1Password X. 1Password for Android also has been using this for a while. I'm honestly not sure which others are.
My colleague, @rob, gave an outstanding talk about one feature of this SPG at the most recent PasswordsCon.
Although the go package is stable and robust enough that we were willing to publish it, the corresponding CLI,
opgen, is a neither. (But we published it anyway because we didn't want to hold up publishing the SPG and didn't want to create a separate repository for the CLI.)So the command-line interface in that go package is very much a "work in progress". You will need a go build environment to build it. Once you have a go build environment than
go get go.1password.io/spg go install go.1password/spg/cmd/opgen
should build and install everything.
opgenreally isn't ready yet, but tryopgen characters --helpandopgen wordlist --help.0 -
@jpgoldberg – Thank you for sharing that talk. It more or less confirmed my guess about how the older password generator works.
Regarding outdated character restrictions in passwords, however, I almost never have a problem with required character classes – by far the big issue is forbidden characters, artificially restricting the available set of possible passwords. For example, the CRA MyAccount website allows symbols, but only
.,-,_, and'. (Bizarrely, the use a different symbol whitelist for answers to security questions, with comma taking the place of the underscore). And of course, the websites that still adhere most strictly to these counterproductive rules also tend to limit the length of passwords the most (in the case of CRA, 16 characters). And they're usually the ones that contain the most valuable information (banks are the worst offenders I've had to deal with). It appears thatspgdoes have facilities for limiting these character sets and still providing a uniform distribution (the least obvious problem), but that functionality won't be accessible in any of the 1Password apps. Disappointing.The biggest thing that I miss from KeePass was the ability to satisfy all those stupid character restriction rules, and to have the password manager record the generator rules last used for each entry independently, so whenever I needed to change a password, all I needed to do (assuming I didn't want to change the rule) was click the button. With 1Password, I've found it necessary to be constantly adjusting things because it only stores one global setting. Fortunately, I have plans to build my own password generator…but I digress – lest I be accused of topic hijacking again, I'll rein myself in on this tangent.
I would recommend, if that talk is given again, using a Venn diagram for the 3-class case, to visually show how some sections get counted twice might be helpful to anyone in the audience who's not well-versed in formal set theory notation, by the way…
0 -
But if you really need a human usable password that meets various character requirements, you should take a look our new improved strong password generator which is being slowly rolled out to different clients. It is much more flexible about the separators that it can us, it can capitalize words. (And if you really want to see it in action, you take take a look at its source in all its glory at https://github.com/1Password/spg
@jpgoldberg: Also, usable on our website: https://1password.com/password-generator/ :sunglasses:
Here's a non-broken link to the Peerio blog post in question. Also a link to the YouTube video, starting at the beginning of the talk.
@gedankenexperimenter: Thank you for those links! :chuffed:
Regarding outdated character restrictions in passwords, however, I almost never have a problem with required character classes – by far the big issue is forbidden characters,
That's really interesting. I feel like it's pretty close between them in my experience, but I don't have statistics. I may be misremembering.
And of course, the websites that still adhere most strictly to these counterproductive rules also tend to limit the length of passwords the most (in the case of CRA, 16 characters). And they're usually the ones that contain the most valuable information (banks are the worst offenders I've had to deal with).
That's certainly been my experience. I'm pretty sure my bank was limited to 8 just a few years ago... It's understandable in that this is often legacy infrastructure, which they're slow to change since so much depends on it...but at the same time that just why we want better security. :(
It appears that spg does have facilities for limiting these character sets and still providing a uniform distribution (the least obvious problem), but that functionality won't be accessible in any of the 1Password apps. Disappointing.
Cheer up! Just because it isn't user-accessible today doesn't mean it won't be in the future. ;)
0 -
Cheer up! Just because it isn't user-accessible today doesn't mean it won't be in the future. ;)
I would have more reason to be hopeful of that if AgileBits didn't trumpet the Apple philosophy of "the designer knows best, and the UX should be as simple as possible", but "the users know what they want, and should have controls that let them configure the software to behave that way, with reasonable defaults".
One thing that could be done is to use special fields to set the password generator parameters for an entry, perhaps in a section named "Password Rules". Of course, that brings to mind the bank I used that only recently changed from 8-character digit-only passwords with security questions. There, I generated strong passwords as the answers to the security questions, hoping that those answers weren't stored in plain text. I store those as "password" fields in the entry, but I'd want different generator rules for them than for the main password.
The worst offenders are the ones that have a list of forbidden characters (or other bizarre rules), but don't publish it, or publish a list, but it's not the one they actually use (I've seen that more than once).
The big reason I find the restrictions on symbols so troublesome is best illustrated with the CRA MyAccount example. Only 4 of 32 symbols produced by most character-password generators are allowed, and ~1/3 of the resulting characters are symbols. That means my probability of getting a valid password from an entirely random generator is ≈0.003% on a 16-character password. If I use the old generator in 1Password 7, and optimize it (16 characters, 2 digits, 1 symbol), then roll a die or flip coins to replace the resulting symbol with one from the whitelist, I end up losing more than 3 bits of entropy: I get access to ~10% of the possible allowed passwords, which, though the resulting entropy is ~93.5 bits, is still pretty poor, when there's a pretty simple way to specify the rules, which would get me access to almost ten times as many outcomes.
As the password length limit decreases, it's both a bigger difference, and more important to use as much of the available space as possible. And that's exactly the area where most password generators simply give up and don't even try.
I love the idea of a crowd-sourced open database listing the dumb password restrictions of various websites, automatically used by password managers to generate valid passwords for those sites. The problem is that it might get hacked, of course, or simply fed bad data.
0 -
I would have more reason to be hopeful of that if AgileBits didn't trumpet the Apple philosophy of "the designer knows best, and the UX should be as simple as possible", but "the users know what they want, and should have controls that let them configure the software to behave that way, with reasonable defaults".
@gedankenexperimenter: I can't speak for Apple, but we neither have trumpets nor have we ever said that. :tongue: It's not fair play to just put things in quotes to pass them off as someone's words. ;) But we could do worse than getting compared to Apple I guess. :lol:
One thing that could be done is to use special fields to set the password generator parameters for an entry, perhaps in a section named "Password Rules". Of course, that brings to mind the bank I used that only recently changed from 8-character digit-only passwords with security questions. There, I generated strong passwords as the answers to the security questions, hoping that those answers weren't stored in plain text. I store those as "password" fields in the entry, but I'd want different generator rules for them than for the main password.
Yeah, yuck. But good call on the security questions. Every little bit helps! :)
The worst offenders are the ones that have a list of forbidden characters (or other bizarre rules), but don't publish it, or publish a list, but it's not the one they actually use (I've seen that more than once).
Amen! They always go on my "Enemies List". :naughty:
The big reason I find the restrictions on symbols so troublesome is best illustrated with the CRA MyAccount example. Only 4 of 32 symbols produced by most character-password generators are allowed, and ~1/3 of the resulting characters are symbols. That means my probability of getting a valid password from an entirely random generator is ≈0.003% on a 16-character password. If I use the old generator in 1Password 7, and optimize it (16 characters, 2 digits, 1 symbol), then roll a die or flip coins to replace the resulting symbol with one from the whitelist, I end up losing more than 3 bits of entropy: I get access to ~10% of the possible allowed passwords, which, though the resulting entropy is ~93.5 bits, is still pretty poor, when there's a pretty simple way to specify the rules, which would get me access to almost ten times as many outcomes.
That's a really interesting example. Thank you for sharing it! I'm not following you on the part where you say 93 bits is poor though. Unless we're talking about different things, you're way past the point of diminishing returns, when we're dealing with the difference between being able to brute force the password only in a time frame far outside a human time scale.
As the password length limit decreases, it's both a bigger difference, and more important to use as much of the available space as possible. And that's exactly the area where most password generators simply give up and don't even try. I love the idea of a crowd-sourced open database listing the dumb password restrictions of various websites, automatically used by password managers to generate valid passwords for those sites. The problem is that it might get hacked, of course, or simply fed bad data.
Good points all around. it's certainly a complex issue, and one that spans security, design, and, ultimately, usability. The good news is that websites are generally not getting worse about this, are improving overall (albeit slowly in most cases), and we'll continue to work at it from the other end too, to see what we can do to bridge the gap. Cheers! :)
0 -
I can't speak for Apple, but we neither have trumpets nor have we ever said that. :tongue: It's not fair play to just put things in quotes to pass them off as someone's words. ;) But we could do worse than getting compared to Apple I guess. :lol:
I thought it was clear that I was paraphrasing. Here's an example of one direct quote from @Ben on this forum:
We're trying to balance recommendations like that against adding complexity to the product. We're very resistant to adding additional preferences. Not only do they make the codebase more difficult to manage and less agile but they also have a tendency to confuse people and make the options they are looking for more difficult to find. If less than, say, 20% of people would utilize a preference, we try to make the most widely accepted option the default and not offer a preference. I'd argue we currently have too many preferences, not that we don't have enough.
There are plenty of other such comments defending this position. I've done a lot of software development in the past 25 years, and while I won't say that the argument is entirely without merit, I find it to be frequently exaggerated on this forum by AgileBits representatives while telling users that they almost certainly won't get options that they have asked for.
This is very similar to the design philosophy that Apple seems to employ, and though you may take that comparison as a compliment, to me it is not.
That's a really interesting example. Thank you for sharing it! I'm not following you on the part where you say 93 bits is poor though.
I sure worded that poorly! As I read it, I thought to myself that I must have made a typo, then realized that it was the word I intended. What I meant was that, while I still end up with 93 bits of entropy, I'm only able to get access to 10% of the allowed passwords this way, and I think that's poor.
For this reason, I don't want my current 1Password app on Android to change the behaviour of its generator. Right now, I can switch on both digits and symbols and get access to all 94^N possibilities on most websites, because it doesn't reject passwords for lacking character classes. And I can always do that myself, and it takes an insignificant amount of time.
What I would like to change is the ability to restrict the elements of those character classes (symbols, mainly). Right now, I have only a 0.03% chance of getting a valid password in the CRA example because of this, and that would get even worse if turning on symbols rejects all passwords with no symbols. That would take me a ridiculously large number of attempts unless I got very, very lucky. If I could whitelist the few allowed symbols, it would only take one.
In the required classes case, my chances of getting an acceptable password are much better (without the generator doing the filtering for me). With an 8-character password, I still have a 56% chance of getting a valid password in the first attempt, and 99% by the fifth.
0 -
There are plenty of other such comments defending this position. I've done a lot of software development in the past 25 years, and while I won't say that the argument is entirely without merit, I find it to be frequently exaggerated on this forum by AgileBits representatives while telling users that they almost certainly won't get options that they have asked for. This is very similar to the design philosophy that Apple seems to employ, and though you may take that comparison as a compliment, to me it is not.
@gedankenexperimenter: I think you may just be reading into it. Or perhaps you have a very different environment to develop in. Either you have much fewer users with much fewer competing requests, you don't hear from them much, or greater development resources. It isn't an exaggeration at all to say that everything we put time and effort into doing means not doing many more other things. That's not even a development thing; that's life. There are tons of hobbies I have an interest in, but I need to balance my time and can only really devote myself to a few alongside work, food, and sleeping. Food for thought. :)
What I would like to change is the ability to restrict the elements of those character classes (symbols, mainly). Right now, I have only a 0.03% chance of getting a valid password in the CRA example because of this, and that would get even worse if turning on symbols rejects all passwords with no symbols. That would take me a ridiculously large number of attempts unless I got very, very lucky. If I could whitelist the few allowed symbols, it would only take one.
In the required classes case, my chances of getting an acceptable password are much better (without the generator doing the filtering for me). With an 8-character password, I still have a 56% chance of getting a valid password in the first attempt, and 99% by the fifth.I appreciate the clarification! I do think we need to design primarily for more typical use cases, but we do have some ideas that could help with situations like this. A lot of the groundwork is being laid with the new strong password generator, and as we figure out good ways of offering more flexibility without making a mess for the 90%+ use cases we will expand on it. :)
0 -
I think you may just be reading into it. Or perhaps you have a very different environment to develop in. Either you have much fewer users with much fewer competing requests, you don't hear from them much, or greater development resources.
I'm not reading into it; I'm reacting to the arguments I have seen presented on this forum. This is the first time I've seen someone from AgileBits use the limited-resources argument. That is a perfectly valid reason for declining to implement requested features (depending on the details, of course), and it's much more palatable than the argument that I've seen repeatedly, in which it is claimed that the UI would become "covered in checkboxes" if all those feature requests were granted. A few times, a strawman screenshot of an old Microsoft Word window with all the toolbars simultaneously active[1] gets trotted out to demonstrate the horrors of adding preferences to an app, despite the fact that the UI being attacked does not display any preferences — those are generally hidden during use, as we all well know.
I would like to suggest to the AgileBits staff on this forum that they emphasize the fact that development resources are limited, and present that as the primary reason that feature request have been or likely will be denied. For those of us who feel that apps are better when the designers give us more options to fit their apps to our use cases, that is a much more palatable reason than the one that I've been hearing which comes off like, "Your grandfather might get confused by checkboxes that are hidden away on a More Settings page that he probably doesn't even know exists, and we're valiantly defending him against 1Password therefore becoming an office suite."[2]
[1. I am aware that the Word screenshot has been used as a joke, and it was amusing. But it comes across as crass, as though you're laughing about your customer's disappointment.]
[2. That last "quote" is not taken from anyone on this forum, nor do I think anyone at AgileBits would say such a thing. I'm describing the impression that is left on me (exaggerated for effect) by the comments that I have read here, not what I believe the writers of those comments intended to convey.]
0 -
We pretty regularly emphasize that we can only do so much, and need to focus on the things that offer the most benefit for the greatest number of users. I'm a bit shocked if you haven't read even me specifically writing nearly those same words repeatedly. It's confusing to me that you'd bring up "a few times" completely out of context since no one here even mentions checkboxes or references them in screenshots. I'm not sure it's fair to complain about us using a little bit of hyperbole to illustrate a point if you're going to exaggerate yourself. ;)
Anyway, junking up the UI would be not great for most users, and could easily lead to more serious issues, like more bugs due to exponential interactions between that and everything else. Anything we add not only requires some amount of effort, but also increases complexity, both for testing and for usability, so we try to add that sort of thing only when the benefits outweigh the aggregate costs. Anyway, none of this is meant to be palatable to you necessarily (especially if we're addressing someone else entirely), only honest. :)
0 -
[1. I am aware that the Word screenshot has been used as a joke, and it was amusing. But it comes across as crass, as though you're laughing about your customer's disappointment.]
While no offense is intended any time someone is looking to be offended they can find reason to be. The point is that adding a lot of (arguably unnecessary) preferences does cause confusion for customers. We see it all the time even with the comparatively limited preferences we offer. Not only does it add confusion for customers, it also adds complexities to the codebase. In some cases this can make future changes to existing features or implementation of new features that much more difficult / time consuming. So, yes, those are some of the reasons we're hesitant to add the huge amount of preferences that are requested. As brenty mentioned there are a number of others as well.
Ben
0 -
It's confusing to me that you'd bring up "a few times" completely out of context since no one here even mentions checkboxes or references them in screenshots.
This is not the only example, but I believe it is sufficient to falsify your claim. Here's another one, for good measure. Neither @Ben nor @Lars makes any reference to development resources in those discussions. I, too, have limited time, so I won't continue trying to convince you that it would be better to emphasize that rather than the debatable merits of the restrictions you choose to place on the apps when communicating with users who clearly think you're making the wrong call. To the extent that you have already been doing so, I'm glad to hear it.
I do think we need to design primarily for more typical use cases, but we do have some ideas that could help with situations like this. A lot of the groundwork is being laid with the new strong password generator, and as we figure out good ways of offering more flexibility without making a mess for the 90%+ use cases we will expand on it. :)
I'm also interested in the most common use cases. In my experience, it is far more common for password restrictions to be problematic because of forbidden characters than required classes. And, as I already pointed out, this is much more difficult to work around by simply clicking the generate button a few extra times until an acceptable password is found. For a typical user who's unable to get the generator to produce a valid password, I would not expect them to go find a more fully-featured generator that allows them to set the parameters appropriately (or do what I would do and write their own password generator). Instead, I would expect them to do things that compromise the security of their passwords, like shortening them or substituting characters.
I would really like AgileBits to consider storing password-generator settings separately for each password. The more likely users are to get a password that won't be rejected on the first try, the more likely they are to end up with a strong password. And the less work we have to do each time we generate a new password, the less likely we are to mess up. Right now, it seems like I have a 50/50 chance of having to adjust the password generator settings when regenerating a password, even though I almost always want one that uses the same rules as the last time (for a given password).
The other thing that would help the most would be a field to set which symbols are allowed. It would be one simple text field beside or below the "symbols" toggle, and would provide a solution for the vast majority of password-generation problems I've seen. I'd probably hide that field unless a "more options" or "restrict symbols" control was activated, to keep users who wouldn't be capable of using it effectively from getting distracted or confused by it.
I would also want controls to set whether or not character classes are required, and separate upper- and lower-case letters into two different classes, since plenty of password validators require both, but those are a distant third, and I would also not want to include them in the UI in an obvious way. My first thought is to make things like this available via a special custom field in an entry, so "power users" could get the control they want without adding any complexity to the interface for everyone else.
0 -
This is not the only example, but I believe it is sufficient to falsify your claim. Here's another one, for good measure. Neither @Ben nor @Lars makes any reference to development resources in those discussions. I, too, have limited time, so I won't continue trying to convince you that it would be better to emphasize that rather than the debatable merits of the restrictions you choose to place on the apps when communicating with users who clearly think you're making the wrong call. To the extent that you have already been doing so, I'm glad to hear it.
I don't necessarily enumerate every one of the reasons for or against something every time the conversation comes up. I like to give enough perspective that the point is made without writing essays in response to each inquiry. As you say, limited time.
Instead, I would expect them to do things that compromise the security of their passwords, like shortening them or substituting characters.
Indeed, that does seem like a fairly likely case.
I would really like AgileBits to consider storing password-generator settings separately for each password.
It's an interesting idea, and perhaps something we can take into consideration for the future.
even though I almost always want one that uses the same rules as the last time (for a given password).
I'd be interested in better understanding how often sites change their password requirements and how often this might hurt rather than help. For example in the past one of my banks only allowed 8 character passwords (yes, you read that right). They now allow somewhat longer passwords, which of course I'm taking advantage of. But that change might not be obvious, and the password generator might otherwise still be generating 8 character passwords for me for this site, which would obviously not be ideal. I'm not saying that would be definite cause to not do such a thing, just that I'd want to know before advocating for it.
The other thing that would help the most would be a field to set which symbols are allowed. It would be one simple text field beside or below the "symbols" toggle, and would provide a solution for the vast majority of password-generation problems I've seen. I'd probably hide that field unless a "more options" or "restrict symbols" control was activated, to keep users who wouldn't be capable of using it effectively from getting distracted or confused by it.
That seems reasonable.
I would also want controls to set whether or not character classes are required, and separate upper- and lower-case letters into two different classes, since plenty of password validators require both
I take it that we're talking about the words recipe here, given that the characters recipe already includes both upper and lower-case?
Ben
0 -
I take it that we're talking about the words recipe here, given that the characters recipe already includes both upper and lower-case?
No, I'm referring to validators that require both uppercase and lowercase letters (and ususally a digit, and a "special" character, and probably the first character must be a letter, et cetera…).
I'd be interested in better understanding how often sites change their password requirements and how often this might hurt rather than help. For example in the past one of my banks only allowed 8 character passwords (yes, you read that right). They now allow somewhat longer passwords, which of course I'm taking advantage of. But that change might not be obvious, and the password generator might otherwise still be generating 8 character passwords for me for this site, which would obviously not be ideal. I'm not saying that would be definite cause to not do such a thing, just that I'd want to know before advocating for it.
I agree, that would be worth knowing. I've had the same issue with banks in the not-so-distant past (I think it was only a year or so ago that one bank I used only allowed an 8-digit password). But here's a counter argument: unless I change my password routinely, I would have no reason to be updating that password unless I either was concerned about a possible security breach, or I got the news that they now allow better-quality passwords. And banks do tend to advertise security improvements to their customers, because they want those customers to feel protected. Even when those "security improvements" are pointless theatre. So, the question becomes, "Why am I changing my password?" and the answer is probably, "Because the bank just told me I can finally have a strong password!"
0 -
No, I'm referring to validators that require both uppercase and lowercase letters (and ususally a digit, and a "special" character, and probably the first character must be a letter, et cetera…).
Gotcha.
I agree, that would be worth knowing. I've had the same issue with banks in the not-so-distant past (I think it was only a year or so ago that one bank I used only allowed an 8-digit password). But here's a counter argument: unless I change my password routinely, I would have no reason to be updating that password unless I either was concerned about a possible security breach, or I got the news that they now allow better-quality passwords. And banks do tend to advertise security improvements to their customers, because they want those customers to feel protected. Even when those "security improvements" are pointless theatre. So, the question becomes, "Why am I changing my password?" and the answer is probably, "Because the bank just told me I can finally have a strong password!"
Another possible cause is that some sites still require routine password changes... banks notoriously so.
Ben
0 -
Another possible cause is that some sites still require routine password changes... banks notoriously so.
That, I must admit, is something I haven't seen in many years. I can't recall if I've ever had an account at a financial institution that had such a policy, and I still think that a bank that changes its password strength policy would go out of its way to inform its customers, particularly when they are changing passwords, whether they've been required to do so or not.
And in the case where the user must change passwords frequently, but the policy hasn't changed, that's where it's most useful to have whatever silly constraints they require recorded.
0 -
And in the case where the user must change passwords frequently, but the policy hasn't changed, that's where it's most useful to have whatever silly constraints they require recorded.
Of course. :)
That, I must admit, is something I haven't seen in many years. I can't recall if I've ever had an account at a financial institution that had such a policy, and I still think that a bank that changes its password strength policy would go out of its way to inform its customers, particularly when they are changing passwords, whether they've been required to do so or not.
I have two that still do it though I wish they wouldn't.
Ben
0 -
This is not the only example, but I believe it is sufficient to falsify your claim. Here's another one, for good measure. Neither @Ben nor @Lars makes any reference to development resources in those discussions. I, too, have limited time, so I won't continue trying to convince you that it would be better to emphasize that rather than the debatable merits of the restrictions you choose to place on the apps when communicating with users who clearly think you're making the wrong call. To the extent that you have already been doing so, I'm glad to hear it.
@gedankenexperimenter: It really seems like you're just going around trying to find things to argue about. Literally everything else you're saying -- feature requests, security observations, and questions about how 1Password works -- seems really thoughtful and is greatly appreciated. But this sort of thing doesn't benefit anyone who comes here for help with 1Password, which is the reason this support forum exists. Please keep that in mind before commenting further. There are plenty of opportunities to pick fights elsewhere on the internet. Not that I'd recommend or condone it in that case either, but that's not my business. :lol:
0 -
Hey, @gedankenexperimenter.
Ben commented on these above, but I wanted to add some comments from my perspective, having worked on the password generator and given the talk Goldberg linked much earlier.
I would really like AgileBits to consider storing password-generator settings separately for each password.
This isn't out of the question. It's true that sometimes things are not implemented because the demand seems low and we can't add every feature any user requests. But this is something that's come up before, and I can't say it won't happen (or that it will, but you know that).
The other thing that would help the most would be a field to set which symbols are allowed.
We're probably less inclined to do this and more inclined to remove a few symbols from our set that are commonly prohibited. Achieving the maximum possible entropy for every set of password rules just isn't our highest priority. We do try to find the best way to get things to "just work" for the majority of sites, which is why the default recipe is letters and numbers, no symbols. That said, this has also come up before and could change. This piece from earlier is another option:
I love the idea of a crowd-sourced open database listing the dumb password restrictions of various websites, automatically used by password managers to generate valid passwords for those sites. The problem is that it might get hacked, of course, or simply fed bad data.
At PasswordsCon 2018, where I gave my talk, this was the subject of the first talk, right before mine, and I'd still like to see it happen. You can see some discussion on Twitter here:
I describe how sites could override any such repo, and we could test submissions automatically with CI. We could feed this kind of data to our password generator behind the scenes and thus generate better passwords without exposing any additional UI.I would also want controls to set whether or not character classes are required
This was the entire subject of my talk. The difference between requiring and not requiring is not much, and it decreases with every character added. In one of the final slides, I show that when using our default recipe (lower + upper + digits - ambiguous) the difference between requiring the character classes and not is less than 1 bit of entropy once the password is 6 characters long or more. This is another case where we might take this info from the passwordrules attribute or from a database of these rules, but probably not expose the option because it's just not that important.
and separate upper- and lower-case letters into two different classes, since plenty of password validators require both
I get to end on a good note! This is actually how the new generator works behind the scenes. When turning on letters, both lowercase and uppercase are required. This will be rolling out to all clients eventually.
0
https://youtu.be/3IXx_6a_TPs