Improved password requirements and usability in Password Generator

Ben

I don't see any feasibility for 1Password to try to automatically do this, it would have to be a manual process.

Indeed... Unless a standard becomes established that most websites adhere to that would have to be the case.

I agree that even a manual option for white/blacklisting specific symbols would be very handy, though.

Ben

AlwaysSortaCurious

+1 for me as well.

Just used a wordlist for the Equifax breach and had to enter a CAP and Number. I get it's a pain, but some incremental improvement would still be appreciated (word list with Upper/Lower and Num as a delimiter, for example, might just meet most needs), a little more control for websites with annoying password requirements would be appreciated.

AGAlumB

@AlwaysSortaCurious: Thanks for the feedback! We'd like to do something in this area in a future version. :)

Eliot_C

This feels like an appropriate thread though looking more at whole passwords than symbols - are passwords generated by 1password prescreened in any way? For example is a generated password compared against any breached password list to ensure a breached password isn't coincidentally being replicated? My assumption is not but just looking for confirmation one way or another.

Cheers,

E

AlwaysSortaCurious

Interesting thought, compare a random or intentional password against a DB of the 500K most popular? (oops, you said breached, that would be, at this stage, every password every entered into any system I think)

I actually see more value for people who like to specify their own to see if they came up with something already not unique.

AGAlumB

This feels like an appropriate thread though looking more at whole passwords than symbols - are passwords generated by 1password prescreened in any way? For example is a generated password compared against any breached password list to ensure a breached password isn't coincidentally being replicated? My assumption is not but just looking for confirmation one way or another.

@Eliot_C: That's a really cool idea. I'm not sure it's feasible do such a broad search (there are a LOT of breached passwords...) at this point, but perhaps that could be an option in the future. AlwaysSortaCurious also raised a good point about using a ranking to ease this...but I think it's fairly reasonable to say that the randomly generated passwords 1Password creates will not have high "popularity" and would not be included in that. But this is really good food for thought. :)

Eliot_C

