[GH-ISSUE #99] Backwards compatibility breakage coming, here is what you can do #79

New issue

Closed

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

kerem commented

2026-02-25 21:34:06 +03:00

Owner

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

There are 2 issues in the code that will break existing saved settings. Both are pro-active changes to address potential security issues, neither of which has been exploited or proven exploitable.

The same key was being used to both encrypt strings and build the hmac hash used to verify an encrypted payload. I'm not aware of specific guidance that these must be different, but it seems reasonable to use different keys here just in case.
User and site settings currently use PHP serialize. Unserializing data opens a potential vulnerability if the data has been compromised. To avoid this potential vector we are switching to json based encoding.

HOW TO UPDATE YOUR SETTINGS:

Pull the current master branch
Run the config generator "php ./scripts/config_gen.php"
Login and save your settings.
Thats it!

Once you do that, your data will be updated to the new formats and won't be lost when the final changes go in. I plan on making the switch over in about 1 week.

Originally created by @jasonmunro on GitHub (Jul 24, 2016). Original GitHub issue: https://github.com/cypht-org/cypht/issues/99 There are 2 issues in the code that will break existing saved settings. Both are pro-active changes to address potential security issues, neither of which has been exploited or proven exploitable. 1. The same key was being used to both encrypt strings and build the hmac hash used to verify an encrypted payload. I'm not aware of specific guidance that these must be different, but it seems reasonable to use different keys here just in case. 2. User and site settings currently use PHP serialize. Unserializing data opens a potential vulnerability if the data has been compromised. To avoid this potential vector we are switching to json based encoding. HOW TO UPDATE YOUR SETTINGS: - Pull the current master branch - Run the config generator "php ./scripts/config_gen.php" - Login and save your settings. - Thats it! Once you do that, your data will be updated to the new formats and won't be lost when the final changes go in. I plan on making the switch over in about 1 week.

kerem closed this issue

2026-02-25 21:34:06 +03:00

kerem commented

2026-02-25 21:34:06 +03:00

Author

Owner

@ulfgebhardt commented on GitHub (Jul 26, 2016):

Hello @jasonmunro ,

i have an issue with this procedure ;-). I dont update your Software in 1weeks time.

To save my Settings i would like you to detect wether the saved settings is the old or new format and convert it if possible - or make it convert on config_gen. I guess there might be a Problem with Encryption, since the server might not be able 2 decrypt the string on its own, without the users password(???) - if so, please ask the user for his password to convert the Data on login. In this step i recommend to include a version number if thats possible so you can change the settings whenever you like.

Do this if its possible and not too much work, i use your software still in a small environment with few users, but if that might change this could be a real pain.

Thanks for your Time and Effort you put into this for all of us!

@ulfgebhardt commented on GitHub (Jul 26, 2016): Hello @jasonmunro , i have an issue with this procedure ;-). I dont update your Software in 1weeks time. To save my Settings i would like you to detect wether the saved settings is the old or new format and convert it if possible - or make it convert on config_gen. I guess there might be a Problem with Encryption, since the server might not be able 2 decrypt the string on its own, without the users password(???) - if so, please ask the user for his password to convert the Data on login. In this step i recommend to include a version number if thats possible so you can change the settings whenever you like. Do this if its possible and not too much work, i use your software still in a small environment with few users, but if that might change this could be a real pain. Thanks for your Time and Effort you put into this for all of us!

kerem commented

2026-02-25 21:34:06 +03:00

Author

Owner

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

@ulfgebhardt, thanks for the feedback!
Currently the code does just what you suggest, it checks for the old/new formats and converts them to the newer format on user save/config generation, and the hmac signature check tries both the old and the new keys when validating an encrypted string. Technically, I don't have to remove the legacy support, and I could seamlessly update the user settings on login if the old format is detected without too much effort (or the user even knowing about it).

Honestly, I picked a 1 week time frame because I did not think it would be problem for anyone. Now that I know it is, I have no problem delaying the switch over, or even maintaining legacy support using a version number perpetually. Thanks again for letting me know!

@jasonmunro commented on GitHub (Jul 26, 2016): @ulfgebhardt, thanks for the feedback! Currently the code does just what you suggest, it checks for the old/new formats and converts them to the newer format on user save/config generation, and the hmac signature check tries both the old and the new keys when validating an encrypted string. Technically, I don't have to remove the legacy support, and I could seamlessly update the user settings on login if the old format is detected without too much effort (or the user even knowing about it). Honestly, I picked a 1 week time frame because I did not think it would be problem for anyone. Now that I know it is, I have no problem delaying the switch over, or even maintaining legacy support using a version number perpetually. Thanks again for letting me know!

kerem commented

2026-02-25 21:34:06 +03:00

Author

Owner

@jasonmunro commented on GitHub (Aug 19, 2016):

I have preliminary version support in place, and my new plan is to delay this change until we get serious about releasing a first version. Closing this in the meantime.

@jasonmunro commented on GitHub (Aug 19, 2016): I have preliminary version support in place, and my new plan is to delay this change until we get serious about releasing a first version. Closing this in the meantime.