Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-9076

Fix Criteria Masking on Lookups with encrypted fields

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.0-m3, 2.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Lookup
    • Application Requirement:
      Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Pending Review
    • Include in Release Notes?:
      Yes

      Description

      1) When a masked data field is used for a lookup criteria KRAD displays the mask and puts the field into read only while KNS leaves the field editable and only displays the mask if a value is given (see KNSLookupCriteria.png and KRADLookupCriteria.png). Personally, I prefer how KRAD implements it as under KNS you can brute force guess the value of the masked field until the desired record is displayed (see KNSBruteForceGuess.png).

      2) When a masked datafield is returned from a lookup the encrypted string is displayed in KRAD instead of the mask (see KNSMaskReturn.png and KRADMaskReturn.png). The search results are displayed correctly in both cases. Subsequent lookups do not pass the encrypted (supposently masked) value correctly and the same record won't be found with KRAD unlike in KNS where it works fine.

        Attachments

        1. KNSBruteForceGuess.png
          KNSBruteForceGuess.png
          104 kB
        2. KNSLookupCriteria.png
          KNSLookupCriteria.png
          111 kB
        3. KNSMaskReturn.png
          KNSMaskReturn.png
          113 kB
        4. KRADLookupCriteria.png
          KRADLookupCriteria.png
          103 kB
        5. KRADMaskReturn.png
          KRADMaskReturn.png
          97 kB

          Issue Links

            Activity

            Hide
            cniesen Claus Niesen added a comment -

            Damon, your concern are quite valid for the (1) issue. The changes resulting from (2) better security should not be noticeable for the end user though. The synthetic key would never be displayed to the user.

            The tax id's uniqueness would be guaranteed by making it a unique column in the database. The users will also be able to search by the tax id. The difference is that the return links from the lookup would not use the tax id but the synthetic key. This prevents that the sensitive tax id is passed to the browser in encrypted form and thus adds to the security of the data. On the receiving page/document the synthetic key will be used to get the business object and the tax id can now be displayed again (in masked form).

            So the end user won't know the difference. Auditors will be happier about the increased security. The application developers and implementers will have to pay the cost though since the database schema and data needs to be updated wherever sensitive data is currently being used as the primary key.

            Show
            cniesen Claus Niesen added a comment - Damon, your concern are quite valid for the (1) issue. The changes resulting from (2) better security should not be noticeable for the end user though. The synthetic key would never be displayed to the user. The tax id's uniqueness would be guaranteed by making it a unique column in the database. The users will also be able to search by the tax id. The difference is that the return links from the lookup would not use the tax id but the synthetic key. This prevents that the sensitive tax id is passed to the browser in encrypted form and thus adds to the security of the data. On the receiving page/document the synthetic key will be used to get the business object and the tax id can now be displayed again (in masked form). So the end user won't know the difference. Auditors will be happier about the increased security. The application developers and implementers will have to pay the cost though since the database schema and data needs to be updated wherever sensitive data is currently being used as the primary key.
            Hide
            ddorsey Damon Dorsey added a comment -

            Thanks for clarifying for me Claus.

            Show
            ddorsey Damon Dorsey added a comment - Thanks for clarifying for me Claus.
            Hide
            lschultz Lori Schultz (Inactive) added a comment -

            For KC, I was able to confirm with our PM that we don't mask any result fields in KC.

            Show
            lschultz Lori Schultz (Inactive) added a comment - For KC, I was able to confirm with our PM that we don't mask any result fields in KC.
            Hide
            jkneal Jerry Neal (Inactive) added a comment -

            Hi Damon,

            We talked more about this. We think using synthetic keys is what applications should do for security purposes. However, since that requires reworking some database tables, we don't want to require this for the conversion. So we are going to support enabling searching based on a secure field with a configuration option. In addition, we will continue to support encryption/decryption of values on the URL.

            Claus, I think we could add an option to the CriteriaInputField that will allow editing of the field when the value is secure.

            Jerry

            Show
            jkneal Jerry Neal (Inactive) added a comment - Hi Damon, We talked more about this. We think using synthetic keys is what applications should do for security purposes. However, since that requires reworking some database tables, we don't want to require this for the conversion. So we are going to support enabling searching based on a secure field with a configuration option. In addition, we will continue to support encryption/decryption of values on the URL. Claus, I think we could add an option to the CriteriaInputField that will allow editing of the field when the value is secure. Jerry
            Hide
            cniesen Claus Niesen added a comment -

            KULRICE-8050 is required to make the Lookup with masking work property. I.e. when a masked value is returned via a quickfinder, the field should be read only and the quickfinder should displayed and functional.

            Show
            cniesen Claus Niesen added a comment - KULRICE-8050 is required to make the Lookup with masking work property. I.e. when a masked value is returned via a quickfinder, the field should be read only and the quickfinder should displayed and functional.

              People

              • Assignee:
                cniesen Claus Niesen
                Reporter:
                cniesen Claus Niesen
              • Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: