password-policy-vectors.json

Rama master · réplica de lectura del repositorio original.

{
  "//": "Shared contract between the two halves of the password policy: api/src/password.rs and frontend/src/utils/passwordPolicy.ts. Both test suites read this file and must reach the same verdict for every vector, so a form can never accept what the API refuses, nor blame a different rule for the same password. Only the identity half is pinned here — the blocklist lives on the server alone. `verdict` is one of: acceptable, similarToEmail, similarToName.",
  "vectors": [
    {
      "why": "The reported vulnerability: the password is the account's email address.",
      "password": "jordanrivera801@example.com",
      "email": "jordanrivera801@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "similarToEmail"
    },
    {
      "why": "Decorating the address must not walk past the rule; the domain is public.",
      "password": "jordanrivera801@example.com!",
      "email": "jordanrivera801@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "similarToEmail"
    },
    {
      "why": "Same, prefixed rather than suffixed.",
      "password": "xjordanrivera801@example.com",
      "email": "jordanrivera801@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "similarToEmail"
    },
    {
      "why": "The local part alone.",
      "password": "jordanrivera801",
      "email": "jordanrivera801@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "similarToEmail"
    },
    {
      "why": "Lookalike substitutions must not hide the address.",
      "password": "j0rd4nrivera801@example.com",
      "email": "jordanrivera801@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "similarToEmail"
    },
    {
      "why": "A password that is mostly the user's name.",
      "password": "rivera-is-here",
      "email": "jordanrivera801@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "similarToName"
    },
    {
      "why": "Ordinary first.last address whose halves are the user's names: both sides must blame the same rule. The two implementations used to disagree here, one saying email and the other name.",
      "password": "rivera-rivera",
      "email": "jordan.rivera@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "similarToEmail"
    },
    {
      "why": "Astral characters: counted once as code points, twice as UTF-16 units. Counting units moved the remainder threshold and made the form accept what the API refuses.",
      "password": "john.doe𝐀𝐁𝐂𝐃",
      "email": "john.doe@example.com",
      "firstName": "",
      "lastName": "",
      "verdict": "similarToEmail"
    },
    {
      "why": "Other_Alphabetic marks (Devanagari vowel sign): kept by Rust's is_alphanumeric, dropped by a naive \\p{L}. Dropping them made the form refuse what the API accepts, for users writing in Indic, Thai, Arabic or Hebrew scripts.",
      "password": "john.doeिििििििि",
      "email": "john.doe@example.com",
      "firstName": "",
      "lastName": "",
      "verdict": "acceptable"
    },
    {
      "why": "A passphrase that merely contains a short name keeps its own strength.",
      "password": "generic thunder quilt",
      "email": "eric@example.com",
      "firstName": "Eric",
      "lastName": "Smith",
      "verdict": "acceptable"
    },
    {
      "why": "A password that merely opens with the user name: the rest is still a secret.",
      "password": "TestPassword123!1754000000000",
      "email": "test-navigation-1754000000000@hook0.local",
      "firstName": "Test",
      "lastName": "User",
      "verdict": "acceptable"
    },
    {
      "why": "A very short name must not reject unrelated passwords.",
      "password": "quilt lantern harbour",
      "email": "l.i@example.com",
      "firstName": "Li",
      "lastName": "Ito",
      "verdict": "acceptable"
    },
    {
      "why": "Folds to nothing: no identity to compare against. The length and diversity rules are what bound this one, on the server.",
      "password": "#%&*()[]{}<>",
      "email": "john.doe@example.com",
      "firstName": "John",
      "lastName": "Doe",
      "verdict": "acceptable"
    },
    {
      "why": "Folds to a single letter, which almost any address contains. Being inside the address only means something when there is enough of the password left to recognise; otherwise a pile of symbols gets blamed on the email.",
      "password": "#%^&*()-_=+[]{}@",
      "email": "jordan.rivera@example.com",
      "firstName": "Jordan",
      "lastName": "Rivera",
      "verdict": "acceptable"
    }
  ],
  "//maximumLength": "The password ceiling. Not operator-configurable, so the frontend mirrors the constant rather than fetching it; both suites check their own constant against this number, so the two cannot drift.",
  "maximumLength": 100,
  "//rejectionProblemIds":"Every API error that means 'the password was refused', as opposed to 'the request failed'. The API test suite checks this list against `Rejection::into_problem`, the frontend test suite checks it against the ids the forms attach to the password field: a rejection reason added on one side without the other stops being a silent toast-only error.",
  "rejectionProblemIds": [
    "PasswordTooShort",
    "PasswordTooLong",
    "PasswordSimilarToEmail",
    "PasswordSimilarToName",
    "PasswordTooCommon",
    "PasswordNotDiverseEnough"
  ]
}