Keepassxc: Change default auto-type sequence not to include {ENTER}

[hifi]

I find the default auto-type sequence to be dangerous. I've always removed {ENTER} from the Root group as a safety measure. It's possible that you have the wrong thing focused within the window you're auto-typing to and it would accidentally submit something you definitely didn't want (a chat message for example).

Having it without {ENTER} gives you, the user, the ultimate control in the end if what you see is acceptable. The best case is auto-type works as intended and you hit the enter key yourself to complete the sequence.

Suggested Behavior

{USERNAME}{TAB}{PASSWORD}

Current Behavior

{USERNAME}{TAB}{PASSWORD}{ENTER}

[TheZ3ro]

I already see users opening issue like "Autotype doesn't submit my fields!!!"
I agree is pretty bad

What about removing enter from the default sequence and adding an option in the Root group like "Always submit autotype when using default sequence" (default will be off)

[droidmonkey]

I think we should investigate multiple defaults, like a template picklist for common scenarios.

[quinncomendant]

I also prefer to hit ‘enter’ manually. However, this can be an issue if you hit enter before the auto-type has finished "typing" into the password form field (resulting in "login failed"). If you use a long password, auto-type can take > 1 second.

If removal of {enter} from the default sequence goes ahead, it's worth checking if it would be possible to send the auto-type characters faster, or force them to go into the keyboard stream ahead of a manually typed ‘enter’.

Not a big deal, since users will learn (like I have) just to resist hitting enter before auto-type completes. ;P

[hifi]

Making auto-type faster will make it more likely to miss characters. The alternative would be to have "copy & paste" type auto-type that could be used alternatively instead of invidual keystrokes.

[louib]

What about adding the default autotype sequence to the database settings? Looks like the default sequence is hardcoded here and at some other places.

[hifi]

@louib The standard location for a database default is in the Root group of the database file. So you can make a database wide default by setting it there and every item in every group will inherit from that unless changed.

The point of this issue would be to change the hard coded default to something less dangerous by removing ENTER from the sequence.

[ccoenen]

Please don't diverge from original KeePass default.
Everyone with a heightened requirement for security can easily change this in their root group.

[phoerious]

Letting the use choose the default auto-type sequence is probably the best idea. The default would be what we have now hardcoded.

[hifi]

@ccoenen It may seem convenient to have it as a default but it can lead to submitting your credentials within a wrong form for example when used on a web page and auto-focus is set to, say, a contact form or you just have accidentally selected a wrong input field. Some forms even have enough javascript magic going on making them behave somewhat unexpectedly.

Protecting the user from hurting themselves is usually a good thing when you can always override the new behaviour. I would default to not submitting and having a checkbox in options if necessary to re-enable submitting by default if changing the root group is deemed too hard.

Also do remember that KeePassXC already greatly diverges from KeePass by having at least partly different keyboard shortcuts and completely different UI (both inherited from KeePassX) so it's a moot point in my opinion.

[phoerious]

I don't like having a checkbox. Having a default auto-type sequence instead is way more consistent and more flexible.

[droidmonkey]

One can just as easily add {ENTER} as the default as well. One thing i just thought of would be a setting that prompted the user prior to actually issuing {ENTER} with perhaps a "don't ask again" checkbox.

[phoerious]

But that wouldn't work if you wanted it for some entries and not for others (or you'd need that setting for each entry and group).

[ccoenen]

So, we're breaking the default state for someone "who might" leak their credentials this way. You do realize that the circumstances have to be very specific for that to happen, right?

They might also Press Enter because of muscle-memory - so where do we go from there?

I am very much against changing this default.

[phoerious]

We are not breaking anything. We are only changing a default if anything.

[hifi]

@phoerious It would only need to ask it only once per installation and set the global default that way, then override per-database with the root group or something along these lines.

@ccoenen "Breaking" is a strong word when this project is not KeePass.

[ccoenen]

If something does not work as expected, it is broken. Even if it is technologically sound, it will create confusion for users. And this should be treated as a problem as well, unless there is a very good reason for it. This is the part that I do not see, here.

