Tails

#1 Updated by sajolida 2014-10-15 16:24:06

Currently, AutoType is the only way to paste a password in Pinentry in
Tails (see KeePassX documentation), for example, for an OpenPGP key. So
disabling the AutoType would introduce a regression in that aspect.

#2 Updated by intrigeri 2014-10-16 01:30:50

> Currently, AutoType is the only way to paste a password in Pinentry in Tails (see KeePassX documentation), for example, for an OpenPGP key. So disabling the AutoType would introduce a regression in that aspect.

Urgh. Can the AutoType feature be enabled on a per-application basis? In our case, that would be either “everything but the web browsers” or “nothing but pinentry”.

#3 Updated by matsa 2014-10-22 21:24:28

> Can the AutoType feature be enabled on a per-application basis?

When adding a new entry in Keepassx, it’s possible to select the target window (based on the window’s title), by selecting “Tools” (on the bottom-left corner) then “Auto-type: Select target window”

#9 Updated by dkg 2016-03-09 21:04:03

as i understand the paper from a quick skim, it’s primarily about autofill attacks. If you can avoid having your password manager auto-populate forms that appear to be password entries, then you should avoid most of these concerns.

I haven’t used keepassx, but does it actively target all web forms as they appear? or does it only activate when you explicitly trigger it? if it’s the latter, the attacks listed in section 5.1 in this paper are not relevant. the (weaker) remaining attacks in section 5.2 are still relevant, but require much deeper integration in the browser than i think keepassx is capable of doing.

do not trigger keepass to enter your passwords into an insecure webpage (or any other insecure network resource)!

#10 Updated by dkg 2016-03-09 21:07:20

sajolida wrote:
> Currently, AutoType is the only way to paste a password in Pinentry in
> Tails (see KeePassX documentation), for example, for an OpenPGP key. So
> disabling the AutoType would introduce a regression in that aspect.

newer versions of pinentry (since 0.9.6) now support traditional copy/paste, if you want that. I think this means that they shouldn’t require “auto-type”. jessie only has pinentry 0.8.3, though.

If you’d like a backport of pinentry to jessie-backports, feel free to file a wishlist bug with the debian BTS, i don’t think that should be a difficult thing to accomplish.

#12 Updated by anonym 2016-03-09 22:33:07

dkg wrote:
> as i understand the paper from a quick skim, it’s primarily about autofill attacks. If you can avoid having your password manager auto-populate forms that appear to be password entries, then you should avoid most of these concerns.
>
> I haven’t used keepassx, but does it actively target all web forms as they appear? or does it only activate when you explicitly trigger it? if it’s the latter, the attacks listed in section 5.1 in this paper are not relevant. the (weaker) remaining attacks in section 5.2 are still relevant, but require much deeper integration in the browser than i think keepassx is capable of doing.

This is was also my conclusion. Like I said above, KeePassX uses a simplistic method: when auto-typing it will just switch to the target window and after a short delay (so the GUI becomes ready) then simulating keypresses (xdotool-style) for the password. KeePassX has no way of focusing on the password entry itself, so the user must already have focused on it, or the keypresses will “leak”. So KISS saves the day it seems, at least w.r.t this paper.

Note that KeePassX also supports entering the username, which then requires focusing the username entry, and that a TAB will focus the password entry. Again, KISS should save the day.

Do you agree? If so I’ll close this ticket, concluding that we can keep auto-type.

> do not trigger keepass to enter your passwords into an insecure webpage (or any other insecure network resource)!

Sure, but it would be no unsafer than users entering the password manually in these situations. In fact, using KeePassX should be better when there’s no safe (HTTPS/whatever) option since it encourages unique passwords.

#25 Updated by dkg 2017-03-14 01:55:36

anonym wrote:
> dkg wrote:
> > If you want to clarify what you want me to do, i’m happy to have it reassigned back to me.
>
> In my comment in response to you (Bug #8121#note-12) I expand a bit on why I think none of the attacks are relevant to KeePassX, and even why it’s no worse to use on “unsafe” websites compared to manually typing. If you agree, I think this ticket can be closed and we leave autotyping enabled, otherwise I’d like a clarification of what I’ve misunderstood.

I think i agree that if keepassx is manually triggered by the user (as opposed to scanning each window or browser tab for forms it should fill in and aggressively filling in those forms without the user’s explicit permission), then the autotype feature is probably fine. feel free to close this report.

#27 Updated by RLW99 2017-03-28 16:25:58

thanks