[Suggestion] Include Special Character Class Resources

[ewc7092]

Apple Developer resources have documentation regarding character classes in UI kit. This information could be useful if republished here for individuals who are crafting new rulesets particularly for special characters, as many sites are nebulous about exactly what characters they support, requiring some trial and error.

Example Special Characters Sets: Apple : -~!@#$%^&_+=`|(){}[:;"'<>,.? ] OWASP: !"#$%&'()+,-./:;<=>?@[]^_`{|}~

[TomEarnest]

How about a character set for a site that specifies Special Characters "Not to Include the Following Special Characters : .... " One of our banking sites works this way. Otherwise Apple's Suggested Passwords would work fine. I always have to remove or replace the Not Allowed Characters to use the Apple Suggested Password.

[duffn]

How about a character set for a site that specifies Special Characters "Not to Include the Following Special Characters : .... "

Yes, this would be great. That are unfortunately so many sites that do this.

[rmondello]

My gut tells me that constructing rules based on what is permitted, and not what is not permitted, will be more straightforward for password manager adoption. However, it is true that it does make it harder to create the rules. I think it would be great for one of us to write a short guide for translating a ‘cannot include’ description to a ‘can include’ rule, and add it to the README. There may also be tooling that could help with this!

[ewc7092]

Thanks all for the comments. I could see the value of an "exclude this" character space, but my suggestion is more focused on the documentation side rather than defining a new quirk.

I was thinking more along the lines of including this type of information in the README or as a separate resource within the documentation to provide a starting point for figuring out usable special characters. If the site provides allowable special characters then crafting a ruleset is made much easier. I'd say most don't or, they provide a subset characters (e.g. $,&,#) without defining the rest of the allowable characters. This would just establish a baseline set of special characters to test with, specified in the README to make this information handy for new contributors. It would probably be sufficient to provide a link to the UIkit Customizing Password AutoFill Rules documentation, where the below string is sourced.

-~!@#$%^&*_+=`|(){}[:;"'<>,.? ]

@rmondello I think your idea of converting 'cannot include' is definitely a good follow up effort. Perhaps I can make this into a separate issue.

[rmondello]

This makes sense to me. Thanks for the follow-up explanation, @ewc7092; it helped me a lot.

The repository could better document the “special” bit of special characters, and how character classes work in general. This idea makes sense to me and I’d like us to do this. If anyone would like to give this a try, I’d love to work with you on this.

[TomEarnest]

Safari generates a random password that contains groups of AlphaNumeric characters separated by hyphens or minus signs ( - ). One of our banks does not like Safari's use of Minus signs ( - ). Therefore, I have to replace the Minus signs ( - ) in the Safari Suggested Password with something else, such as a space or $ sign. I often use a $ sign because in my mind a bank likes $ signs and they hate to minus ( - ) the $'s. This is just a little quirk in the bank's acceptance of Safari passwords that allow me to use them , but not change them very much...

In general, I like Safari's Method of suggesting passwords and saving them. Then via the use of iCloud encryption , it allows other devices, Macs, Phones, Tablets, etc. to be able to use (know) the same password for a specific site that has been assigned by another device.

A website on Security that may be of help w general reading is : https://staysafeonline.org This website might be of use in writing the code.

I wish I could just ask Safari to not use a - sign sometimes and replace it with something else such as the $ sign.

Unfortunately, I cannot participate in writing the code myself. I am just a retired beginner.

[ewc7092]

@rmondello I can try to come up with a draft of some documentation.

[jpgoldberg]

My gut tells me that constructing rules based on what is permitted, and not what is not permitted, will be more straightforward for password manager adoption.

We, 1Password, can go either way. Our generator does internally have a mechanism for directly handling excluded characters, but we don't need to use that.

For a human reading (and perhaps writing) password-rules, I think that having an ability to list excluded characters may make sense as it better expresses what is going on to a human. For machines reading these, I don't think it matters.

I should also note that just going through the rules in this repo, a list of symbols to exclude would be longer than just listed the symbols to allow/require.