apple / password-manager-resources

A place for creators and users of password managers to collaborate on resources to make password management better.

Password Manager Resources

Welcome!

The Password Manager Resources project exists so creators of password managers can collaborate on resources to make password management better for users. Resources currently consist of data, or "quirks", as well as code.

"Quirk" is a term from web browser development that refers to a website-specific, hard-coded behavior to work around an issue with a website that can't be fixed in a principled, universal way. In this project, it has the same meaning. Although ideally, the industry will work to eliminate the need for all of the quirks in this project, there's value in customizing behaviors to ensure better user experience. The current quirks are:

• Password Rules: Rules to generate compatible passwords with websites' particular requirements.
• Shared Credentials: Groups of websites known to use the same credential backend, which can be used to enhance suggested credentials to sign in to websites.
• Change Password URLs: To drive the adoption of strong passwords, it's useful to be able to take users directly to websites' change password pages.
• Websites Where 2FA Code is Appended to Password: Some websites use a two-factor authentication scheme where the user must append a generated code to their password when signing in.

Having password managers collaborate on these resources has three high-level benefits:

1. By sharing resources, all password managers can improve their quality with less work than it'd take for any individual password manager to achieve the same effect.
2. By publicly documenting website-specific behaviors, password managers can offer an incentive for websites to use standards or emerging standards to improve their compatibility with password managers; it's no fun to be called out on a list!
3. By improving the quality of password managers, we improve user trust in them as a concept, which benefits everyone.

We encourage you to incorporate the data from this project into your password manager, but kindly ask that you please contribute any quirks you have back to the project so that all users of participating password managers can benefit from your discoveries and testing.

The Resources, In Detail

Password Rules

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.

The file quirks/password-rules.json contains a JSON object mapping domains to known good password rules for generating compatible passwords for use on that website. The Password Rules language is a human- and machine-readable way to concisely write and read the rules to generate a compatible password on a website. quirks/password-rules.json is the quirks version of the passwordRules attribute, which is currently an open WHATWG proposal and supported in Safari. The same language is part of native iOS application development API. If a website changes its password requirements to be general enough to not warrant quirks, or if it adopts the passwordRules attribute to accurately communicate its requirements to password managers and web browsers, it should be removed from this list.

When a domain is listed in quirks/password-rules.json, it means that that domain and all of its subdomains use the rule. For example, a rule for example.com will match URLs on example.com as well as *.example.com. A rule for a.example.com will match URLs on a.example.com as well as *.a.example.com, but will not match other subdomains of example.com such as b.example.com.

A rule that should only be applied to the exact domain stated as a key should have the exact-domain-match-only key set to a value of true. The absence of the exact-domain-match-only key means that it is false.

Password Rules Language Parser

An implementation of a parser for the Password Rules language that's written in JavaScript can be found in tools/PasswordRulesParser.js. It can be used as a reference implementation, interpreted in build systems to convert data/password-rules.json to an application-specific format, or interpreted at application runtime wherever it's possible to execute JavaScript (e.g. using the JavaScriptCore framework on Apple platforms).

A third-party parser implementation that's written in Rust is also available.

Shared Credentials

The files quirks/shared-credentials.json and quirks/shared-credentials-historical.json express relationships between groups of websites that share credentials. The -historical file describes such relationships that were valid in the past but either are not valid today or we don't have a high degree of confidence are valid today.

Information in quirks/shared-credentials.json can be used by password managers to offer contextually relevant accounts to users on first.website, even if credentials were previously saved for second.website. This list should not be used as part of any user experience that releases user credentials to a website without the user's explicit review and consent. In general, saved credentials should only be suggested to users with site-bound scoping. This list is appropriate for allowing a credential saved for website A to appear on website B if the website the credential was saved for is clearly stated.

There are existing proposals to allow different domains to declare an affiliation with each other, which could be a way for websites to solve this problem themselves, given browser and password manager adoption of such a proposal. Until and perhaps beyond then, it is useful to have these groupings of websites to make password filling suggestions more useful.

Information in quirks/shared-credentials-historical.json can be used by password managers to suppress password reuse warnings across websites, given that website A and website B once were known to share credentials in the past.

The Contributing document goes into detail on the format of these files.

Change Password URLs

The file quirks/change-password-URLs.json contains a JSON object mapping domains to URLs where users can change their password. This is the quirks version of the Well Known URL for Changing Passwords. If a website adopts the Change Password URL, it should be removed from this list.

