[Bug 32078] New: We should have an easy way for an administrator to update the encryption keys
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Bug ID: 32078 Summary: We should have an easy way for an administrator to update the encryption keys Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org CC: robin@catalyst.net.nz We now use encryption on a number of Koha database fields and utilise a key sorted in koha-conf.xml.. However, we have no easy way to change key should that key be leaked or found to be to simple to crack. We should add a script to allow updating of our encrpyted values from one key to the next... (or alternatively, perhaps we should allow for an array of keys in our config and update the encryption on access whenever we find an prior key is in use?.. I believe this is what we did when we upgraded from SHA to BCrypt for user passwords). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28998 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Command-line Utilities |Architecture, internals, | |and plumbing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=30649 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com, | |kyle@bywatersolutions.com, | |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Good call on adding functionality for key rotation! The tricky thing is that we don't currently have a way of noting which key was used to encrypt which field. In master, I'm only seeing Koha::Encryption used in Koha::Patron, and within Koha::Patron it's used in the function "encode_secret". So we could put a "key_id" or "encrypt_key_id" field in the patron table row, and then look up the key that way. Then the re-encryption tool could take a source ID and a destination ID for doing the re-encryption. If we wanted to automate it more, we could add additional metadata to the keys to indicate something like "revoked", "preferred", or whatever. But I think recording the key ID would be the first step. (You can see this all over AWS with KMS IDs.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor@tuxayo.net --- Comment #2 from Victor Grousset/tuxayo <victor@tuxayo.net> ---
The tricky thing is that we don't currently have a way of noting which key was used to encrypt which field.
As long as there is one key at the time, it's not needed. The update process should be one transaction to guaranty that though.
However, we have no easy way to change key should that key be leaked or found to be to simple to crack
It's generated so cracking shouldn't be an issue. As for a leak, yes a webserver misconfiguration or a vulnerability in Koha or another app on the same server could expose the config file while still having the DB unleaked. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Victor Grousset/tuxayo from comment #2)
The tricky thing is that we don't currently have a way of noting which key was used to encrypt which field.
As long as there is one key at the time, it's not needed. The update process should be one transaction to guaranty that though.
That's not going to scale. If you have a large number of amount of data, that's going to be slow, require downtime, and potentially put unnecessary load on the database server. Large transactions are rarely a programmer's friend. That said, it would be easier in the short-term and for small databases. So certainly better than nothing.
However, we have no easy way to change key should that key be leaked or found to be to simple to crack
It's generated so cracking shouldn't be an issue. As for a leak, yes a webserver misconfiguration or a vulnerability in Koha or another app on the same server could expose the config file while still having the DB unleaked.
Theoretically we might learn of new computing methods that mean the generated key is too weak, and we need to employ a different algorithm. What Martin is saying is that there's no way to currently re-encrypt using a stronger/unknown key. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Bug 34976 - Encryption keys should not be shared between modules -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #1)
In master, I'm only seeing Koha::Encryption used in Koha::Patron, and within Koha::Patron it's used in the function "encode_secret".
Unfortunately this is no longer true. EDI and Acquisition started using it too. See the other report. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40349 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org