Skip to main content

SEC.AUTH.ROLE_DEPRECATED_PASSWORD_HASH_LOCKED — A locked account still carrying the retired verifier

  • Category: security
  • Severity: low
  • Level: 0
  • Confidence: deterministic
  • Downtime class: none — the finding is about an account, not about a statement
  • Stability: stable
  • Suites: audit
  • Applies to: PostgreSQL 18 · MySQL 8.4

Why this is reported at all​

The account cannot log in as it stands: it is locked, or its password has expired. So it is not the finding to fix first, and it is reported at low rather than beside the live ones.

It is reported rather than skipped because locking is not fixing. Unlocking is a single statement, the stored verifier is untouched by the lock, and the account comes back carrying exactly what it went away with. A rule that stayed silent here would make ACCOUNT LOCK look like a remediation.

Why it is a separate rule rather than a lower severity​

Severity in SQLens is metadata on the rule, not on the finding — so "the same finding, but less urgent" is not expressible, and deliberately so. A severity that varied per occurrence would make --min-severity unpredictable: the same rule would sometimes pass a gate and sometimes not, for reasons the gate cannot see.

Two ids means the two states can be filtered, baselined and escalated independently, which is what somebody triaging actually wants.

Bad​

-- Locked, and still carrying the old verifier it will come back with
ALTER USER 'legacy'@'%' IDENTIFIED WITH mysql_native_password BY 'secret';
ALTER USER 'legacy'@'%' ACCOUNT LOCK;

Good​

-- Give it a current verifier while it is out of use…
ALTER USER 'legacy'@'%' IDENTIFIED WITH caching_sha2_password BY 'secret';

-- …or drop it, if nothing needs it.
DROP USER 'legacy'@'%';