Browser side Drupal Encryption for Password being submitted to block the MITM attack

The following RFE is being closed as not under consideration from IBM. Please see the following for a breakdown of our justifications.

IBM follows a strict set of security and privacy practices, design, and testing outlined in IBM Security and Privacy by Design (SPbD@IBM https://www.ibm.com/support/pages/ibm-security-and-privacy-design) All IBM products provide Security Bulletins provided by CVE ID and Product Name at IBM Product Security Central (https://www.ibm.com/support/pages/bulletin/). IBM is also a leader in security and threat analysis with IBM X-Force publishing a yearly Threat Intelligence Index (https://www.ibm.com/reports/threat-intelligence) base on insights and observation obtained from monitoring over 150 billion security events per day in more than 130 countries.

When we find legitimate product security finding alerts and fixes are published, such as CVE-2023-47722 (https://www.ibm.com/support/pages/node/7087806) which did find credentials in the browser cache which could be read by the local user. Clients that want to maintain a strong security footprint should prioritize maintaining their environments with the latest supported version and fix packs as older out of support version of the software that do not continually get scanned for issues or receive security patches.

For the specific items that were requested in the request for enhancement have been broken down as the following:

1) Encrypt the Password(s) in the Drupal Database at rest

When using the Developer Portal (Drupal) as provided by IBM API Connect, the only account password that is stored in the Drupal Database is the admin which is stored using a salted one way hash so there is no way to retrieve the original string password. All of the other password are not stored in the Portal but handled the different User Registry configurations in API Manager. Any additional customer customizations, configurations, etc. that are not provided by IBM may impact the data stored in the Drupal database is the responsibility of the owner of that environment.

2) Password in Transit

By default all connections with the Developer Portal use Transport Layer Security (TLS). When trying to connect via HTTP to the Developer Portal using IBM provided configuration the connection will get reset to require TLS via an HTTPS. Thus the password is encrypted in transit, using Transport Layer Security (TLS), and is never sent over the network in the clear. If the customer has a requirement that goes beyond the transport level encryption used by the product, they can choose to use an external OAuth or OIDC provider for authentication. The product integration with such providers uses standards-based communications whereby API Connect will redirect the browser to the customer's chosen provider and that provider can enforce additional structures they choose.

3) Comments on Burp Suite attachment Workstation-compromised Man in the Middle Attack (MITM)

If an attacker managed to launch any form of Man in the Middle (MITM) Attack the users login password becomes irrelevant. The attacker can see everything that goes in both direction between the client and server and can manipulate and modify anything that they choose. This includes any request and/or response headers, tokens, cookies, form data, page data, etc. To be able to encrypt the password on the client side in the browser the client and server need to agree on an encryption key which an MITM would have been able to access.

In the example of using Burp Suite, which was creating a sudo-MTIM attack by compromising the browser by setting an intercept proxy. This attack is more aligned with a compromised computer/browser. Any encryption keys being shared between the clients and server for the client encrypt the password would be visible to Burp Suite’s MITM attacker eliminating any perceived security provided by encrypting the value. If the users workstation has been compromised it can also be assumed then that any number of data collection systems could be in place such as keystroke loggers.

4) Third Party Modules

Clients choosing to use 3rd party modules are dependent on the support of these 3rd party modules from the maintainer/creator. Specific Drupal version support of 3rd party modules is up to the module owner/maintainer and not IBM.

IBM does not provide any support additional modules that are not shipped with our product, we do not provide any compatibility testing with modules not shipped with our product.

IBM has never shipped the module Password Encrypt (https://www.drupal.org/project/password_encrypt). Our evaluation of this module was that it is security theatre having security holes in the module itself. It would make security worse and not better. If the client still wants to use this modules they can work with the maintainer to get Drupal v10 support and/or fork the code and update it themselves. This module would not protect from a real MITM attack as described in the above section.