Make {PICKCHARS} possible [$50]

[marekjedrzejewski]

Original KeePass has {PICKCHARS} placeholders for entering partial password, would be nice if it was implemented.

Expected Behavior

When entry has {PICKCHARS} placeholder, window is opened that lets user choose which characters of the password should be entered. It looks like this in KeePass:

I'd gladly try to implement it myself if someone points me in the right direction :)

[droidmonkey]

I still think this is an antipattern fad that is going to go away. Cool dialog though

[slagiewka]

Antipattern or not - it is still a valuable feature for logins in various locations that still require selective character input. For me it's the only thing that forces me to use a regular KeePass from time to time. It would be great if I could use KeePassXC for every use case I have.

👍 to that.

[phoerious]

To be honest, I didn't even know this broken authentication scheme was even a thing until people started bringing it up.

[sourcecodes2]

Santander, one of the world's largest banks, use this authentication scheme.

Having {PICKCHARS} is a life saver, especially when you've got a long randomly-generated string as a password :)

[TheZ3ro]

I think this will remain in wishlist for a long time

#820 (comment)

[sourcecodes2]

I think #820 has been referenced in error, these are two distinct suggestions/features.

[TheZ3ro]

It was a specific comment that I was referencing.

Here Santander is using a bad practice authentication.
The password stored in Santander database are plaintext otherwise they won't be able to know which character is in which position.
Storing passwords in plaintext is a VERY BAD idea.

I'm really not interested in developing a tool that will increase the adoption of such a system.

[slagiewka]

Again, denying this option to KPXC users will NOT make Santander (or any other banking system - seems that only those use it) forfeit this login method.

Some people are stuck with certain banking solution and as long they have no other option, KPXC is useless. Imagine using a business account, where you have no saying in which bank is contracted. What would you rather see? A user not relying on kdbx and using memorized/written down, fairly simple password or a user that is doing everything he can in order to make everything as secure as possible on his side?

Do what ever you think is right, but from my point of view you're declining the feature while blaming the wrong side.

And no, those passwords are not stored as plain text. I encourage you to do some research before making any assumptions.

[TheZ3ro]

I've not said that we won't implement this.
If we receive a PR we can even accept it.

But personally I will not waste time on this since only few website are using this scheme and there are core feature that need much work instead.

this will NOT make Santander (or any other banking system - seems that only those use it) forfeit this login method.

Never heard of strike/protest? If users don't have a way to login they should blame Santander for using that login method.

And no, those passwords are not stored as plain text. I encourage you to do some research before making any assumptions.

Then tell me how they are stored.
Encrypted? Then the server has the key to decrypt them and see them in plaintext.
Homomorphic encryption? To date there are no reliable homomorphic encryption scheme that are safe and reliable at the same time

The only viable option is using 2 password, one stored as hash and one stored plaintext, asking the full one and only part of the second one, but from the screenshot (and from what I read online about Santander) this is not the case

I would love reading some papers/documentations on that (but sadly all banking system are closed source proprietary software)

[phoerious]

I was recently confronted with this weird confounding authentication scheme on a UEFI console when I tried to change secure boot settings. That was the one and only time I've ever had that. Never before, never since and I'm still puzzled by it. It is so astoundingly counter-intuitive that I almost forgot what password I chose when it asked me for the 3rd and 5th character of my temporary 7 character bullshit password.

[phoerious]

BTW I agree with @TheZ3ro that this is very low priority. If somebody wants to implement it, fine by me. But for us it's no priority. I consider this authentication scheme very bad practice for obvious reasons. The most obvious is its terrible usability which I described above, the other is its security.

As for how banks implement this scheme, we have no idea what methods they use, because, as said before, they are all closed-source. The three supposedly most viable options would be symmetric encryption (hopefully with some sort of HSM or at least TPM), hashes of all possible combinations of letters or secret sharing where you use your partial passwords to encrypt a stored hash value which you can later compare.

None of these are industry standard best practices for storing passwords. Symmetric encryption may compromise passwords if the keys are leaked. There is expensive security hardware which is designed to prevent that, but why not simply hash the passwords for free?
Hashing of partial passwords is very inflexible, costs a quadratic amount of space and when you have to hash so many passwords, you are more likely to use fast hashing algorithms which overall lowers the security considerably.
Secret sharing is perhaps the best way, but I don't like it either. There has been quite some research in the field (Google Scholar lists about 1.3 million papers), but except for two recent ISO publications I can't really find any applicable industry standards. Password hashing has received a lot more attention and is considered the industry standard best practice for good reason. There are also hardly any notable libraries out there that provide a secure and proven secret sharing implementation except for various textbook Shamir-SS finger exercises. I wouldn't entrust my passwords with any of those implementations.

