CA Release Automation Recommendation for clear Text Password and autocomplete on sensitive fields

book

Article ID: 207165

calendar_today

Updated On:

Products

CA Release Automation - Release Operations Center (Nolio)

Issue/Introduction

We can see that on developer console of browser the password is visible as clear text and auto-completion option on sensitive fields like username and password. What is the product CA Release Automation recommendation for the same.

Environment

Release : 6.7

Component : CA RELEASE AUTOMATION CORE

Resolution

The recommended approach to all these financial and non-financial customers has been from the product side to use SSL with SSO:

  • A large automobile manufacturer in North America uses CA Release Automation (Nolio) for managing over 10,000 deployments every month.
  • A prominent IT services provider to the state services in Western Europe uses CA Release Automation (Nolio) for managing end-to-end deployment request lifecycle, encompassing interactions with ServiceNow and JIRA, to manage over 2000 deployments per month.
  • A major bank in Asia supports application releases across hybrid and public cloud using CA Release Automation (Nolio).
  • A financial services provider in Australia manages 100% of its application deployments in the cloud using CA Release Automation (Nolio).
  • One of the top 5 financial services providers in Europe plans to manage 40% of their application deployments in cloud, across three regions, using CA Release Automation (Nolio).

Recommendation

Scenario: Clear Text Password available on browser Console

  1. It has been highlighted that a browser developer tool is revealing a password in clear text and is accounted as a vulnerability, if in case the browser is compromised. Please be advised that a client side browser exposure or clear text password communications requires end to end encryption in a way which can only be deciphered using client/server application and encryption algorithms, which is already a part of the solution.
  2. A browser developer tool is an advanced feature which is meant for website builders and developers to edit webpages or to diagnose problems by temporarily holding all the data which was sent and received for a given page load. This includes things ranging from passwords, session keys, JavaScript activity, hashes, CSS etc. Also, browser is acting as a client application and is decrypting the traffic and communication exchanged with a server application thus showing everything in the developer tool.
  3. We should understand that network security, endpoint security and OS and application patching act as a first line of defense and have in-depth focus towards preventing a compromise of any endpoint machines; otherwise, below mentioned security parameters can be leveraged as an additional layer of defense, but each one of them have their  own pros and cons which should be considered while having them applied in an environment:
    1. Follow security standards like disabling of un-necessary services, network ports and application features as well as restricted usage of internet and applications: Developer tool is majorly meant for Web developers and diagnosing issues and thus should be enabled as per use cases. As such, the standard security practice is to keep Developer Tool disabled in production instance of applications in similar to right clicking on banking applications/login forms
    2. Two factor authentication: Two factor authentication is an additional layer of security and information protection which has become pretty well known and is being employed by enterprises like Google, Microsoft etc. to secure enterprise assets from malicious actors. Two-factor authentication is highly recommended for application passwords that may be prone to attack, and can provide a higher degree of protection compared to other methods
    3. Hashing: Hashing can be used to mask passwords; however, it has its own limitations which can be facilitated by an attacker and that is the reason if it mostly used for verifying an integrity of a message or a file rather than a password. One of the common limitations is a quality of password. If the user has chosen a simple or short password or a common password like OS password, then it matters little which hashing algorithm the security architect has chosen. Even if the attacker cannot directly deduce the password, just using a cryptographic hash function to convert a password into a shorter fixed-length string leaves the password vulnerable to attack

 RA solution follows all the mandated global security guidelines; however, with the additional suggestions given in the email and the implementation of options especially 3a / 3b will help customers with the best possible mitigation and reduction of the risk to the lowest possible. The best way to protect an enterprise is to stay up to date and know and block common vulnerabilities with a first line of defense. 

Scenario: Auto-complete is enabled for sensitive fields

In our review we find it as false alert, RA has turned off auto-complete the screen shot shared is from the browser password remembrance utility.

The password field in RA is using autocomplete="new-password". You want to prevent auto-filling of password fields, you can use autocomplete="new-password". Modern browsers have stopped auto-filling <input> elements with autocomplete="new-password" for this very reason. Please refer to MDN reference document for more details.

The autocomplete="new-password" is new value, which does exactly what autocomplete="off" achieves in most of the modern browsers. The suggested value of "off" is not acceptable in modern browsers. Please check the browser compatibility matrix for autocomplete.