Websites Where 2FA Code is Appended to Password

The file quirks/websites-that-append-2fa-to-password.json contains a JSON array of domains which use a two-factor authentication scheme where the user must append a generated code to their password when signing in. This list of websites could be used to prevent auto-submission of signin forms, allowing the user to append the 2FA code without frustration. It can also be used to suppress prompting to update a saved password when the submitted password is prefixed by the already-stored password.

Contributing

Please review how to contribute if you would like to submit a pull request.

Asking Questions and Discussing Ideas

If you have any questions you'd like to ask publicly, or ideas you'd like to discuss, please raise a GitHub issue or send a message in the project's Slack instance. Anyone participating in the project is welcome to join the Slack instance by emailing the project's maintainers at Apple and asking for an invitation. Please include your GitHub user name when you do this.

Project Maintenance

Project maintenance involves, but is not limited to, adding clarity to incoming issues and reviewing pull requests. Project maintainers can approve and merge pull requests. Reviewing a pull request involves judging that a proposed contribution follows the project's guidelines, as described by the guide to contributing. If you are interested in becoming a project maintainer, please email the project maintainers at Apple with the following information:

• Your name
• Your GitHub user name
• Any organizations you're affiliated with that are related to password management, including professionally
• Links to examples of pull requests submitted, review feedback given, and comments on issues that demonstrate why you'd be a good project maintainer

Ideally, you'd provide somewhere between five and eight examples. The purpose of this note is to remind the Apple maintainers of who you are; ideally, before sending this message, we already know you from your great contributions!

Project maintainers are expected to always follow the project's Code of Conduct, and help to model it for others.

Project Governance

Although we expect this to happen very infrequently, Apple reserves the right to make changes, including changes to data format and scope, to the project at any time.

password-manager-resources's Issues

Add airbnb.com.au and airbnb.com to websites-with-shared-credential-backends.json

See title :)

[BLOCKED] Group “id.atlassian.com” and “trello.com” as sharing a credential backend

Hi,

Atlassian makes bitbucket/trello/jira/etc.

The new "atlassian cloud" and "jira cloud" projects are starting to replace the separate auth backends previously used for (1) bitbucket, and (2) trello.

Is it realistic to add these as "shared backend" at this point?

[Suggestion] add "Close Account" URLs

As a user of the project I want similar access to the close account link for the site in question, to the change password links that already exist, so that I have an easy time closing my account on a service

Make a file similar to this one:
https://github.com/apple/password-manager-resources/blob/master/quirks/change-password-URLs.json

Proposed file:
https://github.com/apple/password-manager-resources/blob/master/quirks/close-account-URLs.json

Website provides their info via page or http header metadata

Would it be helpful to come up with a standard so that websites could declare their password url, password policy, etc. in their page metadata? I know adoption would be slow but would start helping end user experience pretty quickly once password managers start using it.

PasswordRulesParser.js should have unit tests

This is a good initiative. But there are:

• no unit tests
• no comments so not able to follow several flows. For eg: what is the method _parsePasswordRequiredOrAllowedPropertyValue doing?
• Single line if conditions are lacking braces. Did we forget goto fail?

Hopefully the code will get improved over time.

"Ensure that it works properly when the user is [not] logged in" needs clarification

For contributing Change Password URLs, the README states:

Before adding a URL, ensure that it works properly both when the user is logged in and when they are not.

It's not spelled out what exactly is meant by "works properly when the user is not logged in". While testing some Change Password URLs for contribution, I've observed the following range of behaviors when visiting a Change Password URL when not logged in to the site: (Sorted approximately from best to worst experience)

1. The website displays a login page. After signing in, the user is taken to the Change Password page.
2. The website displays a login page. After signing in, the user is taken to the homepage.
3. The website loads the homepage with a message informing the user that they need to log in.
4. The website loads the homepage normally. (i.e. with no indication that the user is trying to navigate somewhere behind a login page.)
5. The Change Password URL leads to a user-friendly error page. (i.e. a "pretty" page that still shows the common navigation elements (toolbars etc...) of the website, allowing the user to log in anyway. This is similar to 3, but simply showing an error in place of the main content of the page.)
6. The Change Password URL leads to a not-user-friendly error page. (i.e. a raw text/JSON/XML response showing the contents of a server-generated error, or a very minimal HTML page that only includes an HTTP status code and maybe shows the URL of the attempted load.)