[UtXtiQArZE]

Is this feature still going to be implemented (if not eventually)? for me its one of the biggest headaches re keepassXC.

There was progress made in issue #1245 but that got closed.

[ksimuk]

My opinion this feature should never be implemented, it is bad in all cases, just change the bank to another with proper security practices.

[UtXtiQArZE]

please expand on "bad in all cases";
Is it a high priority feature? well no probably not. but it is important enough for Keepass to implement and would provide a benefit to a number of people.

yes the banking security is potentially a little less, but i'm not moving my bank because it's hard to type in my password / the bank does not have the best practices.

what harm, apart from needing a bit of coding time, does it cause to add it in?

[ksimuk]

please expand on "bad in all cases";

Usability/security.

Is it a high priority feature?

it should not be a feature at all, as it is a bad security practice. Check BarclayCard, they are authentication a user by 6 digit pin and 2 letters from memorable information, instead of implementing 2FA as they should.

would provide a benefit to a number of people.

benefit of usability may be, questionable, but it will be a huge step back in security, people should stop using these banks and not move bad practices into password managers.

i'm not moving my bank because it's hard to type in my password

you should move your bank because they are incompetent.

what harm, apart from needing a bit of coding time, does it cause to add it in?

more code => more complexity => more issues

Example is 2FA software token functionality should not be implemented in password managers because it kills the idea of "the second factor", but with your logic it should be added as it "would provide a benefit to a number of people".

[droidmonkey]

We have already added 2FA TOTP in KeePassXC and it does not kill the idea of a second factor. You can create multiple databases and simply store your TOTP token separately from your main password database. Use a different master key and there is your second factor. In fact, I would argue this is much more secure than storing that information on a phone that only gets security updates semi-annually.

As for this "feature" I do intend to implement it based on the original PR that was submitted, but not until 2.5.0.

[ksimuk]

We have already added 2FA TOTP in KeePassXC
Missed that, thats a shame
it does not kill the idea of a second factor. You can create multiple databases and simply store your TOTP token separately from your main password database.

this is exactly the wrong 2FA usage, the attacker needs to get access only to one device to perform the attack now. there is no physical separation of factors anymore in your case.

I would argue this is much more secure than storing that information on a phone that only gets security updates semi-annually.

this is why phone is just an additional factor in authentication, hacking the phone or getting access to a hardware generator is not enough to log in to a system with 2FA.

As for this "feature" I do intend to implement it based on the original PR that was submitted

okey then, may be 'reboot' went to much into 'reboot'.

[OskarW85]

My opinion this feature should never be implemented, it is bad in all cases, just change the bank to another with proper security practices.

And that's exactly why YOU lose potential users, Mr. Know-it-all.

[droidmonkey]

@OskarW85 that quote is not from a member of the KeePassXC team...

[ksimuk]

@OskarW85 the first: these banks should loose clients,
And yes, keepassxc lost me as a client, trivial bugs are not fixed, but bad secure practices are introduced in priority.

[phoerious]

I don't know what trivial bugs you are talking about, but I object to the statement that we implement bad security practices. I am inclined to lock this issue. The discussion has derailed and is leading nowhere.

[wheybags]

I actually started working on this independently, just saw this issue now. I'll try clean up what I've got and submit a PR, unless @droidmonkey says he has it done?

[droidmonkey]

I haven't done it, but there are major autotype changes in my branch

[wheybags]

There is no auto type functionality in my implementation.

[wheybags]

(Yet) :p

[Wolvverine]

How use this?
What status?

[droidmonkey]

It's done, going to be merged into 2.7.0

[droidmonkey]

They likely only have a few permutations of choices and just precompute the hash for each permutation from your original password when you set/reset it. They definitely aren't being fancy!

[phoerious]

Salted one-character passwords sound like a pretty dumb idea, because the salt is in plaintext. Should be easily crackable in milliseconds if you know the scheme. Go, try it, here's a pair of sha256 hash and salt:

('d50ea1c16e2a426ca2e6f6a0492e0e39fa99422ff41c522ec85f3156768d4b74', '9kZB&%hG')

And since the bank also needs to keep track of which hash is which character in which position, they would have to save all 6 as a list in the correct order, so it's basically just obfuscated plaintext.

[kevin201]

Pickchars syntax still apparently not aligned with keepass. Produces an error:

https://i.imgur.com/RXWxU9R.png
https://imgur.com/LjcrUbR

[droidmonkey]

We chose not to follow that syntax. You can opt to use another attribute by name (case matters), but not the character positioning portion. Example: {PICKCHARS:Username}