@brenty @AlwaysSortaCurious thanks for the replies! I figured there was only a fringe chance - heres the backstory: NIST recently(ish) released their updated Digital Identity Guidelines (https://pages.nist.gov/800-63-3/sp800-63b.html) which we have been using as justification to remove our password rotation requirement.
At the same time NIST also recommends comparing any passwords used to a breached list or common password list (like the one available here https://haveibeenpwned.com/Passwords which contains a frightening 320 million passwords (hashed)); I don't like the idea of cherry picking which standards to incorporate so I've been looking into this a bit and was blindly hoping that just by using 1Password we would get a pass there.

Since we use 1Password for our password generation the likelihood of coincidentally creating a match with a breached password is extremely small, but extremely small *320000000 (or as @AlwaysSortaCurious puts it: every password ever put in any system) isn't 0.
Anyway - thanks again!

-E

AGAlumB

NIST recently(ish) released their updated Digital Identity Guidelines (https://pages.nist.gov/800-63-3/sp800-63b.html) which we have been using as justification to remove our password rotation requirement.

@Eliot_C: Oh I love that! Fantastic! That makes a lot of sense. I appreciate you providing the background. Cheers! :)

AlwaysSortaCurious

@elliot_c @brenty OK, maybe not every password ever used, but a boatload >_<

Edit: 320 million passwords and NO ONE ever used

'I Hate My Job'

lol.... I thought that would have been in there for sure.

bundtkate

@AlwaysSortaCurious That sounds more like the password you'd use to unlock your computer at work. Wouldn't work for me, of course (I love my job. No, really, I do. My teammates and all of you are the best. ❤), but I'm sure quite a few folks would have no trouble at all remembering that one. :wink:

AlwaysSortaCurious

@bundtkate lol... I work with a bunch of people that would have used that in externally facing systems, and with 320 million passwords in the DB, wow. I am just surprised that it wasn't there.

You can download the files, but they only share the sha1 hash rather than the password for privacy reasons so anyone can compare a password, but not necessarily ever see them (from that site). But really, I thought that would have been in there.

hmmmm..... I just checked again right this second

'ihatemyjob' (no spaces or caps IS in there). and for giggles I tried 'ihatemyboss' and there was a hit on that.

I guess the added complexity of a space and cap was too much for those folks that would actually use that.

The social aspect of password hacking is still there. Work for a sports enterprise, and I bet a lot of passwords have to do with sports, etc.

AGAlumB

Edit: 320 million passwords and NO ONE ever used 'I Hate My Job'

Hmm...

hmmmm..... I just checked again right this second 'ihatemyjob' (no spaces or caps IS in there). and for giggles I tried 'ihatemyboss' and there was a hit on that.

Bingo! :lol:

The social aspect of password hacking is still there. Work for a sports enterprise, and I bet a lot of passwords have to do with sports, etc.

Definitely. A lot of folks seem to assume that "hackers" are just going to bang away on their accounts at random, and this is done to some extent with automation...but then when they get in someone has to go and try to find something of value. It's much more worthwhile to target a specific individual that is likely to have something of interest and learn things about them that can help you in hacking them.

At least that's what I've heard... ;)

AlwaysSortaCurious

lol... yeah, I assume many think everything must be brute forced, and guess they are if you consider any kind of automation brute force, but with some efficiencies built in. Every curse, curse phrase, string of curses, popular quotes, theme-based phrases (like the sports one used above), yadda, all things nice and not nice.

I'm guessing that those two phrases have too much bitterness associated with them for the typers to even both with spaces or initial caps. ihatemyboss while they were buys using other words in their heads ;)

bundtkate

@AlwaysSortaCurious: At this point, I really think reuse is the biggie. Why even bother brute forcing when data breaches have exposed credentials that may be reused for you? Nevemind the human problem. I remember someone telling a story about their Verizon account continually getting compromised because someone kept calling in claiming to be a Verizon employee helping him with his phone. Didn't even have to answer security questions or know any private info about the account. Just claimed he was with Verizon and done. Heck, if I need a new phone activated, taking this route would probably be quicker than official channels ... :angry:

nils_enevoldsen

Two ideas for implementing this. Both are very demanding to implement.

1. Allow the browser extension to consult a crowdsourced password-constraint dictionary for websites.
2. Allow the browser extension to read the page and attempt to parse any human-readable constraints. This parser might be a long list of AgileBits-curated rules, or it might be trained with machine learning.

(It does raise the possibility of a very convoluted attack vector to make users create very weak passwords, so that has to be defended against.)

tzs

Suggestion: allow specifying a password prefix for a site. The password generator would generate a password by extending the prefix.

Purpose: to deal with annoying password composition requirements.

Example: A site requires passwords of length 8-20, with at least one uppercase, one lowercase, one digit, and one symbol from "!$%^&*". To deal with this site, the user could simply set the prefix to "Ab1%" and then ask the password generator to add 4-16 characters using no symbols.

This should cover most sites with pointless annoying password requirements, in a way that should not be overly difficult either to implement or for the user to understand.

AGAlumB

Two ideas for implementing this. Both are very demanding to implement.

@nils_enevoldsen: Thank you for warning us upfront! :lol: :+1:

• Allow the browser extension to consult a crowdsourced password-constraint dictionary for websites.
• Allow the browser extension to read the page and attempt to parse any human-readable constraints. This parser might be a long list of AgileBits-curated rules, or it might be trained with machine learning.
  (It does raise the possibility of a very convoluted attack vector to make users create very weak passwords, so that has to be defended against.)

Indeed, we have some ideas in these areas. 1Password X uses machine learning to fill web forms better, and we're just getting started there. Crowdsourcing is great for a lot of things, and it may be something we use in other areas in the future. But the geeky nature of login filling suggests that maybe we wouldn't be able to get submissions from but a small subset of the userbase. Nevertheless, we're intrigued. :)

AGAlumB

Suggestion: allow specifying a password prefix for a site. The password generator would generate a password by extending the prefix.
Purpose: to deal with annoying password composition requirements.
Example: A site requires passwords of length 8-20, with at least one uppercase, one lowercase, one digit, and one symbol from "!$%^&*". To deal with this site, the user could simply set the prefix to "Ab1%" and then ask the password generator to add 4-16 characters using no symbols.
This should cover most sites with pointless annoying password requirements, in a way that should not be overly difficult either to implement or for the user to understand.

@tzs: It's a very reasonable suggestion, but it would significantly weaken all of your passwords (and everyone elses!) if we were to institute something like that. I appreciate that it could solve a usability issue for you on many websites with odd requirements, but the very nature of the problem is that the same requirements are rarely in place from one site to the next. Most don't do this at all, or will be equally satisfied with a long, completely random string of capital and lowercase letters. And that will have more entropy than a password which uses a predefined strong at the beginning. It's an interesting idea. I just wish it had better security properties.