Keyword "Input Password" logs given password

I noticed that if you run Robot Framework with log level TRACE, the keyword Input Password does, in fact, log it's values.

I have attached an example test case with demonstrating the problem when you run it

pybot --loglevel TRACE example.txt

I feel this should be fixed ASAP.

example.txt:

*** Settings ***
Library     Selenium2Library

*** Variables ***
${super secret}=    my super secret password

*** Test cases ***
Example
    Open Browser    http://www.google.com
    Input Password    gbqfq    ${super secret}
    Close All Browsers

I actually think the idea of a "super secret" password inside a testing script is a misnomer. Thinking your password is secure in a script is overly optimistic I would say. There is nothing secure about a password stored in RF script and the person running the pybot command, needs to have red access to the script anyways, so the log isn't exposing any information that is not in the script already. The user could simply open up the script and view it.

That being said the documentation for input password does say it doesn't log the password, which as you have identified it clearly does. However that documentation isn't talking about the TRACE loglevel. The TRACE logging you are seeing is coming from WebDriver itself and not from RF, that is in effect what TRACE does. So when S2L calls web_driver it is simply calling "send_keys" which doesn't know if your sending a password or not.

As a work around if you don't want passwords to be logged don't use the TRACE loglevel.

Further with webdriver logging passwords this issue has been raised with the Webdriver team here:

http://code.google.com/p/selenium/issues/detail?id=3442

And they are basically just ignoring it.... So I think the that could possible be done is to implement the typePassword function suggested in the Webdriver bug and submit a pull request to the selenium team. Alternatively it may be possible to temporarily disable TRACE logging when Input Password is called... I don't recall of the top of my head...

But I have to say to that I believe the basic premise of assuming an automation framework should keep secure passwords is simply flawed.

Its worthy to note that, as you highlighted in the screenshot, the password is also visible at level DEBUG. Before distributing the logs, you should use rebot to reprocess the log with a log threshold of INFO if you ran at a level below that.
e.g.
python -m robot.rebot --loglevel INFO output.xml

I agree that having something actually secret in your test scripts is not good. However, we are currently implementing tests to a system, where we have to use actual login credentials. Such is real world. Our workaround currently is to wrap Selenium2Library and provide another keyword for Robot that fetches the login credentials from secure place.

I must thank you for your comments, as it has helped us to identify the root cause (Webdriver) and this helps as to further work around the problem.

I urge you to at least update your documentation regarding Input Password. If you could actually make a workaround, that would be even better.

One thing that briefly came to mind that would maybe fix this issue, is to redirect temporarily Robot's logging to non-existing place while inputting a password. I haven't check if this is, in fact, a feasible approach -- just my two cents.

Continuing previous comment, we ended up to overwrite Robot's logging:

from robot.api import logging
old_debug = logging.debug
logging.debug = lambda *s: s
# a while later...
logging.debug = old_debug

Similar might work with you.

Instead of modifying Robot itself you can set the log level to NONE before putting in the password, and then set it back to the desired level. Seems to work okay and do what you need.

Great idea marekmroz!

Maybe something like this? This won't hide errors locating the element.

def input_password(self, locator, text):
    ...
    self._input_text_into_text_field(locator, text, secret=True)

def _input_text_into_text_field(self, locator, text, secret=False):
        element = self._element_find(locator, True, True)
        element.clear()
        if secret:
            old_level = BuiltIn().set_log_level('NONE')
        try:
            element.send_keys(text)
        finally:
            if secret:
                BuiltIn().set_log_level(old_level)

Won't Robot Framework log the password no matter what? Even if we used the above code won't the log still have a line that says

     Input Password   some-locator   the-secret-password-i-dont-want-logged

I'm not seeing that this keyword is of an use. Yes, it would be helpful if we posted information to the console during test runs. That is, if the obfuscated line we log "Typing password into text field ..." was displayed somewhere other than the log file and thus we were truly suppressing the plain text message "Typing text 'my-secret-password' into text field...". But I don't see a way with the current implementation that we were or could be hiding anything.

@emanlove

@emanlove ,

If you do write like you said, then of course that is visible in the log file. However, the use case here is that you get somehow the actual password to a variable as shown (poorly) in my original example. In this case, Input Password is the only thing that leaks the value of the variable to the log with sufficient log level

As detailed before by @ombre42 , setting the log level to NONE ought to be enough.

@Tattoo

First of all, I think Input Password has its usages. As @Tattoo wrote, you can get the password so that it's not visible in the test data (e.g. from the command line or from a variable file) and thus not visible in logs either unless explicitly logged.

The above said, I don't think it makes sense for Selenium2Library or any other library to fight against automatic trace level logging by Robot Framework itself. The main reason is that if arguments are passed through user keywords,they are trace logged at that point anyway. On test case level that can be avoided by setting log level to NONE, but it's much easier to just avoid distributing logs with trace level messages in the first place.

Selenium2Library logging traffic on debug level is a slightly different topic than trace level logging by Robot. This logging is easier to control by Se2Lib, but I'm not sure is that worth the effort. There could also be cases where those debug messages would actually be useful to understand what's going on.

Personally I would keep the keyword functionality exactly like it is now. I'd just add a note to the keyword that although it doesn't log the password itself, all traffic is logged on debug level by the library and all arguments on trace level by RF.

@pekkaklarck

@pekkaklarck Thank you for those thoughts. I've been searching for the right words so we can explain in the keyword docstring what one normally sees and how one can obscure to a point.

@pekkaklarck

I agree with @pekkaklarck's assessment.

It seems that this issue was resolved but it was not closed. Therefore closing the issue, but if you feel differently, please send an update and we will reopen the issue.

I'm sorry, but how is this resolved? The functionality still stays the same and documentation about the issue is not improved thus still being misleading. I personally still feel, that since Selenium and Selenium2Library are the ones that actually give away the information, that could be easily worked around. If they would like to see the debug messages, they could easily switch to using Input Text for debugging purposes.

Now people are leaking their passwords imagining they are safe, which is not cool.

PR #984 is going to add this note to Input Password's documentation:

    Difference compared to `Input Text` is that this keyword does not
    log the given password on the INFO level. Notice that if you use
    the keyword like

    | Input Password | password_field | password |

    the password is shown as a normal keyword argument. A way to avoid
    that is using variables like

    | Input Password | password_field | ${PASSWORD} |

    Notice also that SeleniumLibrary logs all the communication with
    browser drivers using the DEBUG level, and the actual password can
    be seen there. Additionally Robot Framework logs all arguments using
    the TRACE level. Tests must thus not be executed using level below
    INFO if password should not be logged in any format.

In my opinion this pretty clearly explains the problem with logging and I don't think trying to fix this otherwise is worth the effort. If someone disagrees, please explain how both of the problems explained in the above note could be solved by the library.

🙌 🙏

Navigation Menu

Repository navigation

Keyword "Input Password" logs given password #202

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Keyword "Input Password" logs given password #202

Description

Activity

j1z0 commented on May 27, 2013

ombre42 commented on May 27, 2013

Tattoo commented on May 29, 2013

Tattoo commented on May 29, 2013

marekmroz commented on May 31, 2013

ombre42 commented on May 31, 2013

emanlove commented on Feb 18, 2015

Tattoo commented on Feb 18, 2015

pekkaklarck commented on Feb 18, 2015

emanlove commented on Feb 19, 2015

ombre42 commented on Feb 19, 2015

aaltat commented on May 23, 2016

Tattoo commented on May 23, 2016

pekkaklarck commented on Nov 8, 2017

Tattoo commented on Dec 5, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions