2

I have a web application that replaces a non-web predecessor.

A low level set of users accessed basic functionality with touch panels in the non-web previous version of the product with the touch panels being secured with a PIN code.

The replacement devices panels will be android. We have suggested doing this as a passphrase, or as a numeric input, but product management wants an HTML rendered "key pad" screen instead of the normal android input panel behavior.

Gut feeling is that this is less secure than using the OS inputs, but I cannot come up with a concrete reason that it should be that doesn't also apply in either case.

Am I overlooking something or is my initial reaction incorrect here?

|improve this question
  • Why would a custom input be more or less secure than a default input? In both scenarios you are entering (the same) data and sending it on to the server. The only difference seem to be user friendliness. – oɔɯǝɹ Jun 18 '16 at 23:21
  • in some cases it is, like re-implementing the windows auth dialog vs calling for the default to be displayed from managed code or asking the browser to handle a negotiated auth. I don't know that in this case it actually is or isn't – Bill Jun 19 '16 at 18:58
  • there still is no actual difference, in both cases you are putting your trust in a user device that is not under your control. – oɔɯǝɹ Jun 20 '16 at 8:09
  • In web for this situation you may very well be correct, I used to spend a lot more time in the world of Active Directory where you shouldn't touch the credentials because the OS is capable if doing it more securely and the OS->AD communication has stronger protections and some control over the cleint. This is primarily where my initial reaction comes from I think. – Bill Jun 20 '16 at 15:02
1

There is no huge security weaknesses with them. Actually, a lot of websites (banks notably) are already using web rendered keypads as part of their customer's website authentication mechanism.

While there is still pros and cons, this offers the developers more flexibility than using standard OS input. In particular, the numbers can be presented in random order (preventing shoulder surfing) and it can be made impossible (or at least difficult) for the end-users to copy-paste the password or make the browser remember it.

The main argument I saw against such systems is a direct consequence of the anti-copy-paste feature, since it also prevents the use of password safe software to securely store the password. But this is not a weakness of the HTML rendered keypad per se.

As you said, all attacks valid against the former could also be done against the latter in one form or another.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.