Summary: | Use pbkdf instead of the default openssl1 for Crypt::CBC | ||
---|---|---|---|
Product: | Koha | Reporter: | Jonathan Druart <jonathan.druart> |
Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | dcook, m.de.rooy, martin.renvoize |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34697 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 40348 | ||
Bug Blocks: |
Description
Jonathan Druart
2025-07-11 12:35:56 UTC
Sounds good. Of course, it means that we'll have to re-encrypt all the database contents. But that could be a blessing in disguise! At the moment, we just *know* which fields are encrypted based on the code, and how they're encrypted, and we have a single "encryption_key" in koha-conf.xml. But the more time goes on the harder this is going to get to manage. We should update the database schema to store JSON metadata alongside the encrypted values. This is a normal practice these days. I'd suggest things like "kid" (or key_id), "algorithm" (e.g. AES-256-CBC in the case of Koha::Encryption currently), "pbkdf" (e.g. opensslv1 or pbkdf2), "iterations" (e.g. 10,000 - current default value of Crypt::CBC). In theory, we'd want IV and salt as well, but Crypt::CBC stores them as headers in the ciphertext/encrypted value, so we probably don't need to worry about those yet. Instead of "algorithm", we could break it down into "cipher" (e.g. AES), "keysize" (e.g. 256 bits which is a default value from Crypt::Cipher::AES), and "mode" (e.g. CBC). I'd then say we should add an attribute to "encryption_key" in koha-conf.xml. Since we don't currently programmatically update koha-conf.xml, I'd say we just store a value of "default" for kid for existing data. Once we've updated the database schema to reflect the reality of the encryption options being used, we can then do scripted re-encryptions of the data. By storing key ID, we also create the opportunity to rotate encryption keys and add the ability to use separate keys for separate tasks. (In reply to David Cook from comment #1) > We should update the database schema to store JSON metadata alongside the > encrypted values. Recently, I've been involved in a number of Keycloak system upgrades which have involved re-hashing of passwords, and storing the crypto options next to the values is how they're able to do it. It's also how I was able to work out some bugs in their re-hashing process heh. Noticed that I've been set as the assignee but I don't think that I'll have time to work on it at this time. |