Author Topic: clipboard security risk  (Read 30517 times)

Offline landroni

  • Jr. Member
  • **
  • Posts: 18
clipboard security risk
« on: May 09, 2012, 07:26:51 PM »
Dear all
I am no expert but I was quite impressed by the solution proposed by PasswordMaker to strong passwords. As long as I choose a strong Master Password and I use PasswordMaker to generate very long and unique passwords which cannot reveal the MP. There is however one security detail that bugs me:
Depending on the PasswordMaker Edition used, one needs to *copy* and paste a given password for a specific account. This means that the password is being shared with a completely unsecured medium---the clipboard.

Depending on your OS and config, this password may be stored by the clipboard for a very long time (and sometimes without the express knowledge of the user). On Linux a selected and copied password will be kept in *two* different clipboards [1], and I for one am not very familiar with the internal mechanics of the clipboards. Is the information copied stored in memory or/and on disk? Can another process (say, a logger) recover/request the clipboard information? Can the info be recovered even after the clipboard has been cleared?

To get to the gist of my inquiry, is this security risk recognized and/or documented in the PasswordMaker docs? Do PasswordMaker devels recommend any specific, secure clipboard manager (on each of the supported OSs) that can be trusted with copied passwords? Should PasswordMaker devels provide a very simple but secure clipboard manager to be used in conjunction with any PasswordMaker edition? Please let me know.

[1] http://docs.xfce.org/extra/clipman/start

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Re: clipboard security risk
« Reply #1 on: May 09, 2012, 07:34:27 PM »
Hi,

PasswordMaker automatically clears the clipboard after X seconds. "X" is configurable. Remember, you don't have to copy the password to the clipboard at all. It is your choice.

Eric

Offline landroni

  • Jr. Member
  • **
  • Posts: 18
Re: clipboard security risk
« Reply #2 on: May 09, 2012, 08:07:56 PM »
Hello

PasswordMaker automatically clears the clipboard after X seconds. "X" is configurable. Remember, you don't have to copy the password to the clipboard at all. It is your choice.
This still does not address the security concern.

First, not copying the password is not really an option. I decided that I wanted to have passwords 18 chars long: it is out of the question that I start typing such passwords after PasswordMaker has generated them. I guess many users would adopt the same position even with much shorter passwords: re-typing a 10 char alphanumeric symbol containing exotic symbols would be a put-off to many. So I propose that we assume that many users indeed copy their passwords to the clipboard.

Now also consider that I'm using the Online version. The reason is simple: I use Opera and the PasswordMaker Opera Widget doesn't automatically fill the password input box and there is no 'clear clipboard after X seconds' option, but the Widget gets discontinued anyway [1]; and I use Linux while the PasswordMaker Desktop edition is broken on Linux [2]. Given the above, a copy/paste is inevitable (for me, at least, but for many others, I assume), and there is no 'automatically clear the clipboard' option.

