I have users who log in, AES password gets set, its decodes just fine, then all of a sudden a few days latter, the AES password starts decoding to gibberish. If I delete the row in the AES table, it gets recreated just fine.

Comments

agerson’s picture

Category: bug » support
Status: Active » Closed (fixed)

Wait, I bet have found the culprit: "The keyfile /Library/WebServer/... is not writable. This module needs to be able to write to this file to update the encryption key."

easyfit’s picture

Hi agerson,

Let me know how it goes.

agerson’s picture

Status: Closed (fixed) » Active

Well, its still happening. Any ideas?

Thanks.
Adam

easyfit’s picture

If the passwords are being decryped to garbage then something has to have changed in how they are decrypted from how they were encrypted (and not changed in the AES settings interface since that would update things correctly, but in some other way).

I think the easiest thing to try is to switch temporarily to using database storage for your encryption key, and see if that makes any difference.

A more exhaustive bug tracking attempt would be to write down all the AES parameters as they are when things work, and match them up with the AES settings when it stops working. That way you might be able to see what it is that change and then we can start trying to figure out why. I would also write down at least one of the encrypted passwords (the encrypted string that is, not the actual password) just to see that it isn't the actual encryption strings that change for some reason.

agerson’s picture

I changed it to database storage and it happened again today. So strange. I will continue to investigate.

easyfit’s picture

I'm sorry to say that I have no idea what could be causing this for you, but I've got a new version out and you might want to try it with the phpseclib implementaton since phpseclib doesn't allow changing anything except the key, which obviously rules out a lot of variables.

easyfit’s picture

Status: Active » Closed (cannot reproduce)