Feature request: Generating unicode passwords

publicarray

All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets; Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well.

https://pages.nist.gov/800-63-3/sp800-63b.html

I think this could be implemented as a checkbox to enable unicode password generation.
In the future my passwords could look like this: /jks

ag_TJLuoma

Hi @publicarray

I would love emoji/unicode passwords! I'd assume there would be a lot of places where they wouldn't work, but where they did work, it would add another layer of complexity to your passwords and make them even harder to crack!

Thanks for the suggestion!

Tj

MrC

How would you handle the cases where a letter can be constructed by two different means (one with or without a combining character)? The character appears the same, but is actually two distinctly different byte sequences.

AGAlumB

@MrC: That's an excellent point. I couldn't for the life of me remember what they were called so I looked it up: ZWJ (Zero Width Joiner) emoji work either as a single combined symbol (on platforms that support them) or as groups of emoji representing the same idea everywhere else.

@publicarray: Fascinating stuff, and emoji passwords would be cool...but the ZWJ thing along with the fact that almost no one really knows the names of these (except maybe the folks at Emojipedia), not all platforms support all of them (or represent them the same way), and many websites still have trouble with symbols of any kind makes me think this is an idea before its time. Maybe someday though. :)

publicarray

Thanks @MrC and @brenty I totally forgot that ZWJ existed :chuffed:

I expect that the problem with ZWJ and character length has do be dealt with on the website's side as there is nothing 1password can do about it. As a web developer I have build websites using the laravel framework which by default supports anything you can put into a text field (obviously some developers add unnecessary restrictions sigh)

In terms of generating cross-platform unicode support, that is indeed a problem but if you don't want to rely on the OS http://cldr.unicode.org, or for c/c++ and java http://site.icu-project.org should solve this. Representation hmm yes :sweat:

I agree it is premature but I believe the push to more secure passwords can never happen too early :smile:

AGAlumB

Thanks @MrC and @brenty I totally forgot that ZWJ existed :chuffed:

@publicarray: So did I until it came up here. :lol:

I expect that the problem with ZWJ and character length has do be dealt with on the website's side as there is nothing 1password can do about it. As a web developer I have build websites using the laravel framework which by default supports anything you can put into a text field (obviously some developers add unnecessary restrictions sigh)

That's what scares me. I'm sure this doesn't reflect on you, but I've seen way too much insanity just troubleshooting website issues to maintain much optimism to expect standards-based design. ;)

In terms of generating cross-platform unicode support, that is indeed a problem but if you don't want to rely on the OS http://cldr.unicode.org, or for c/c++ and java http://site.icu-project.org should solve this. Representation hmm yes :sweat:
I agree it is premature but I believe the push to more secure passwords can never happen too early :smile:

Indeed, and I agree that we always need to be looking toward the future. But it's important to remember that there's a lot we can do with what we have today. Even if many sites still limit password length and composition, those sites certainly won't work with emoji anyway. And in cases where good security practices are in use (salting and hashing), we can get even better entropy to push brute force attacks right off the table for the foreseeable future. So while it certainly isn't dire, we'll continue to plan ahead and thank our lucky stars when web developers get it right. Cheers! :)