Keepassdx: Deleted

[GithubABCDEFG]

[J-Jamet]

There is no restriction on the use of extended ascii in the main password field. I just tested and can easily fill them with the current version. The problem must come from your keyboard which does not offer them.

[J-Jamet]

I mean can the input method of the password window be the same as in the normal interface

No, it must be indicated that it is a password field otherwise the keyboard will remember the elements entered and this would be a security fault.

I need the word candidates of the input method to input different languages

I don't understand why you need this, just change the keyboard language.

[J-Jamet]

Can you describe a complete workflow that highlights the problem, with each step of keyboard change etc... Because honestly, I don't understand this language issue.

[J-Jamet]

I don't see the connection between complex passwords and adding words in keyboard recognition. It is quite possible to put a strong complex master password.

[J-Jamet]

And more than that, a long and complex password is essential for overall database security.

[J-Jamet]

What do you meen by "ASC != Chars" ?
It's an EditText defined as a password field, that's all. Like I said, there is no restriction in applying type of characters. You just need to change the keyboard. https://github.com/Kunzisoft/KeePassDX/issues/834#issuecomment-752889267
https://developer.android.com/training/keyboard-input/style

[hokonch]

This problem is practically the same as #660.

[J-Jamet]

But here we are not talking about the field of an entry but the main password. It is not at all the same criticality.
The problem, as it was stated in #660, comes from keyboards of languages ​​which change the type of keyboard. So this is not a problem in KeePassDX but in the keyboard's implementation. That's why I recommend that you take other trusted keyboards that meets your requirements (or create a new one). But I will not lower the security level in KeePassDX.

[J-Jamet]

I probably read #660, in fact, whether it is used for the master password or not, we actually have the same problem. That is, I need to have candidate words on the keyboard. If the password field is switched to the plaintext state, the password field can be synchronously changed to a normal field. I think this is the most reasonable.

It's the same problem if you want a protected field, but not if the field doesn't need to be. It is always an EditText of password type when the field is protected in #660. It's reasonable to put it in plain text simply when the custom field doesn't need to have sensitive content.

In fact, many apps will obtain clipboard permissions, and the password input field can use the clipboard, so this is also a security issue.

I don't understand this part at all. Why are you now talking about Clipboard? Password EditText fields cannot magically access the Clipboard from scratch, code is needed for that! Be more specific at this level.

[J-Jamet]

I just want to explain that there are actually many security vulnerabilities, and it is not a good practice to disable candidate words

I think on the contrary that it is a good practice for passwords, otherwise the words are recovered by the keyboard in an internal database.

All current security software seems to be unable to solve the problem of the master password.

It's necessary to make another keyboard that suits your requirements.

In fact, the security software makes the password even more insecure.

I don't agree, it depends on the uses

As long as the master password is leaked, everything will be leaked.

I agree, that's why I won't lower the security level to make it plain text.

[J-Jamet]

The password can be combined with these words and characters, that is, the plaintext state of the password field and the hidden state of * are combined and input.

I don't see the connection to my quote above and your sentence. As I said, EditText does currently have the password type which gives it character masking characteristics (*) and prevents words from being saved in the keyboard database for suggestion (as plain text would do).

I just think it is very important to prevent brute-force.

I agree, people need to be educated to create long, secure master passwords.

The more extensive the password library, the more secure it is. In fact, everyone has a lot of digital terminals. The solution must be to synchronize the password library through the cloud. Many apps need to directly obtain all cloud permissions, so the password library is actually completely exposed and insecure. For brute force cracking, the vector unit calculation of the graphics card can obtain great computing power, and this computing power has increased geometrically, so only extremely complex passwords can effectively prevent brute force cracking.

Again, I don't see the connection between the Cloud and the current topic. KeePassDX has no built-in cloud and will not have one. And if you want to talk about brute force with graphics card, just open another topic.

[hokonch]

the password needs to be very complicated.

Any Unicode character has lower entropy than three random ASCII characters, so a long ASCII password is complex enough. If you assume that crackers will brute-force only ASCII passwords, just add a single emoji or extended ASCII character. For Chinese and Japanese people, Chinese characters are memorable and high-entropy but not essential to create a strong password.

[J-Jamet]

Everyone agrees that the longer and more complicated a password is, the more effective it is against brute force. This is not the problem. So no need to convince at this level.

The issue here is that the Master Password EditText cannot be passed to plain text because there would be an external save of the words by the keyboard so your solution (@GithubABCDEFG) is a real problem.

If someone can easily get your keyboard database, it also means that no matter how strong the password is, it has already lost its effect.

Not at all, KeePassDX has no way of knowing what the external keyboard is doing with the saved words for the suggestion.

We have almost never heard of keyboard leaks, but Cloud leaks happen frequently.

It doesn't mean that it can't happen or that a fraudulent keyboard can't exist for this purpose. And we can't fix it in the app in this case.

@hokonch is right and once again if you want you can create or get a suitable keyboard in your language for your need.