Issue Description
When trying to step through the migration from 0.15 to 0.16, importing the snapshot fails with errors related to the password strength and passwords are too easy. All our users are LDAP backed and dont actually have passwords configured in stalwart as it is handled by LDAP bind.
Expected Behavior
Allow the import to complete
Actual Behavior
I lost the actual error but it errored on creating users in snapshot due to password strength and and example of ‘aaa’ being too easy etc etc. subsequent imports fail to reproduce the error and fail due to conflicts of the partial restore
Reproduction Steps
configure and have stalwart 0.15 running with only LDAP users - no local auth other than web admin
go through export and migration → snapshot import to 0.16
see error
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
Filesystem
Search Engine
Internal
Directory Backend
LDAP
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
Let me research this issue around password strength validation during migration/import.
This is the key finding. Looking at line 297-300, there is already logic that skips the is_secure_password check when the credential value looks like a password hash (starts with $ or { and passes is_password_hash). The issue is that 0.15 LDAP-backed users apparently had placeholder/dummy passwords (like aaa) stored as plain text in the export, and those fail the strength check on import since they don’t look like hashes.
The workaround and the root cause are now clear. Here is the answer:
The snapshot importer does run the password strength check (zxcvbn) for any credential that is not recognised as an existing password hash. When 0.15 exports LDAP-backed accounts it appears to include a placeholder plain-text credential (something like aaa), which fails the strength gate because it is not prefixed with a recognised hash marker ($, {, etc.).
Immediate workaround: Before importing, temporarily disable the password strength requirement by setting passwordMinStrength to zero in the Authentication singleton (WebUI: Settings > Authentication > General, or via the CLI). This tells Stalwart to skip the zxcvbn check entirely. After the import completes successfully, set it back to your preferred level (three is the default).
The underlying reason this is safe for your deployment is that LDAP-backed principals do not use the stored credential for authentication at all – the LDAP bind handles it – so those placeholder values are inert and the policy check has no real security value for them.
The password policy settings (passwordMinStrength, passwordMinLength, etc.) are documented at:
https://stalw.art/docs/auth/authentication/passwords
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
ok fyi - i did rollback and assigned each LDAP user a strong password and attempted to migrate again. same error:
```
✗ create Account: Account: create failed for `restore-98` (operation #2): error: invalidProperties | Password is too weak. Repeats like "aaa" are easy to guess. Add another word or two. Uncommon words are better. Avoid repeated words and characters. | Properties: secret
Done: 0 destroyed, 0 updated, 2 created (1 failed)
error: Account: create failed for `restore-98` (operation #2): error: invalidProperties | Password is too weak. Repeats like "aaa" are easy to guess. Add another word or two. Uncommon words are better. Avoid repeated words and characters. | Properties: secret
i can try to use the stalwart-cli to make the change you mention but i am having issues with the syntax. i can query using:
stalwart-cli get Authentication --json
{"directoryId":null,"defaultUserRoleIds":{},"defaultGroupRoleIds":{},"defaultTenantRoleIds":{},"defaultAdminRoleIds":{},"passwordHashAlgorithm":"argon2id","passwordMinLength":8,"passwordMaxLength":128,"passwordMinStrength":"three","passwordDefaultExpiry":null,"maxAppPasswords":5,"maxApiKeys":5,"id":"singleton"}
but i am not actually sure the correct syntax to use to set passwordMinStrength to zero. the web ui following the instructions is not available during migration yet so i must use cli.
well quitting for now. @helpbot please look at the following errors after i rolled back to do a fresh migration and set passwordMinStrength to zero first. same error:
root@mail:/home/administrator# stalwart-cli update Authentication --field passwordMinStrength=zero
Updated Authentication singleton
root@mail:/home/administrator# stalwart-cli apply --file export.json
Plan: 0 destroy, 4 update, 4 create (11 objects)
✓ created Domain (2)
✗ create Account: Account: create failed for `restore-34` (operation #2): error: invalidProperties | Password is too weak. Repeats like "aaa" are easy to guess. Add another word or two. Uncommon words are better. Avoid repeated words and characters. | Properties: secret
Done: 0 destroyed, 0 updated, 2 created (1 failed)
error: Account: create failed for `restore-34` (operation #2): error: invalidProperties | Password is too weak. Repeats like "aaa" are easy to guess. Add another word or two. Uncommon words are better. Avoid repeated words and characters. | Properties: secret
root@mail:/home/administrator# stalwart-cli get Authentication --json | jq .
{
"directoryId": null,
"defaultUserRoleIds": {},
"defaultGroupRoleIds": {},
"defaultTenantRoleIds": {},
"defaultAdminRoleIds": {},
"passwordHashAlgorithm": "argon2id",
"passwordMinLength": 8,
"passwordMaxLength": 128,
"passwordMinStrength": "zero",
"passwordDefaultExpiry": null,
"maxAppPasswords": 5,
"maxApiKeys": 5,
"id": "singleton"
}
i like the bot and all but why isnt there a way to trigger the bot to answer again while we wait for a human? @helpbot
@stalwart curious if you have any feedback on this migration issue? TIA
What you should do in this case is either (a) disable the password strength checks before importing the snapshot (then reload the config) or (b) remove the LDAP credentials from the snapshot.
ok did not think about the ldap credentials but those are strong - as you can see though in the post a few above ( Migration failing to import export.json due to password strength - #4 by sphen13 ) i did lower the password srength setting prior to importing snapshot which ended up with the same error.
Also adjust the min password length and reload the settings afterwards.