I am building a module that will need to integrate credentials for the 3rd party service in Drupal 8. The module's admin panel should remember the credentials and use them to interact with the service, but still hold them secure. Storing the credentials un-encrypted or exporting them in config with drush cex can pose a threat. How are such cases to be handled in Drupal 8? What is a good way to handle secure 3rd party credentials with Drupal 8?

Details: A module integrating with the 3rd party online service. This service provides credentials, that the user inserts in the module's admin form, and then can use the services. It won't do to hard code the credentials in PHP, and saving them as config in Drupal 8 will result in them being exported with drush cex. So, there is a need to store secure data in the settings, and keeping it from export when config is exported.

  • 1
    I don't think this question is specific to Drupal, but is about storing credentials on servers in general. There is already a lot of info about this on Information Security SE. – Neograph734 May 23 '16 at 9:33
  • The question is fairly Drupal-related because this question is opinion-based within the Drupal community. Traditionally storing credentials in configuration (i.e. in the database) has been seen as secure enough but there are others who disagree and want to split systems/key security away. – mradcliffe May 23 '16 at 10:18
  • Storing in the database is a part of the problem. But then, having the values show in the exported yml files - that even more insecure than just having it int he db. AFAIK, there is no way currently to mark some of the config as 'not exportable' during drush cex / cim. And that really sounds like something that should have been taken care of, but something that I just don't happen to know. – Alexei Rayu May 23 '16 at 10:34
  • 1
    See drupal.stackexchange.com/questions/185536/… and drupal.stackexchange.com/questions/192845/…, those are probably the only options if you don't want to depend on another module (store it in state, not config or have the actual production values provided with config overrides in $settings.php (which could for example read them from environment variables) – Berdir May 23 '16 at 18:29

The key module provides a framework for abstracting key storage from modules. The module provides 2 key providers (plugins) out of the box: config and file. It is possible to implement a key provider plugin for some arbitrary storage such as what the encrypt module provides.

Note that a web site's actual security risk for using a particular key provider depends more on security procedures and infrastructure.

  • 1
    This definitely is a possibility. Would prefer not to use a separate module for this, but may end up doing it, if no better options. – Alexei Rayu May 23 '16 at 14:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.