Obviously scenario 1 is ideal, and scenario 6 is unacceptable since it's totally unactionable to the user. But where is line that separates which Change Password URLs should and shouldn't be included in these quirks? I think that should be clarified, and the README should be updated to provide guidance as to whether or not a URL should be included (based on the not-logged-in experience). As an example, if scenarios 1-5 are acceptable, that could be expressed as:

If the user is not logged in to the site, loading the Change Password URL must not result in an error page, unless the error page makes it clear that the user needs to log in and makes it accessible for the user to do so. This is to ensure that the presence of a Change Password URL quirk does not lead to a worse user experience (compared to navigating to the domain without a path) for a user who wishes to change a password but doesn't have an active login session in the browser opened by their password manager.

Or if the intent is to be more particular about only including the quirk if it universally improves the "change password" experience, something like:

If the user it not logged in to the site, loading the Change Password URL must take the user to a login page that continues to the Change Password page after successful authentication.

could work.

Rename the master branch to main

We should rename the master branch to main

Seems easier than I thought, and important.
https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx

Is there a security risk for "Websites with shared credential backends"?

This resource seems like a potential security risk. A malicious contributor could link a malicious website to a genuine one. Coupled with social engineering or phishing, users of password managers may inadvertently autofill credentials on fake websites.

What is the process to vet these entries?

[Suggestion] Encourage PASSWORD.TXT Files on Servers

I've often thought it would be useful to build a database of password rules and links for login and password reset for websites, so it's great to see this project. But one possible way to flip the responsibility for doing so would be to encourage sites to host a password.txt file, similar in nature to robots.txt, ads.txt and security.txt, that would allow them to make this information available themselves.

Perhaps one way of doing this would be to send an official email to the development team for each website that is added to this repository with an attached password.txt file that would be suitable for adding to their website (i.e. we would pre-fill the information for them).

Apologies if this is an inappropriate use of your issues list, and I do accept that the gut reaction to this idea will be that it's silly :)

Password Rules that are already defined using contraint validation attributes

To avoid duplication and future conflicts between a quirk and the website rules I'm not sure Password Rules should be accepted in the repo if the rules match what the page's markup already indicates via constraint validation attributes e.g. via minlength, maxlength, pattern, etc. The requirements for many sites can be expressed with those constraint validation attributes without the use of passwordrules.

Is that already covered by the - [ ] The given rule isn't particularly standard and obvious for password managers checklist item in the PR? If so, maybe that should be more clear and documented in CONTRIBUTING.md as well.

Why not just putting those informations to our domains?

Apple already has a good approach for "Universal Links" that forcing domain owners to put a configuration file(apple-app-site-association) to their domains for enabling and configuring how they want to use universal links. I think, same approach could be very handy and secure for password rules. As a domain owner we could put a file to our /password-rules.json path with content similar and combined as here. And any password manager could check this url before trying to generate a password for it. In this case if a website/app need to change their password rules, process will be very easy, fast and secure.

Why Apple suggests a different -and very hard to maintain in my opinion- approach now? Am I missing something?

An example file that needs to be published at microsoft.com/password-rules.json:

{
    "password-rules": "minlength: 8; maxlength: 16;",
    "shared-domains": ["microsoft.com", "live.com"],
    "change-password-url": "https://account.microsoft.com/change-password"
}

link to password changing standard

The README.md alludes to standard mechanisms for password changing etc but doesn't reference any of them. @WICG has published one such standard, it would be good to link to it. If there are other ones, please link to them too.

https://wicg.github.io/change-password-url/
https://github.com/WICG/change-password-url
https://news.ycombinator.com/item?id=18618193

Unfortunately it doesn't appear to allow one-click password changing within browser password lists, but it is a good start.

Add leetchi.com

https://www.leetchi.com/en/User/PlainRegister

domain: www.leetchi.com
rules:

