securitytxt.org VS password-manager-resources

You might consider setting up security.txt notifications, per RFC 9116, to funnel people into the right notification paths. Otherwise, they might try spamming random emails they find or can guess at. I've had external researchers contact our CTO and CEO directly, creating a new problem for me.

Check if they have a security.txt, if they do not, check their /security. If both come up empty, use any contact form that they have available.

In addition to the Bug bounty programs already posted in the comments, I'd suggest you create a security.txt with a dedicated security contact.

Does the website have a responsible disclosure page or a security.txt?

there's technically https://securitytxt.org as well; but sadly it's not in super duper wide deployment (some big places have it, though!)

Especially in the area you guys are operating in, I think it would be great if you could implement RFC 9116 (https://securitytxt.org/). If someone finds a vulnerability on your website, the client or even the SPN, this would make communication or a responsible disclosure process much easier. Furthermore, it would be great if the possibility for secure communication with your staff (e.g. using GPG) would be possible.

When do companies finally start adopting the `security.txt` proposal (see https://securitytxt.org).

Would have made a big difference!

Even Apple was so annoyed at this themselves that they actually went for a full open-source open-for-contributions GitHub repository at https://github.com/apple/password-manager-resources to get around these issues.

> Many password managers generate strong, unique passwords for people so that they aren't tempted to create their passwords by hand, which leads to easily guessed and reused passwords. Every time a password manager generates a password that isn't compatible with a website, a person not only has a bad experience but a reason to be tempted to create their password. Compiling password rule quirks helps fewer people run into issues like these while also documenting that a service's password policy is too restrictive for people using password managers, which may incentivize the services to change.

Check out https://github.com/apple/password-manager-resources

Apple has already created the database for this and made it open source: https://github.com/apple/password-manager-resources

Something like this?

Password rules are really all over the place. Based on the sampling available on Apple's password rules database, seems that the majority of sites would accept a 12-character password (although ironically, most websites that restrict the password to be shorter than 12 characters seem to be banks...).

There are still some things in Keychain that feel stupid. For example, Keychain won't merge https://www.google.co.uk and https://www.google.com accounts into one and you can't do it by yourself, and it will even warn about duplicated passwords for these two websites — that's very stupid especially because Apple maintains open database for password managers which solves the problem of alias domains. But that's the most annoying thing for me.

https://github.com/apple/password-manager-resources/blob/mai...

For being "quite obscure", I've at least heard of most of these sites before. Banks with "maxlength: 8", you love to see it.

FWIW, Apple asks users to tell them the password requirements to websites they notice the "Strong Password" feature doesn't work correctly.

The password complexity rule set is open source, you can contribute requirements for specific sites: https://github.com/apple/password-manager-resources