Summary
User import assigns the same temporary password to every created user in a migration session via a session-cached get_dummy_password(). Source passwords are never available from the API ($encrypted$ / "Password Disabled"), which is expected — but sharing one temp password across all created users is a security concern when Local Database authentication remains enabled on the target.
Current behavior
UserImporter strips source password / ldap_dn and sets performance_config.get_dummy_password() for all creates, including superusers.get_dummy_password() generates one random value per process and reuses it.- Pre-existing users found by username precheck are mapped and not password-updated.
Why it matters
- If Local auth is enabled, every migrated user shares one known password for the import session.
- For SSO/LDAP users this may be unused for IdP login, but it remains a local-auth fallback until passwords are reset or local auth is disabled.
- Credentials already treat secrets as non-extractable (optional Vault rehydration); users have no equivalent secret path.
Proposed direction
- Generate a unique random temporary password per created user.
- Decide reporting/storage: include in migration report securely, or omit and document forced reset / SSO-only.
- Document clearly that passwords are never migrated and local login requires reset (or IdP).
Related
Summary
User import assigns the same temporary password to every created user in a migration session via a session-cached
get_dummy_password(). Source passwords are never available from the API ($encrypted$/"Password Disabled"), which is expected — but sharing one temp password across all created users is a security concern when Local Database authentication remains enabled on the target.Current behavior
UserImporterstrips sourcepassword/ldap_dnand setsperformance_config.get_dummy_password()for all creates, including superusers.get_dummy_password()generates one random value per process and reuses it.Why it matters
Proposed direction
Related