8 characters
1 lower case letter
1 upper case letter
1 number
1 special character (@, #, &, etc.)

Password rule for zdf.de has incorrect form

The rule for zdf.de ends with allowed: lower; special;. I'm not sure if special was supposed to be in its own rule or ; should simply be ,.

"zdf.de": {
    "password-rules": "minlength: 8; required: upper; required: digit; allowed: lower; special;"
},

https://github.com/apple/password-manager-resources/blob/main/quirks/password-rules.json#L310

Add bargainbox.co.nz and myfoodbag.co.nz to websites-with-shared-credential-backends.json

Same website.

[Suggestion] 2FA support Quirk

Knowing whether a website supports 2FA would be very helpful for password managers.

Amazon.cn doesn't share credential backends with other Amazon websites.

password-manager-resources/quirks/websites-with-shared-credential-backends.json

Line 20 in f547ed1

"amazon.cn",

[Suggestion] add "Open Account" URLs

As a user of the project I want similar access to the open account link for the site in question, to the change password links that already exist, so that I have an easy time starting a new account on a service

Make a file similar to this one:
https://github.com/apple/password-manager-resources/blob/master/quirks/change-password-URLs.json

Proposed file:
https://github.com/apple/password-manager-resources/blob/master/quirks/open-account-URLs.json

password manager resource

Adopt mandatory order

While the files currently are relatively short, they will probably fill up with rules in no time. To maintain some sort of clarity, I propose to add a mandatory order, like alphabetical, to the contribution rules.

Dealing with Single sign-on (SSO)-enabled Domains

Hi,

when I sign into overleaf.com, I use the "Sign in with Google" button. In such cases, I use my password manager to remind me, "Hey on this website you used 'Sign in with Google'" by manually creating a custom entry in my password manager telling me exactly this.

Currently, there are two ways of handling this particular situation.

A) Use a field such as "username" for this information

B) Add the domain https://www.overleaf.com to my Google account entry

I do not have a good idea how to fix this particular issue, and I just wanted to spark some discussion how a password manager could ideally handle such cases in a user friendly manner.

Best,
Max

example-xxxxx.com domains

So, I've created the PR #96 and added some websites from German banks.
There is this one bank called Sparkasse, one of the most popular banks in Germany.
But here's the thing. Every district got it's own website like
www.sparkasse-putYourDistrictNameInHere.de

E.g www.sparkasse-aachen.de or www.sparkasse-passau.de

Could we like add an option to say like "allow the password generation for every domain which follows this specific scheme: xxxx "?

I think there are several other websites which are built up like my example.

[Suggestion] Add names to websites-with-shared-credential-backends.json

This might not make sense in all cases and is just a suggestion, but many of the websites with a shared backend have a name for their login system - i.e. all of the amazon sites have Amazon login; Marriot, Ritz Carlton, etc all use Marriot Bonvoy, all of the EPIC ski hills use EPIC although are a bit less obvious about it. I'd bet that for the most part these shared-credential sites are owned or managed by one organization.

In the password bank I'm building, if I'm going to insert a user's credentials that they entered on a different website because I know that they will be shared, for full transparency I'm going to want to show them a) the site they originally entered the credentials at, and if possible b) the name of the credentials platform, and c) the name of the organization that manages it. And theoretically when they sign up originally I'll want to inform them that the credentials will be used for X login system and may be shared across these [x,y,z] websites. If the name of the credential system or organization were also captured in this listing, it would definitely make implementing this user experience much simpler - otherwise I'm just going to be making some sort of mapping in my own project with the appropriate names.

This in a simplistic form could be like:

{
  "Apple": [
    "apple.com",
    "icloud.com"
  ],
  "Amazon": [
    ...
  ],
  "Marriott Bonvoy": [
    "marriott.com",
    ...
  ],
  ...
}

but I think this would be better as it would be more capable of capturing the fact that there maybe cases where there is not one simple name or organization.

[
  {
    "name": "Apple ID",
    "org": "Apple",
    "sites": [
      "apple.com",
      "icloud.com"
     ],
  },
  {
    "name": "Login with Amazon",
    "org": "Amazon",
    "sites": [
      ...
    ],
  },
  {
    "name": "Marriott Bonvoy",
    "org": "Marriott",
    "sites": [
      ...
     ],
  },
  ...
]

There might be some disagreement about what the names should actually be so maybe this would be a difficult proposition, but I hope it bears consideration.

Metadata support for Password Rules

For websites where password rules that are already defined using constraint validation attributes can be marked with some metadata so that password managers can understand whether the constraints are standard and obvious for password managers.

This issue is created w.r.t #237

Password bug

The password created by safari/webkit engine that would not be accepted at this website.

The template/formula that Safari/Webkit/Safari Tech. Preview uses to create a safe and secure password does not meet the standards for many websites. I have attached 1 example for the developer forum to create an account on the ARM architecture website.