In this case, people coming from any other flavor of KeePass* will stare at their login boxes and wait for the websites to reload. And there will be "this is broken" issues here.

As for "configuration after install". Everyone loves those, right? We don't yet know what this software does or if we are going to use it for anything, but we are supposed to anwser things things that are fundamental to its usefulness.

The current default is a good one. Yes, add an option in the general preferences, like KeePass does it. But please don't set that configurable default to anything else.

[hifi]

What if we start by making the default sequence configurable in the auto-type settings like it has been suggested in this issue multiple times? No one is against giving the user the option to change the global default.

It's a rather easy task and I can send a PR if everyone's ok with that.

[phoerious]

There are actually strong security implications tied to this behavior. Changing the default may be totally justified. We do not modify behavior lightly, but when there are reasons, we may.

To put things into a different context: we also have a challenge response implementation that is incompatible with KeeChallenge and the questions we get why things are different or don't work as expected are very manageable. In fact, we get more questions where you put the PLGX files for installing KeePass plugins.

[ccoenen]

Regarding configurable default in general:
It is configurable in KeePass, and I am not at all against that. I am, however, against changing the ultimate default for freshly installed KeePassXC.

Regarding first-time configuration screen:
I wrote all about that in my previous post.

On "security implications":
The "strong security implications" are "you might auto type a password into a window that happens to have a matching (or configured) window title". If someone can trick you into Auto-Typing stuff into a window with faked title, they can easily read the input regardless of a pressed Enter key.

[droidmonkey]

Quick note, I don't believe the "mistake vector" is matching windows title but more so pressing the global autotype hotkey on the wrong window (im/chat window for example). That is why i suggested a simple prompt in this circumstance when the {ENTER} keyword is encountered. Default autotype sequence is irrelevant to that security feature.

[ccoenen]

I don't believe the "mistake vector" is matching windows title but more so pressing the global autotype hotkey on the wrong window

The Auto-Type works by matching the currently active window's title to either a password's title (that one is automatically set up), or to a list of additional allowed window titles (that has to be set up by the user on purpose). You can't have your IRC-Window open and type your PayPal info into it by accidentally hitting Ctrl+Alt+A.

[TheZ3ro]

I've always removed {ENTER} from the Root group as a safety measure.

This behavior is still possible and should be the correct method to do it.
Every entry without a specified sequence will inherit from parent group, every group will inherit from parent so removing {ENTER} from the Root group will effectively disable it for every entry by default.

I think the actual default is ok and safe under the mistake circumstance.
At worse the autotype will mistype some character and press enter

[ccoenen]

We just thought about a few more scenarios among friends, one of them being "the URL field in the browser is active and receives the auto type".

One would argue that NOT hitting enter would save the day. It does not. Most (if not all) browsers are configured to do a live search, automatically pulling suggestions from some search engine. You don't need to type Enter. Your data is already gone.

So removing enter also gives you a false sense of security (not always, but certainly in this case).

[repomaa]

With a password store of roughly 280 entries I can say that it happens every now and then, that the wrong window title gets matched or that the focus is on the wrong form field (this happens to me quite often). In those cases I'm glad, that my password store doesn't hit enter. I second @ccoenen though on the note that malicious websites/programs will not need you to hit enter to get your creds.

[hifi]

The idea wasn't to protect from malicious websites but from accidental submission of credentials through wrong forms.

[sergeevabc]

I voted against removing {ENTER}.

Life is dangerous by definition, due to the presence of imminent risks. Being vigilant should be a part of character, of daily routine, both offline and online. Tool such as KeePass[XC] is here to _facilitate creating, storing and using credentials_, not to promote the subversive idea that a machine could absolve a person from all hassles, especially by means of false safe defaults.

For example, Gmail saves a draft copy without explicit user’s consent unless Javascript is switched off (which is rare) — a well-known malicious technique, so the absence of {ENTER} in auto-type sequence barely helps as sensitive data is already typed in the risk zone. Ultimately, the proposed feature does little for safety of hasty climbers, but slows down the others.

Practise paying attention about where you go, otherwise go to (presumably safe) bed and sleep first.

[hifi]

The PR has been closed and there was another discussion against it in the comments, closing this.