Passing form value w/o being logged in the clear, e.g. password

Get Help
,
1

I have a specific application that prior to running, needs an encrypted directory mounted via encfs/gocryptfs. One of the requirements is also that the password typed in by the user does not show up as clear text in any logs/files.

I’ve tried using the widget: "password_field", but not only am I having a hard time figuring out how to pass a forms attribute variable w/o it showing up in script.sh, but the value is also clear text in user_defined_context.json output file.

Has anyone had this type of requirement before, and if so to what success? (e.g. user enters password in the interactive app form)?

Bruce

2

Set the cacheable field to false and we’ll stop writing it to user_defined_context.json.

How you can safely/securely pass it to a script - I’m not sure. I haven’t run into this use case. But it would seem you’d need to pass an encrypted value (encrypting on the OOD server) and decrypt it on the other side (during the job’s execution).

https://osc.github.io/ood-documentation/latest/app-development/interactive/form.html?highlight=cacheable

3

Jeff,

Does this behave differently when launching from a user/dev sandbox app? Unfortunately the field is still in the json when running this way.

Here is the form.yml entry:

  decrypt_pw:
    widget: "password_field"
    label: "Decryption Password"
    cacheable: false
    help: |
      "Password to Decrypt CMS Data"

In the html source I see:

<div class="form-group"><label for="batch_connect_session_context_decrypt_pw">Decryption Password</label><input class="form-control" type="password" name="batch_connect_session_context[decrypt_pw]" id="batch_connect_session_context_decrypt_pw" /><small class="form-text text-muted"><p>&quot;Password to Decrypt CMS Data&quot;</p>
</small></div>

This is the user_defined_context.json that is generated:

{
  "cluster": "sapelo2",
  "version_rstudio": "Rstudio/2022.07.1-554",
  "version_r": "R/4.2.1-foss-2020b",
  "bc_num_hours": "1",
  "num_cores": "4",
  "group": "Default",
  "queue": "batch ",
  "memtask": "4G",
  "features": "",
  "gres": "",
  "bc_email_on_started": "0",
  "decrypt_pw": "12345"
}
4

Sorry you’re right, I think it’s in 2 files. One we use for a cache (it shouldn’t be there anymore) and another which is in the the CWD of the job (what you’re linking here).

I don’t think we’ve had this use case where you have sensitive data in the form, so we’re not sanitizing it anywhere.

IDK how to solve this problem or have another system solve that trust. I’m wondering if the scheduler can somehow use the implicit trust here. You have the job allocated by user X and user X can decrypt/mount the file system. So somehow getting the scheduler’s trust (the job that’s allocated) to extend to this file system. Could be impossible, just an off the top guess here.

5

Thanks Jeff, I will look into some other options for now.

6

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.