The criteria requested is :
8-16 characters, containing 3 out of 4 of the following: Lowercase characters, uppercase characters, digits (0-9), and one or more of the following symbols: @ # $ % ^ & * - _ + = [ ] { } | \ : ' , ? / ` ~ " ( ) ; .

the created autofill password (see attachment 2) was rejected.

My suggestion is the Apple-manager resource implements a feature (via long-press, tap and hold, or 3d touch) whereby the user can determine how many chars, inters, and special chars, or strings are included in the password. It should have a default, but can be edited via this menu.

[Suggestion] Use JSON fully for password-rules.json

Hi - I'm potential target of this repository as I'm working for a startup building a password manager (among other things). I'm very excited about this repository as it might make my life a lot easier once we get done with it!

I have one question for the maintainers though - why was it decided not to use JSON to express the password rules rather than a custom format for the data? If it were to save characters that would be reasonable, but it appears to be a very similar length.

What I'm asking is, why can't this:

{
    "163.com": {
        "password-rules": "minlength: 6; maxlength: 16;"
    },
    ...

be this:

{
    "163.com": {
        "password-rules": { "minlength": 6, "maxlength": 16 }
    },
    ...

or even better since this entire document is just for password rules (although I could understand doing it the aforementioned way if the document might eventually contain other things as well...) :

{
    "163.com": {
        "minlength": 6, "maxlength": 16
    },
    ...

That way there would still need to be some custom logic for it, but it wouldn't necessitate writing a complete custom parser just to extract information from an already structured data format.

If there is enough support for this change I would be more than happy to make a PR converting the document, although I don't know that I have the time to rewrite the parser at this moment.

consider adding example URLs for automated testing of shared backends

I propose adding URLs for the shared backend groups. As shown below.

The URL should point to a page on that domain, that returns a 2XX-3XX HTTP response (e.g., redirects ok), and (preferably) includes at least one HTML form element for a username.

The goal here is to enable minimal automated testing of these groups, and also to indicate when a group is no longer necessary.

    [
        {"kcls.bibliocommons.com", "https://kcls.bibliocommons.com/user/login"},
        {"kcls.overdrive.com", "https://kcls.overdrive.com/account/ozone/sign-in"},
        {"kcls.org", "https://login.ezproxy.kcls.org/login"}
    ],

MaivKhanh

shared backend appropriate when one domain is a subdomain?

Is a shared backend group appropriate when one domain is a subdomain?

For example, you enter your seattle public library username/pin on pages served from both these sites:
seattle.bibliocommons.com (library catalog)
spl.overdrive.com (ebooks)
spl.org (access online library resources, eg, databases)

Is the fact this rule only works for "seattle.bibliocommons.com" a problem?

Consider, the St. Louis Public Library uses:
slpl.bibliocommons.com
slpl.overdrive.com
slpl.org

playstation.com -> id.sonyentertainmentnetwork.com

I can use my details for playstation.com to login at id.sonyentertainmentnetwork.com.

Often I end up with my password manager saving my details to playstation.com which then prevents it showing when I actually login via id.sonyentertainmentnetwork.com.

[Feature] Web interface for new websites

Hey guys!

I was thinking about a web interface, which can be used to submit additional Websites.
This could be sth like a form, where you have to give a source (screenshot and/or link) for your password rules, the website url, the password rule "generator" itself (similar the the generator on https://developer.apple.com/password-rules/) and if needed a list of shared-credentials sites.
This form could create a PR on a second branch, e.g website-suggestions.

This provides the advantage to actually split suggestions from actual code changes, because I think it's kinda confused right now.
Furthermore this is also a solution for alphabetical order (I'm aware of the GitHub Action in PR #130)
In addition, people who don't know how to use the JSON syntax, can actually contribute to this Open-Source Project.

Give me some feedback on this!

Dealing with broadband routers and consumer IoT devices that hijack the DNS

Hi,

consumer broadband routers [A, B, C] and some IoT devices hijack the DNS for convenient web interface access.

Examples include:

   http://speedport.ip --> http://192.168.2.1

   http://fritz.box --> http://192.168.178.1

   http://vodafone.station --> http://192.168.1.1

Should we add such cases to the quirks/websites-with-shared-credential-backends?

Best,
Max

Document what a set of password requirements not worthy of incorporation into the project is

In #86, David Jennes writes:

This is maybe a more general discussion for this project: do we want to document every password quirk for each website? Or can we agree to a set of rules that we assume (or require?) that each password manager will at least adhere to? I'm pretty sure that each password manager will generate something longer than 8 characters. Not sure if the same can be said for 16 chars (or longer), that's something that may be dependent on the user's settings.

This seems worth doing, to me.

[Suggestion] indicate if website disables copy/paste on password fields

Some websites still disable copy/paste when changing passwords, for example aeroplan.com.

Could this project incorporate a way to indicate the websites that do this? It can be very inconvenient if not impossible to input a generated password for the average user - I personally end up having to use DevTools...

Include support for multiple password rules for a website

Currently, the parser supports a single rule for a website. But there are websites that have multiple rules such as --

• password should be minimum 15 characters in length
  OR
• password should be minimum 8 characters in length and include a lowercase letter and a number

Add airnewzealand domains to shared login

Air New Zealand has at least 3 domains, I think they may have more. They share the same login.

• https://www.airnewzealand.co.nz
• https://www.airnewzealand.com
• https://www.airnewzealand.com.au

Note you have to disable ITP to test this https://www.airnewzealand.co.nz/web-browser-compatibility#safari-signin

[Suggestion] Include Special Character Class Resources

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

Password rules language doesn’t allow us to express Digital Ocean’s requirement that passwords not end in number or special character

Password rules language doesn’t allow us to express Digital Ocean’s requirement that passwords not end in number or special character

Spotted here:
https://twitter.com/denvercoder/status/1287981865694105602?s=20

Parity with lastpass on password changing links

They have a list on https://helpdesk.lastpass.com/generating-a-password/auto-password-change-beta/ but I am not sure if it is up to date.

Amazon.co.jp does not share credentials with other Amazon sites

Hi,

I have separate credentials for Amazon.co.jp and the rest of Amazon.
I also use .com, .co.uk, .de, .fr, .it and .es.

However, the shared credentials descriptions in this repo list Amazon.co.jp as sharing credentials with other Amazon sites:

https://github.com/apple/password-manager-resources/blob/f74c6d0/quirks/websites-with-shared-credential-backends.json#L105

Seems like a bug?

[Suggestion] Add URLs for account deletion

As in title, if there is interest in this. Account deletion is part of the normal account/personal-data management life-cycle, and like password updates, it helps if it's easy to find where to do it.

Translate rules over from the Dumb Password Rules project

Saw this mentioned in a Slack conversation:
https://github.com/dumb-password-rules/dumb-password-rules

There's a whole plethora of examples that we could collect from that document, after verifying them and converting to the right format.

Three sets of websites that share password back ends

From looking at my own list of passwords and reviewing how the accounts work, it seems that these 3 sets of websites each share password back ends:

audi.com
audiusa.com

myuhc.com
optum.com
optumrx.com

newyorker.com
vanityfair.com

Banking domains?

Is it ok to include banking domains here?

Dealing with multiple/different change password URLs on a single domain

Hi,

Deutsche Bahn is the main German railway company. Depending on whether you sign in with your private or business account the change password URL differs.

A) Private account:

B) Business account:

Note that in such cases, the domain itself is no longer enough to guide the user to the correct "change password" URL.

Best,
Max

Flickr no longer shares credentials with Yahoo

I think this entry should be removed now that Flickr is migrating away from Yahoo login.

password-manager-resources/quirks/websites-with-shared-credential-backends.json

Lines 296 to 297 in e6ee721

	"yahoo.com",
	"flickr.com"

[SUGGESTION] add Amazon.fr and French websites

Add french websites

HDFC Bank's website password cannot be saved to password managers

HDFC Bank's website (https://www.hdfcbank.com) randomizes the password before the password managers can save them thus saving incorrect password.

[Discussion] Dealing with or-conditions in password rules

Some websites require, for example, one digit OR one special character. While it seems to be possible to create password rules with an or-condition (see this article) I'm wondering whether we should do this or whether we should just require both things.

Or to put it another way, when a website accepts, for example, digits and characters, wouldn't be it beneficial in terms of security when we make password managers use digits and characters instead of only one of them?

Validation Tool acts strange when max length is between 15 and 20

Description

The Password Rules Validation Tool suggests passwords of non-max length when symbols are not allowed and when max length is between 15-19 and

Replicate

1. Go to https://developer.apple.com/password-rules/
2. Use these rules:

required: lower;
required: upper;
required: digit;

3. Set min length to any (let's say 7)
4. Set max length to 15
5. Suggested passwords will be of length 12.
6. max length 15-19 will all have a length of 12 with these settings.