• 10.0.0 - 10.0.26
    541 201 9965 Email Website
  • Contents

    Home > Security and Tech > Encryption


    Changing the Encrypt Key

    We strongly recommend you change your Encrypt Key at least every 90 days. This must be done through the Change Encrypt Key page within the admin console, so that the software can update encrypted records with the new key information.


    Before attempting to change the Encrypt Key, follow these steps: 

    1. Ensure the IIS Application Pool user account (typically IIS_IUSRS) has been given read/write/modify access to the folder in which the web.config file is stored.

    2. Decrypt the web.config file. Choose Site Setup Wizard from the Configuration menu, then toggle the Encrypt the Web.Config to NO.

    3. Backup your database and store the backup in a secure location.

    4. Backup web.config, connectionstrings.config, and appsettings.config files and store them in a secure location. These files reside in your root web folder.


    Once you have completed these steps, follow these steps to change the Encrypt Key:


    ​1. From the Configuration Menu, choose Change EncryptKey. The Change Encrypt Key page appears.


    2. Choose "Yes" beneath the "Would you like to change your Encrypt Key?" label. When you do so, a section appears which enables you to enter Encrypt Keys, as depicted below:



    These fields enable you to practice security best-practices and to conform to PA-DSS requirements, which include Dual Control and Split Knowledge of cryptographic keys.


    3. Enter Encrypt Keys


    One person should enter a value into the Primary Encrypt Key field, then, as confirmation, enter the same characters into the Confirm Primary Encrypt Key field.

    A different person should enter a value into the Secondary Encrypt Key field, then, as confirmation, enter the same characters into the Confirm Secondary Encrypt Key field.


    Primary and Secondary encrypt keys combined must be at least 8 characters in length, and should not contain special characters (enter only letters and numbers).

    4. Click the Save button.


    The process may take some time to complete. Do not stop the process before it has finished.

    Encrypting the Encrypt Key

    The following provides notification of important changes to the way that the Encrypt Key (also known as the Data Encryption Key, or DEK) is itself encrypted in AspDotNetStorefront 10.0.0 - 10.0.23.


    When a new site is created, the following state exists.


    The string "TBD" exists in the AppSettings.config file:

    <add key="EncryptKey" value="TBD" /> 


    The KeyEncryptionKey value = "" (empty string). This is a GlobalConfig Parameter value stored in the database. 


    The application detects the "TBD" EncryptKey value and forces the merchant to generate a new EncryptKey (DEK) on the first pass, which the must be entered directly into the AppSettings.config file. This is a very temporary key and your site will not run until you change "TBD" to something different.


    This action allows the admin console to function, at which point the merchant uses the “Change Encrypt Key” process from the admin console as described above.


    When the admin user clicks the Save button as described above, the 'change encrypt key' process generates a new Tertiary Encryption Key (TEK) and saves it in the AppSettings.config file on Server A. The AppSettings.config file is encrypted with DPAPI.


    The process also randomly generates a 64-bit Key Encryption Key (KEK), encrypts it using AES128 using the TEK and saves the result in the GlobalConfig table in the database on Server B. This cannot be decrypted or unmasked and is never displayed in the admin console.


    The DEK is encrypted using the KEK. ​



    There should be no call to transmit your encryption key (KEK) and under no circumstances must you transmit, except 

    through the use of strong cryptography and encryption techniques with at least a 128 bit encryption strength (either at the transport layer with TLS or IPSEC; or at the data layer with algorithms such as RSA or Triple-DES) to safeguard cardholder data during transmission over public networks (this includes the Internet and Internet accessible DMZ network segments).


    Print This Article
    Email This Article
    Previous Article
    Next Article