But even with such an option, imagine a logger that automatically clones the system clipboard on each modification of its contents. (I don't think that this pertains to SF.) In such a case the 'automatically clear the clipboard after X seconds' option is genuinely useless. Also, would this option address the X11 'primary clipboard'? On Linux, even if the 'default clipboard' is being cleared, if I don't select anything later and leave the computer, then a 3rd party could in principle come to the computer, press 'shift + insert' and recover the account password.

Am I missing anything? Could PasswordMaker provide a cross-platform utility that would allow to securely transfer (NOT via the clipboard) a generated password to the current focus/cursor?

[1] http://forums.passwordmaker.org/index.php/topic,1749.msg1282824.html#msg1282824
[2] http://forums.passwordmaker.org/index.php/topic,1750.msg1282828.html#msg1282828

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Re: clipboard security risk
« Reply #3 on: May 09, 2012, 08:20:33 PM »
Quote
Am I missing anything? Could PasswordMaker provide a cross-platform utility that would allow to securely transfer (NOT via the clipboard) a generated password to the current focus/cursor?

What is wrong with CoolKey and auto-populate? These two features do not use the clipboard.

Offline landroni

  • Jr. Member
  • **
  • Posts: 18
Re: clipboard security risk
« Reply #4 on: May 09, 2012, 08:52:24 PM »
Quote
Am I missing anything? Could PasswordMaker provide a cross-platform utility that would allow to securely transfer (NOT via the clipboard) a generated password to the current focus/cursor?

What is wrong with CoolKey and auto-populate? These two features do not use the clipboard.
True, but I see these two features only in the Firefox Extension. Unfortunately I do not use Firefox, and for the time being I rely on the Online Edition.

Offline Miquel 'Fire' Burns

  • Administrator
  • *****
  • Posts: 1157
  • Programmer
Re: clipboard security risk
« Reply #5 on: May 10, 2012, 01:05:56 PM »
Click Edition might be the best option for Opera users until an extension is made.
"I'm not drunk, just sleep deprived."

Offline landroni

  • Jr. Member
  • **
  • Posts: 18
Re: clipboard security risk
« Reply #6 on: May 10, 2012, 05:18:19 PM »
Click Edition might be the best option for Opera users until an extension is made.
I did play around with the Click Edition, but I couldn't find a way to configure it. Its homepage informs that all the settings are stored within the bookmark, which is fine, but I'm not sure how to modify these settings. I tried modifying the settings here [1] and then saving the bookmarklet, but it doesn't seem to have an effect. Any ideas?

[1] http://passwordmaker.org/bml/

Offline Miquel 'Fire' Burns

  • Administrator
  • *****
  • Posts: 1157
  • Programmer
Re: clipboard security risk
« Reply #7 on: May 10, 2012, 08:21:34 PM »
*See some byte saving optimizations that can be applied to the bookmarklet*

Look at the generated bookmarklet at the p and e variables. Those should be changing as you make changes.
"I'm not drunk, just sleep deprived."

Offline landroni

  • Jr. Member
  • **
  • Posts: 18
Re: clipboard security risk
« Reply #8 on: May 14, 2012, 04:10:19 PM »
*See some byte saving optimizations that can be applied to the bookmarklet*

Look at the generated bookmarklet at the p and e variables. Those should be changing as you make changes.
It took me a while to understand what was happening and why it was not working. It turns out that I had JS disabled when I was trying to configure the settings. So the modifications weren't imported in the bookmarklet.

To avoid user confusion, would it be possible to have an: 'Attention: Make sure that your browser has JavaScript enabled before modifying any settings.' Moreover, to make it more clear I would suggest to add some more info at the end: 'To save the settings above, drag this link to your bookmarks menu'.

Thanks.

Offline Miquel 'Fire' Burns

  • Administrator
  • *****
  • Posts: 1157
  • Programmer
Re: clipboard security risk
« Reply #9 on: May 15, 2012, 01:24:17 PM »
I made the changes to the page. Just need to copy the changes to SVN now.
"I'm not drunk, just sleep deprived."

Offline landroni

  • Jr. Member
  • **
  • Posts: 18
Re: clipboard security risk
« Reply #10 on: May 18, 2012, 07:00:49 AM »
PasswordMaker automatically clears the clipboard after X seconds. "X" is configurable.
I've tried the functionality in the Qt and Java editions of PasswordMaker and at least on Linux this is more of a security illusion.

Qt: I generated the (currently broken) password 'ERROR!ER' and had it copied to clipboard. However, even though the 'autoclear in 10 sec' setting was activated, PasswordMaker-Qt didn't subsequently do anything so the password was kept in the clipboard manager indefinitely.

Java: It copied the password to the clipboard then tried to erase it after 10sec, but failed. It failed simply because it assumed that the clipboard can hold only one item at a time and that subsequently copying to the clipboard a bogus string 'ªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªª', to be precise, would erase the previous password string. However, my clipboard manager (Clipman)---as well as most such apps on Linux---is capable of holding 15 different items in its history. So the password string was simply bumped to the 2nd place in history, staying there indefinitely.


I gave some thought to this issue and I think that one way to address the security risk is to replace the 'copy to clipboard and auto-erase' with 'Coolkey'-equivalent functionality in all the other clients. (At the very least the 'copy to clipboard and auto-erase' security risk should be properly documented, either online or as a tooltip in the various clients.) My proof of concept design is to have a 'Transfer password' global keybinding:
After you generate the password in the, say, Qt edition, you focus the browser password input field and then hit a 'ctrl+alt+`' or similar key binding that would securely, without accessing the clipboard, transfer the password string from the Qt app to the current focused input box.

This would be similar to the Firefox implementation, but would have a more global desktop application (for passwords for encrypted partitions, etc.).

Offline tanstaafl

  • God Member
  • ******
  • Posts: 1363
Re: clipboard security risk
« Reply #11 on: May 18, 2012, 09:38:01 AM »
Dear all - There is however one security detail that bugs me:
Depending on the PasswordMaker Edition used, one needs to *copy* and paste a given password for a specific account. This means that the password is being shared with a completely unsecured medium---the clipboard.
<snip>
To get to the gist of my inquiry, is this security risk recognized and/or documented in the PasswordMaker docs?

Not to my knowledge, but I agree there could be an FAQ added... which I would happy to do, but I lost wiki access a long time ago (there are other minor changes I'd like to make too, so I'll see if I can get my access restored)...

Quote
Do PasswordMaker devels recommend any specific, secure clipboard manager (on each of the supported OSs) that can be trusted with copied passwords?

No (at least not that I recall, and I helped write the wiki)...

But the bottom line is, there probably isn't one... if your computer is compromised, it is compromised. If you are using some 'secure' clipboard manager, but you have 'engaged' it (ie, typed the password to allow it to work so that it can interact with form fields like the regular clipboard), then whatever is monitoring the system clipboard could monitor it too.

There is no such thing as a 100% secure computer, except for one that is disconnected *and* powered down.

Quote
Should PasswordMaker devels provide a very simple but secure clipboard manager to be used in conjunction with any PasswordMaker edition? Please let me know.

Seriously? I'm curious how exactly that you feel the PWM devs 'should' provide you anything beyond what they are willing to offer up on their own terms and at their own pleasure. You are free to use it or not, but I really hate these kinds of comments that seem to make the claim that open-source developers 'owe' you something/anything. Maybe you didn't intend it in t hat way, but that is how it reads...

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Re: clipboard security risk
« Reply #12 on: May 18, 2012, 03:05:25 PM »
Quote
but I lost wiki access a long time ago (there are other minor changes I'd like to make too, so I'll see if I can get my access restored)...
As you might recall, we all essentially lost write access when the management of wiki spammers became unendurable. Write access is globally disabled for all, even accounts granted administrator access. In order to re-enable write access, one of us has to (temporarily) edit the MediaWiki config file. That requires ssh access.

I am PM'ing you SSH login details and instructions on how to make the wiki editable. Save the PM for the future!

eric

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Re: clipboard security risk
« Reply #13 on: May 18, 2012, 03:22:22 PM »
I am PM'ing you SSH login details and instructions on how to make the wiki editable.

Sent!

Quote
I'm curious how exactly that you feel the PWM devs 'should' provide you anything beyond what they are willing to offer up on their own terms and at their own pleasure. You are free to use it or not, but I really hate these kinds of comments that seem to make the claim that open-source developers 'owe' you something/anything. Maybe you didn't intend it in t hat way, but that is how it reads...
My standard answer is "PATCHES ACCEPTED"

But landroni must be smoking something funny if he thinks there is a cryptographically secure way to achieve IPC across arbitrary, unknown executables on multiple operating systems (i'd be surprised if he has an answer even for just *one* operating system). There are ways to achieve secure IPC when the developer has source-level control over both the sending application (passwordmaker, in this case) and the receiving application (in this case... Firefox? Some other browser?). But we do not have source-level control over the receivers without forking major F/OSS projects, like Firefox, and issuing custom builds with the appropriate secure IPC patches. That's not going to happen.

Eric

PasswordMaker Forums

Re: clipboard security risk
« Reply #13 on: May 18, 2012, 03:22:22 PM »