Username and password must be provided. The “Show Password” checkbox displays the password. This is a security issue. Otherwise, what other options can be used to not display password in the REST objects.
I know the password can be passed in on the fly, however, this doesn’t solve the problem, and I believe the newly release encrypted password capability will not work with these objects.
Is this checkbox really necessary? Or what other options in securing passwords here are available?
I see there is no response, so let me request the following:
Please remove the “Show Password” checkbox.
This should be a very simple change. Actually, I honestly can’t fathom, given the nature of this tool, why you would have it there.
Katalon have recently introduced encrypting text and the proxy password, this will be in line with hiding plain text passwords, and should be a trivial change.
Nick,
We understood the situation. This request will be put into our backlog for further investigation. Thank you so much for the suggestion.
I want to tag along here with a related problem (basic auth and encrypted passwords) - but can move this into a separate post if desired
I cannot find any way to use encrypted passwords from execution profiles in basic auth on web pages.
Approaches tried:
- Encrypt https://user:pass@dev.site.com in the execution profile. navigateToUrl(GlobalVariable.url) will not decrypt the password. (passing the url unencrypted works, but then I must save the password unenctrypted)
- Authenticate(url, user, pass) - this also will not decrypt the password
- Write a Custom Keyword and build the user:pass-URL myself using setEncryptedText(Element, text) , but in this case there is not Element to write into.
Version tried: Windows Katalon Studio, 5.4.2
The unencrypted password on the REST objects is a huge flaw.
For my own case, simply removing the “Show Password” checkbox will satisfy my immediate requirement. This is such a simple change, but I can understand if you want to develop a more robust solution
Why should it be done?
Katalon is a very good tool, and is used by teams of people. The “Show Password” approach to passwords is typically used for single accessible configurations (like a mobile phone). If the Test source is available, then it’s a trivial matter for anyone to “show” the password. A huge security breach. In fact, this breach has meant that we have not been able to use Katalon for some of our testing and have had to revert to other methods. A real shame, because I think it’s a great tool.
An employee of our company bumped on this topic too.
This behaviour is still existing (KSE 7.7.0) and an clear security error on our point of view.
Its interesting to see that the unencrypted password is only visible on the GUI. Within the data (nameOfFile.rs) there is only the encrypted Value:
<value>Basic [encryptedValue]</value>
Please remove this checkbox.
the same ‘checkbox’ you have on plenty cloud services.
provided you are the entitled user to modify-it, you can see it.
how is this an issue? is this password exposed into the CLI execution log?
you are running katalon on your own machine … not on www
do you give other users access to your machine and in addition to your own account on that machine?
kindly submit the same request to any other provider for the toys you use, e.g google.com, and come back with the response you get
(yeah, i just exposed to the www that i have two katalon accounts, hack me)
as for … ‘encrypted in .rs file’ i think you speak about this?
suuure … it’s encrypted …
it’s just base64 encoding, feel free to use any online decoder to decrypt mine.
I’m with @anon46315158
This is NOT an issue as it’s being portrayed. If the devs choose to provide a checkbox, it’s merely to protect you from you - no one else.
Basic Auth, unless it’s used over an https transport is NOT SECURE.
The problem with changing the Katalon UI in the way that has been suggested, is that naive users may think BA provides security that is not actually there. THAT is not only misleading, but would lead to further complications and misunderstandings.
Here’s the relevant IETF section:
If there were a vote, I would not vote the devs spend any time on this.
@Russ_Thomas i voted with :
: on your post … which should be read as ‘down-vote’ for this feature to be taken into consideration
meah … lack of forum features 
Alternative solution should be the option to use an Encrypted Text Variable: How to use encrypted text in web service requests (functionality needed)
