Secret Text fields
I'd like to get a feel from the community for a SBM enhancement proposal for Secret Text fields. The use case is to be able to turn a normal text field into a field capable of holding secret text or have a separate field type with those properties. Use cases include putting passwords or other sensitive data on a form. The submitter would be able to encrypt the text on the field and be able to specify who should be able to view the secret text - list of users or groups explicitly listed. Certain admin accounts would always be able to view such fields. Optionally, the submitter would be able to provide a password that would be required by the reader if such option is chosen regardless if they are on the "allowed" list. The distribution of such passwords is beyond the scope of such enhancement
Would something along these lines be of interest of SBM customers?
We also have a 'password' field. In Composer, if you create a text field, you need to make it a fixed length type. Then a checkbox will appear for 'Password'. This will show the field as asterisks on the form, and is encrypted in the database. I'm not sure how feasible it would be to make this value appear to some users.
If neither of these options work for you, then you can submit an enhancement on the 'Ideas' page, where other customers can vote on it. https://community.microfocus.com/t5/SBM-Idea-Exchange/idb-p/SBM_Ideas
Is this end-to-end encryption for text fields? If so I'd suggest that even "certain admin accounts" be prevented from viewing the data. The user MUST have the password/decryption key to view the data. No exceptions. As you noted, the distribution of those passwords/keys is outside this suggestion.
If the user is entering an encryption key/password, then the system must store that key/password in order to perform the decryption for admin users. So now both the encrypted data AND the key to decrypt it are in the database. That doesn't sound very secure.
I could see how some people might like a reveal option on forms to reveal text only when needed to deter over the shoulder observation. This concept probably wouldn't apply to web services. But if it did, then we would need an option explicitly reveal the content perhaps by including the field in Limited Fields or something.
Your use case could also expand to tracking who has been shown the contents of the field (which may scale to reports, item and field access). If this were the case, then architecturally I suspect that a specific call would have to be made by the client to request the data from the server (otherwise, the data has already been transmitted to the client regardless of if the user took specific action to look at the data.)
I have had scenarios where the limit of allowed field sections has been a challenge to secure fields when there are effectively more stakeholders than field sections. I could see how something like this could address this challenge in some ways.
It may still be necessary to restrict the actions on the secret text field much like we do other fields via field sections contextualized to states, transitions, workflows, projects and tables (along with options to override things like Read Only, Required,..).
Secret data could not only include PII, but also Salaries, Costs, even people who wish to be anonymous in some way (like an approver), private keys, security tokens, as well as passwords.
And obviously Change History features would have to be adjusted accordingly for such fields.