+5
hi,
We use http connectors to get data from 3rd party API’s and we have the account info (username/password) stored in the database, and use this with process variables in the processflow http connector:
So now, when a user starts the process flow monitor while executing this task, the password is shown in plain text. The domain of this variable is a password control, so why is this shown?
Any idea how to fix this security issue?
Best answer by Anne Buit
View original
+5
Hi Tejo,
When using the 2-tier Windows GUI, the client will be the one to invoke the API call.
Hiding the password in the process flow monitor would not fix the core of this security issue, but the process flow monitor can be hidden by running the application in end-user mode.
The Universal GUI in combination with Indicium completely resolves this problem. Indicium will run the process flow behind the scenes, and the end-user will not have access to the process variables. A similar version of the Windows GUI that can connect to Indicium is also planned.
Alternatively, you can schedule a system flow to take care of the API call. Indicium will then run the flow instead of the Windows client.
+5
Hi Anne,
thank you for the reply, I don’t understand why a simple password question leads to the use of a different GUI or system flows handling the API call. So I have a processflow which needs user input, and then processes an API call. With the Windows GUI, the advantage of the processflow is that I can debug it, with a systemflow only the output/errors are shown in indicium (outside the client).
A simple solution can be, hash the password string. So it’s unreadable in the database but not for the software. It frightens me everytime I see a password as plain text in the database, this should be part of the model, right? It’s an intelligent platform, it should handle password’s properly.
End user mode is something you declare in the configuration file, a user can bypass it.
So looking forward to new developments planned, but I think this is something basic and should be handled by the model.
+5
Hi Tejo,
I completely agree. However, we cannot safely offer the requested functionality in a 2-tier architecture.
Storing passwords encrypted is certainly recommended. Data encryption is a feature already offered by the platform. This feature is not available to the 2-tier Windows GUI. Only Indicium as agent can encrypt and decrypt safely for use in (e.g.) API calls without the client ever accessing these raw data values.
We cannot offer the option to decrypt to the Windows GUI, as this would mean that the decryption keys would be available to the end user. Because of this, the feature to decrypt is exclusive to an architecture with Indicium (a system flow, Universal GUI and eventually Windows GUI on Indicium).
Hashing of passwords and checking hashed passwords is also available in the platform, also to the 2-tier Windows GUI. However, a hashed password can only be used to verify a password. The hash cannot be ‘un-hashed’ to the raw password for use in an API call.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
