Password2 3DES deprecation starting from Vancouver Patch 1 release *** Content of this article is applicable from Vancouver Patch 1 release or higher. Password2 3DES deprecation can only be opted in once your instance is Vancouver Patch 1 or higher.*** Overview ServiceNow provides the Password2 field type. This field type is used to encrypt its input before storing it to the database. In Pre-Rome versions of ServiceNow, Password2 fields used the DESede/3DES algorithm to encrypt and decrypt the stored data. We’ll call these “legacy” password2 fields. In Rome and later releases, Password2 fields primarily use the Key Management Framework, which uses the newer AES algorithm. However, there are some configurations and fallbacks in password2 logic that can still use the 3DES algorithm for encryption and decryption. Beginning in the Vancouver P1 release, ServiceNow provides the ability to remove 3DES algorithm usage completely from legacy password2 fields. Because there are some use cases to continue 3DES algorithm usage, this deprecation is inactive by default. The details of these use cases are found in the next sections. To deprecate 3DES completely on your instance, you must review your instance’s workflows and business logic. Legacy password2 fields A legacy password2 field (Field with attribute is_legacy_password2=true introduced in Rome) relies on the 3DES algorithm if no package level KMF password2 sub-module (key) exists for that field’s scope. After full deprecation of 3DES has been enabled, these fields will start using KMF based encryptions. If you have a use case that relies on these fields for any data transfer across other instances, you need to use KMF key exchange. Things to consider before deprecating 3DES Consider the following when deciding to deprecate 3DES on your instance: Using password2 encrypted text cross-instance (between two ServiceNow instances)Having password2 fields that accept input of length greater than 125 characters If any of these points are applicable to your instance, review the information in KB1531118 before upgrading to a newer release. If you do not opt for complete 3DES deprecation for password2 before Yokohama release, then please be aware that: Your instances will be opted-in by default for complete 3DES deprecation for password2 with Yokohama release upgrade.Password2 3DES data migration job will be triggered during upgrade to Yokohama and there is feasibility for customers to re-initiate data migration on-demand in Yokohama release version. Consequences of not enabling 3DES deprecation: Failure to opt-in to 3DES deprecation will mean your instance is not compliant with NIST guidelines. You can improve the security of your password2 data by migrating to an alternative cryptographic solution. Additionally, your instance is using a static cryptographic key. If you opt-in to 3DES deprecation for your password2 fields, you will avoid the risk of using the static key for cryptographic operations. What to expect after 3DES deprecation Below are the behaviors you should expect after enabling 3DES deprecation: Once 3DES deprecation is enabled, password2 fields will continue to support decryption of 3DES encrypted data. Any update to the existing value will remove 3DES encrypted text and replace it with the text encrypted by respective KMF sub module (key), using cryptographic algorithm specified by the module (e.g. AES). For more information, see What is the Key Management Framework.Existing 3DES encrypted data in password2 fields will remain as-is until that value is updated by the user or workflow or by password2-data-migration in Yokohama.New password2 record entries will use KMF sub module (key) for encryption and decryption.The “Complete Deprecation” enablement option will not use 3DES for any legacy password2 fields. Enable 3DES deprecation Once you have decided to continue with deprecation, there are a few actions to take to successfully deprecate 3DES in password2 fields: Execute the required script to validate the prerequisites required for 3DES deprecation.Scan your instance for uses of 3DES in password2 field types.Enable deprecation in System Security.Complete the steps to fully deprecate 3DES in password2 field types. Each step to be performed is explained in the following sections. Execute the required script As a prerequisite, 3DES deprecation requires you to execute a mandatory script (attached) on your instance. Run the Validate_Password2_3DES_Prerequisites.txt script in the Scripts – Background module to check if all the required configurations are valid for 3DES deprecation for password2. If any of the configurations are not valid on the script execution, contact Customer Support. Scan your instance for password2 field types: Note: No action is required on releases before Vancouver Patch 1. Run a scan to find password2 fields that have 3DES ciphertext in your instance. The scan will list all the table or fields where it finds fields in 3DES format. After reviewing the results of the scan, review considerations to take before upgrading Navigate to All > Instance Scan > Suites.In the Suites list, select Password2 Fields Security AssessmentIn the Suites record, select Triple DES Usages in Password2 Fields from the Suites related list.Click on the “Execute Suite Scan” button. When the scan is complete, select Go to Result to view the Scan Result record. In the Scan Result record, the Scan Findings list displays a list of impacted password2 fields (see screenshot below) Select the Check Version field in the Scan Findings list to navigate to a record (sample record is shown in below screenshot).Review all findings of the scan: Find all tables or field lines in the results containing potential records in 3DES format.Enable ‘Show XML’ to find lines with the format of <attributes>is_legacy_password2=true</attributes>. This means that it is set to be in legacy password2 format or at least it may be.Open the table for that entry. If the table has no entries, there is no impact. If it does, then choose an entry and open them in separate tabs. Enable ‘Show XML’ for each entry and look for the specific field you had found in the dictionary entry. Compliant entries will have a format of <field>SYS_ID1ENCRYPTED_DATA</field>, which indicates that the field is KMF encrypted and should have no impact. The sys_id between the symbols will match a record in [sys_kmf_module_key], to which you can then review the Algorithm (TDEA is 3DES, AES is compliant) and review if it is compliant or not. Repeat steps D and E until all entries are evaluated and determine if any noncompliant entries impact your instance. Now, if you have upgraded to Vancouver P1 or higher release and planning to opt-in 3DES deprecation for Password2, review this KB1531118 Note: Custom fields discovered by the scan must be modified to remove the use of the GlideEncrypter API. For details on alternatives you can use see KB1320986. Enable 3DES deprecation in System Security (UI deprecation steps) Elevate your role to security_admin to see the Security Compliance module.In your instance, go to System Security -> Security Compliance -> Password2 Triple DES deprecation. Choose complete deprecation. Note: Partial deprecation is no longer supported from Yokohama release version. You might see this option in lower release versions but it is not recommended to use. Steps to complete a full deprecation (manual deprecation steps) NOTE: Deprecation is automatically enabled on instances with Yokohama or later and therefore is not required for these releases. Enabling complete deprecation removes the usage of 3DES for all the password2 fields in your instance. If all the prerequisites are met, then there will be no configuration or scenarios where 3DES will be used in password2 fields. In the System Properties [sys_properties] table: Set glide.password2.legacycode.disabled=true. Setting this system property value to ‘true’ effectively disables the legacy code responsible for utilizing 3DES encryption, except for legacy fields, which will continue to rely on 3DES encryption.Set glide.password2.honor.attributes=false. Setting this system property value to ‘false’ ensures that Password2 does not rely on 3DES encryption for legacy configured fields, allowing for a complete transition to alternative encryption methods. NOT RECOMMENDED to set to true. FAQs Q1. What are the 3DES deprecation timelines or roadmap? A1. Customers will be provided the facility to opt-in to complete 3DES deprecation by evaluating/fixing their use cases until Xanadu release, till March 2025. In Yokohama release Password2 fields will be automatically enabled for complete deprecation and data migration facility will be provided to the customers. From Zurich release, planned for Sept 2025 onwards 3DES will not be supported by ServiceNow platform. Q2. What are actions to be taken post opt-in of the complete 3DES deprecation or how to ensure that deprecation worked fine on instance? A2. Ensure your functionality related to Password2 fields work as expected and new encryptions are in KMF format. Example KMF encryption (new) format: d74ba48dc3ba3550a1747fc6050131e61hwxhtk0X4fczsG-pM8uQ_A==NXPr_zX0Cdgn4DK_x7y3z1zVTCWZ_29JJV_NYh4= Example 3DES encryption (old) format: MN4oftawzjfEmLYz/5mH98Y2fOQDvybzXQVsaF9qagEpGMXYy+meoA== Q3. Is there support for rollback of 3DES deprecation in password2 fields? A3. Customers can toggle the 3DES deprecation flag (Data is not rolled-back with this change). For any further queries reach out to Customer Support. Q4. What is a legacy password2 field vs a non-legacy password2 field? A4. Legacy password2 fields are those that were encrypted via TDEA or other older encryption methods that are aligned with 3DES. Normally they are less than 125 characters long and the format of the data in the field will be encrypted data. A non-legacy password 2 field leverages KMF encryption which is a core part of the platform since Quebec but has become more interconnected since San Diego/Tokyo. The format of a non-legacy is different and follows this format. The example below assumes the password2 field is "client_secret": <client_secret>SYS_ID1ENCRYPTED_DATA</client_secret>. Q5. How will the contents of password2 fields be affected by deprecating 3DES encryption? A5. If you opt in to the deprecation, two property control flags are added to the records. New password2 records will be encrypted with AES instead of 3DES. Old records will remain in 3DES until updated, after which they will be encrypted with AES. The Yokohama release will introduce functionality that will allow to migrate all password2 fields directly to AES rather than waiting for the need to retype the data. In Zurich, records which have 3DES data will not be supported and will require you to retype the data. Q6. Does this deprecation affect password2 system properties as well? A6. No, these properties are handled differently. The encryption of password2 system properties are part of ServiceNow’s continued deprecation efforts in Washington and will continue to roll out with Xanadu and Yokohama. Q7. Will there be a tool in the Yokohama release of ServiceNow that converts existing 3DES encrypted fields to be AES encrypted? A7. Yes, an auto migration tool will run post Yokohama upgrade to convert existing Password2 3DES encrypted data to AES encrypted data. Q8. Should I take every action that the executed security script recommends? A8. The suite for the scan is content agnostic and will make generalized recommendations on actions to take to prepare your instance for password deprecation. However, if you haven't heavily customized the instance, have not changed the out of box settings for Resource Exchange or the system properties listed in the prerequisites, then you should already be in a good state for deprecation and can opt-in with minimal to no impact.