As from my earlier times of programming one of my stock in trades was and still is a special password field and as Xojo password field is quite awful, I made one and also a auto fill textbox, so MoreInputs was born. In the beginning I thought that maybe I can earn little money by it, but then I realized that money is not most important thing in the world, so you can use it with e-mail code@for.all and accordingly with activation code CDE9-EE1E-03BA-791C. If it suitable for anybody, then enjoy and Merry Christmas!
Heads up, the password field in Xojo is a native control. This means it takes advantage of security features provided by the OS for password fields. To make this more clear, on Mac it is called NSSecureTextField.
Do not provide your user a field other than a native password filed for password entry.
I have not looked into the Windows security aspects of a password field, but ugly is less important than secure.
On Mac password fields protect the user from keystroke listeners (unless they’re installed and running root) as well as preventing copying the value.
[h]Do not provide your user anything except a native password filed for password entry.[/h]
I appreciate the effort, and the kind gesture of sharing the work; but security is far more important.
This is a security issue. A major one. Presenting your user with anything other than a native password field for their password is unnecessarily opening them up to dangerous situations for the sake of vanity. The user may have malware they don’t know about, or someone unscrupulous could be watching.
Imagine you lost control to your bank account because you happen to use the same password, and it got stolen because an app you use didn’t implement a password field the way they should have.
I’m all about interfaces looking nice and being easy to use, but a developer should never sacrifice the user’s personal security for a “styled” password field. Not knowing about the security involved is one thing, but to argue against user security after it’s been pointed out is just irresponsible.
I’m not talking to just the OP.
I’m talking to anyone here who looks at this thread, and looks at the controls.
About me being dogmatic:
Xojo is super easy which is great for a lot of reasons. But it has the downside of attracting some people who have no idea what they’re doing with software development. It’s okay when it comes to personal use applications, but I’ve seen some things here that should not be delivered to customers - yet they are.
There are a lot of things I let go, like when it comes to accessibility I just make annoying reminders.
But this is user security. For the real world. Ignorance is not acceptable.
Thanks a lot Michel for good words.
And Tim you talking about user security! In windows there is easy possibility to hack native password field with some kind of bullet revealer. And you talk with bold letters about native password field and nothing more! Shame on you! You are dogmatic.
I elaborated in an earlier post, but let me quote it again for you.
[quote=304001:@Tim Parnell]
On Mac password fields protect the user from keystroke listeners (unless they’re installed and running root) as well as preventing copying the value.[/quote]
So, in bullets, the two features I covered:
Protects the user from keystroke listeners (unless the admin has installed one to run as root)
Markus, I would have a LOT of efforts to do to even remotely start being as aggressive as you. And BTW there would be no interesting discussion without some level of disagreement.
I looked at the class posted by the OP. His password textfields do protect the user against copy.
It is not fair to single out a fellow programmer without even looking at his work.
I looked at the classes running in the debugger, they’re subclassed of TextField with Password: False
Setting Password to True might be enough to change them to a proper NSSecureTextField but the truth is we can’t know what else may be going on because they’re encrypted. The customizations may expose a security hole one might never know about because we can’t look.
Why Tim must be shame? Because he suggest to use Windows native password field, which is not secure at all and can be revealed with little tools, easily obtained from internet. And he insists with bold letters to use that nonsecure native way! Shame on him! He blames that I use for indicating purposes TextField. So what? If Tim would be wiser men, he would know that always you dont get what you see. Shame twice!
You dont know, what is behind that password field? Good then it is more secure. And Tim you dont know at least 50% of life aspects, what is behind of them. Can you live with that knowledge?
If you fear, then with my inputfields you can, before using them, make certain that they not collect information and not calling home. Im not 100% sure, but I think that you also dont know what is exactly behind the Apples NSSecureTextField.
Tim you started it, I just defend myself, so please think twice or triple before you talk about things, you dont know (For example about Windows native passwordfields). Unfortunately my English is quite bad, otherwise I told much more and explained me more clearly, but let it be. Im stupid and you are God. It not takes piece from me. I learn with every step. Can you?
Even more amusing in context, this comment at the same site :
There is much more with a simple googling. Dozens of pages… I am posting this link only for illustration of what we are up against, so we can devise workarounds, not as an encouragement.
Moreover, the Xojo Windows default password field is really disgustingly ugly.
All that said, I would personally rather explore a solution that uses a Canvas to mimic a TextField than the TextField control itself, in order to completely disable any copy feature. And maybe use Keyboard.AsyncKeydown to bypass the normal keyboard buffer that can be hacked. By the way for once, the Windows keyboard class has the advantage for us European barbarians, to be localized, which is not the case on Mac.
Finally, your English is quite legible. You can also use Google translate. It is often very convenient.
Yes, implementing Keyboard.AsyncKeyboard is possible and not hard at all, but it still not defends against key loggers under Windows. Or am I wrong? And using Canvas - I dont see a good reason. Why I must invent bicycle and text caret, if they already exist. It will be only joy from creating particular, already existing thing, but I have lot more nonexistent things to create for achieving a joy.
And about my English. I have just little practice. I read a lot, but no need to write or talk. And what considers Google or Bing translates - their Estonian-English-Estonian side is just for cheer making. Good humor, but quite useless if you already dont know language. Grammar is headache for me and about that those translators did not help at all. But by little help from Word speller, my sentences are born. Anyway, I dont feel yet comfortable explaining my thoughts in foreign languages that I understand.
A simple TextField allows copying the content. A canvas would prevent any such copy. And it is really not that difficult to emulate the caret. By the way, the English idiom is “reinventing the wheel”.
Keyloggers usually tap into the keyboard buffer. Using the keyboard class taps directly into the keyboard handler, before keys are sent to the buffer. You can even return true in the KeyDown event so they are suppressed immediately.
As I said, if I needed such control, I would probably do it that way. Which does not mean it is the only way to go. If anything, computing is less about dogma than about creativity.
In the end, as Norman and other have often described, hackers use tools able to follow every single byte, and they can pick a password in the extremely short time it exists between encryptions…
