iv is updated when the attribute's value hasn't changed #216
Comments
|
@moliver-hemasystems Can you please provide more info? I would think that if the IV is being updated without updating the ciphertext, you wouldn't be able to decrypt the attribute. Is this the case? |
|
@saghaulor We were previously seeing this with empty values, but I tested it with the encypted attribute populated and it's updating the ciphertext. So when the value being set on the model is the same as the previous decrypted value, it's still creating a new encrypted value. The auditing gem then records the change because the ciphertext is different now, but when we display the audit history it looks like it was changed to the same value because the decrypted text is not actually different. I would think that if the new unencrypted value matches the current decrypted value, it would be better to skip encrypting the new value. That way on a post without any changes the model doesn't actually save, the rails timestamps and lock versions don't need to change, and auditing and other hooks don't need to run either. |
|
Thank you for reporting this @moliver-hemasystems I understand the problem and I am investigating a solution. One problem with not changing the ciphertext when you update with the same value is that you prevent the ability to re-encrypt. Re-encryption is useful when you want to do a key rotation, or when changing your current crypto implementation. I'm exploring how we might still conditionally allow an update to the record when the unencrypted value hasn't changed, so as to allow for re-encryption. However, at this time I do not have a solution that is complete or satisfactory. |
|
Could this be related to this issue? https://stackoverflow.com/questions/47422328/attr-encrypted-updating-all-encrypted-fields-although-i-only-changed-one |
|
Yeah, this sounds like the issue I was having, just with a different change history gem. I understand the desire to rotate the keys automatically, but I could also see it as something that should be explicitly called by method or enabled via flag on the model in order to have happen. I'd honestly rather be batch rotating keys on a schedule than having it automatically rotate on every save just so I could have a cleaner change history. |
``` user = User.new(name: 'hi') user.name = 'hi' ``` That code would generate two different ivs. At first look that is not an issue, but when using attr_encrypted combined with ActiveRecord this could impose some issues. Like extra writes to the db. Also, marking some attributes as dirty, when they were actually not changed. [fixes attr-encrypted#216]
|
@saghaulor Any updates on this issue? or any work around to skip re-encrypting when the unencrypted value has not been changed? |
I've run into an issue where a user submits a form without updating any fields, even though the value we encrypt isn't changing when we pass it into assign_attributes or update_attributes, the iv is still updated.
Normally, I wouldn't consider that a problem, except that because the iv gets updated, the updated_at timestamp is updated and our record auditing gem records a new audit, leading the users to think something changed on the record even though nothing has.
We're using version 3.0.1 of the gem and version 4.2.6 of Rails.
The text was updated successfully, but these errors were encountered: