Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C
Core
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 976
    • Issues 976
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • Core
  • Issues
  • #2258

Closed
Open
Opened Nov 09, 2020 by seamuslee@seamusleeDeveloper

Re-Thinking our Crypto implementation

Motivation:

We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted within the database e.g. Payment Processor Passwords.

Problems:

  1. Not easily able to determine what Crypto method has been used (Mcrypt or Base64 encoded only) to save the SMTP password.
  2. Not easily to assess which extensions have had fields encrypted (e.g. know that Sparkpost has encrypted their API key but other than that unsure)
  3. Relies on CIVICRM_SITE_KEY (which is maybe over-using that value).
  4. Linked to Item 2, is there is no way for the API/DAO/Extensions to know what fields have been encrypted so to decrypt code appropriately.

Potential ideas:

  1. Create a setting which stores the encryption class and use a factory / hooks to allow for extensions to customise which crypto library to use within CiviCRM
  2. Have a hook / use some level of meta data to determine if a field is to be encrypted

Discussion Questions:

  1. Should we completely break CRM_Utils_Crypt class as we re-work the encryption within the app
  2. How should we handle switching between Crypto libraries?
  3. Should extensions be able to use their own Crypto Library whilst leaving rest of the App to use a system specific Crypto?
  4. Do we want to allow for civicrm.settings.php defines / environment variable overrides for encrypted fields / data points?
Edited Dec 17, 2020 by totten
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/core#2258