Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-9076

Fix Criteria Masking on Lookups with encrypted fields

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major 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
    • Similar issues:
      KULRICE-10272KRAD Demo Lookups Account name is now editable and not masked.
      KULRICE-12608Lookup Criteria should be functioning even for secure fields
      KULRICE-8271partially masked field can't be masked properly (RQ_PO_0316)
      KULRICE-8412Fields encrypted on URL are not always decrypted when returned to document
      KULRICE-4782forceUppercase and encrypted PK fields are not compatible - unable to perform inquiry
      KULRICE-9474Implement defaulting of attribute security in the metadata based on the presence of an encryption converter
      KULRICE-10308Lookup: Check that masked fields are reset properly with "clear value"
      KULRICE-10461Create Web Tests for KRAD Maintenance Document Masked Fields
      KULRICE-10046KRAD Sample App: Lookup with Conditional Criteria Field
      KULRICE-7688Decrypting/Encrypting hide fields value that are not set as encrypted when click on custom button on Maintenance Document
    • 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.

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

        Issue Links

          Activity

          Hide
          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
          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
          Damon Dorsey added a comment -

          Thanks for clarifying for me Claus.

          Show
          Damon Dorsey added a comment - Thanks for clarifying for me Claus.
          Hide
          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
          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
          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
          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
          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
          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:
              Claus Niesen
              Reporter:
              Claus Niesen
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel