[GH-ISSUE #98] Using anything but built in authentication causes users to lose their settings on a password change #81

Closed
opened 2026-02-25 21:34:06 +03:00 by kerem · 2 comments
Owner

Originally created by @jasonmunro on GitHub (Jul 21, 2016).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/98

Originally assigned to: @jasonmunro on GitHub.

Persistent settings stored on the server are encrypted with a key derived from the user's clear text password. If that password changes, their settings are lost (unless using built in auth and the password is changed from inside Cypht). This might be a detectable situation, and we can then prompt the user for their old/new passwords after login to restore the settings.

Originally created by @jasonmunro on GitHub (Jul 21, 2016). Original GitHub issue: https://github.com/cypht-org/cypht/issues/98 Originally assigned to: @jasonmunro on GitHub. Persistent settings stored on the server are encrypted with a key derived from the user's clear text password. If that password changes, their settings are lost (unless using built in auth and the password is changed from inside Cypht). This might be a detectable situation, and we can then prompt the user for their old/new passwords after login to restore the settings.
kerem 2026-02-25 21:34:06 +03:00
  • closed this issue
  • added the
    bug
    core
    labels
Author
Owner

@jasonmunro commented on GitHub (Jul 27, 2016):

This can be detected, and the user_config object now has a flag set on login that can be read by modules to determine if it's appropriate to prompt the user to recover their settings. To complete this solution, I'm going to create a module set that uses this flag and provides a "settings recovery" page. Users can enter their old and new passwords, and we will attempt to decrypt their settings with the old password, then re-encrypt the with the new one.

<!-- gh-comment-id:235713098 --> @jasonmunro commented on GitHub (Jul 27, 2016): This can be detected, and the user_config object now has a flag set on login that can be read by modules to determine if it's appropriate to prompt the user to recover their settings. To complete this solution, I'm going to create a module set that uses this flag and provides a "settings recovery" page. Users can enter their old and new passwords, and we will attempt to decrypt their settings with the old password, then re-encrypt the with the new one.
Author
Owner

@jasonmunro commented on GitHub (Jul 31, 2016):

recover_settings module set is committed to the master branch

<!-- gh-comment-id:236455791 --> @jasonmunro commented on GitHub (Jul 31, 2016): recover_settings module set is committed to the master branch
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/cypht#81
No description provided.