# Does multiple numbers per button have an effect on security?

I recently came across an electronic deadbolt like this:

The keys have multiple numbers per button, `1|2`, `3|4`, `5|6`, `7|8`, `9|0`

Is there any way that this increases the security of the electronic lock? It seems like having two numbers per button dramatically reduces your possible entropy, since you now have 5 bits instead of 10 bits, right?

Is this just a matter aesthetics/cost-cutting over security?

• Not an answer to your question, but it is not 5 bits instead of 10. It is log2(5) = 2.32 bits per digit instead of log2(10) = 3.32 bits per digit. Halving the number of options means removing one bit. – Anders May 3 '16 at 14:58
• Do you know for a fact that both numbers on the button are indistinguishable? I wonder from looking at it, if you need to press the `12` button twice or something to get the `2`, in which case you could be back up to 10 possibilities. It's not 10 bits by the way, if you're talking entropy, it's between 3 and 4 bits per number in your PIN (at best, assuming a completely random PIN). – Ben May 3 '16 at 15:03
• Here's the user guide. The second page makes it clear that yes, it is just 5 buttons - nothing clever like "tap once for 1, tap twice quickly for 2, tap twice slowly for 11".. – Rawling May 3 '16 at 17:57
• Its basically a 5 button lock that allows people to abuse their birthday or pin code for a password. – Dennis Jaheruddin May 3 '16 at 18:06
• @DennisJaheruddin: I have seen at least one such lock where the left number requires pushing briefly, and the right number requires holding a bit longer. – supercat May 3 '16 at 20:24

No, assuming equally long passcodes, having fewer buttons cannot increase security in any way.

Depending on how the passcodes are chosen, and whether or not the buttons are regularly cleaned to remove smudges*, it (might or) might not decrease security significantly, but reducing the number of buttons certainly cannot make the lock more secure.

So you're probably right: it's just done for aesthetics and/or to save costs. As for why the buttons on your example lock are double-numbered, Dennis Jaheruddin probably nailed that in the comments:

"It's basically a 5 button lock that allows people to abuse their birthday or pin code for a password."

With just five digits to choose from, you can't pick an easily memorizable passcode like `31121976` or `31415926`. With each button labeled twice, you can. (Whether that's good or bad for security is debatable; arguably, if users couldn't pick codes like that, many of them would either fall back on something even less secure like `12341234`, or just write down their passcode on a post-it note. But from a usability perspective, it's definitely a win.)

*) Since the issue of smudge attacks has already been brought up, let me briefly note that they don't affect the general conclusion that fewer buttons cannot be more secure. Specifically, let us assume that the passcode is known to be digits long, and uses k buttons out of a total of n, and consider the following two extreme cases:

1. The buttons are kept clean, so that an attacker can't tell which buttons are part of the passcode. In this case, there are n possible passcodes, of which the attacker must on average try half before finding the correct one.

2. The buttons are never cleaned, and accumulate smudges that eventually allow an attacker to tell exactly which k buttons are used in the passcode. In that case, the unused buttons become completely irrelevant, and so the attacker knows that there are only at most k possible passcodes (of which they, again, on average need to try half to find the right one) regardless of n. (The actual number is a bit fewer than k, since codes that only use less than k different buttons can be ruled out, but it still doesn't depend on n at all.)

Reality is typically somewhere between these two extremes: an attacker might be able to observe some wear and smudging on the buttons, and thus get some information on how likely each button is to be part of the passcode, but unless the keypad is really worn and/or filthy, they probably can't be 100% sure. Thus, typically, having fewer buttons does decrease security somewhat, but probably not quite as much as a naïve calculation ignoring smudging would lead one to expect (since it has already been reduced by smudging).

Of course, one further way in which reducing the number of buttons can weaken security, even under the heavy-smudging scenario above, is if two numbers used in the passcode get mapped onto the same button on the smaller keypad (thus reducing both n and k). For randomly chosen passcodes, this starts to become an issue (due to the birthday paradox) when n < ², and will definitely be an issue when n < . Still, this observation only strengthens the conclusion that, smudged or not, fewer buttons can't ever be more secure (and may be less).

• The math is wrong as there's an order of quantification issue. If you fix the security of a password \$n^l\$ first, then all but 2 passwords over 2 buttons use all the buttons and smudging (where smudge is binary) diminishes the security none, whereas for large number of buttons there will be \$n-k\$ unused buttons which and we lose security. – djechlin May 3 '16 at 21:58
• @djechlin: Sure, but almost all the passcodes on the n button keypad will use at least two different buttons as well, and therefore, even with smudging, will be at least as hard to guess as any passcode (of the same length) on a two-button keypad. – Ilmari Karonen May 3 '16 at 22:52
• ...but if you hold target password strength constant first, instead of target length, then more buttons + knowledge of which buttons appear in the password becomes less secure. – djechlin May 3 '16 at 23:40
• @djechlin: Ah, I think I see what you mean now: you're talking about increasing the passcode length ℓ as you decrease the number of buttons n so as to keep n^ℓ (approximately) constant. That does work, but only at the cost of making the passcode harder to remember -- the way the human brain works, the difficulty of remembering a random sequence of items is roughly proportional to its length, and nearly independent of the number of choices for each item, provided that all the items are things that each map to a single "concept unit" in our mind (like digits, letters or familiar words). – Ilmari Karonen May 3 '16 at 23:56
• ... Thus, I was implicitly assuming that ℓ is already as high as we can practically make it, and that significantly increasing it to compensate for a lower n is not feasible. (If we could easily make the passcode longer, we should do that anyway, regardless of the number of buttons available.) – Ilmari Karonen May 3 '16 at 23:59

Think about the technical implementation, not about the user or what's painted on the buttons: it's a keypad with 5 buttons. In order to unlock the device, it needs a sequence of those 5 buttons (however many presses of those 5 button it allows).

More buttons would make it harder to brute-force the combination. Imagine having only 2 buttons, or imagine having 20. More buttons would mean more possible combinations, more combinations means harder to bruteforce.

I can imagine one way where having fewer buttons might increase security: smudges. If you had 20 buttons, over time, the few buttons you used would appear to be used, thereby reducing the number of possible buttons to try, including being able to deuce the number string ("123456") that the user needed to remember. Fewer buttons (with multiple numbers per button) means that smudges are less meaningful (they are all smudged), and a reduced possibility of deducing what the memorized number sequence was. But, this is only one aspect of security, and one I might not value too highly on a residential house lock.

• That was pretty much what prompted my question. I looked at the lock and said, "Wait a minute... there aren't really 10 digits here, just the 5..." – Wayne Werner May 3 '16 at 15:04
• Assuming passcodes of equal length, the only information an attacker can learn from smudges is what eliminating the unused buttons (or merging them with others) would directly give them anyway. The only way in which fewer buttons can be more secure, smudges or no smudges, is if the passcode length is increased to compensate. – Ilmari Karonen May 3 '16 at 15:59
• I think smudges would only matter if each key was used for both numbers (i.e. press twice for second number). Then a smudge on the first key would only narrow it to a 1 or 2, as opposed to if there were two separate keys where it would narrow it to only 1. – DasBeasto May 3 '16 at 17:59
• On a keypad with 20 buttons, the oft used buttons will get smudges and the search space would be reduced. With fewer buttons, you increase the chance that all buttons would be smudged, thereby potentially reducing wear/smudge patterns as a way of reducing the search space. – schroeder May 3 '16 at 18:00
• @schroeder Having all buttons smudged at approximately the same rate does reduce the value of smudges for reducing the search space. However, by cutting the total number of buttons down the search space is already dramatically reduced. The only way to reduce the impact of smudges on the search space, without reducing the overall possible key space is to make it so that each button can represent more than one value. (e.g.: Multi-Tap) However, such systems likely suffer from increased susceptibility to shoulder-surfing. – Iszi May 3 '16 at 19:58

Not by itself.

The total number of combination is XY where `X` is the number of buttons, and `Y` is the length of the combination.

For example:

• a 6 digits combination of 5 buttons is 56 = 15 625 combinations.
• a 4 digits combination of 10 buttons is 104 = 10 000 combinations.

If you don't know the length of the combination, the number of buttons is irrelevant to security. You could have just 2 buttons.

• But you can't have just one button .... The problem with your assessment is that it only holds if the number of digits is unknown or unknowable. With products like this, it is trivial to know the length, which makes fewer buttons a problem.. – schroeder May 3 '16 at 17:24
• You can have just one button, the "code" is the number of repeated button presses you make before pausing. Though it does give a very small search space unless you're willing to press the button an awful lot of times. Though I guess you could have a multi "digit" code. I.e. press the button 7 times, pause, press 13 times, pause, press 3 times. – Johnny May 4 '16 at 4:48
• Morse code of course was invented because a telegraph has only one button. – MSalters May 4 '16 at 7:59

Wouldn't it depend on what actually happens when you want to input the second number on each button (I assume you press it twice)?

Case 1: Two keystrokes on the same button simply outputs two of the same digit, similar to pressing the same button twice on a single number button keypad, then the result is just a reduced number of buttons, but longer code. Instead of referring to the buttons by their numbers, you can refer to them by which button it is (i.e. button 1, button 2...... button `n`). The total number of combinations as I'm sure you're aware is nl, where `l` is the length of combination. Clearly l has a higher affect on the total number.

Case 2: Two keystrokes on one button outputs a single digit (the second number on the button) then the number of buttons is 10, but the length changes and is not the same as the number of inputs!

It depends on the maximum number of keystrokes allowed. Let's say 10 keystrokes is the maximum.

Case 1:

5 buttons, 1 digit per keystroke, results in a length of 10.

510 = 9 765 625

Case 2:

5 buttons, 1 digit per 1 or 2 keystrokes, results in a maximum length of 10 and minimum of 5. But remember that you actually have 10 possible outputs.

If you use a combination that only uses the first digits of the buttons:

510 = 9 765 625 - the same!

If you use a combination that utilizes all of the second numbers only:

105 = 100 000 - much lower

So if the mechanic for creating the second number is as above, and the combination has a maximum number of keystrokes then security is lower.

But if the combination has a maximum number of digits with endless keystrokes, then the result is very different.

With a maximum of 10 digits:

Case 1:

Same as above: 510 = 9 765 625

Case 2:

Now you have 5 buttons but number of keystrokes is irrelevant so you effectively have 10 buttons.

1010 = 10 000 000 000

It may seem like much more, but this is the same as a standard 10 button (0-9) lock. As a conclusion, I could have simply compared the final case with the standard one and said the most security you can achieve with this lock is the same as the 10 button lock. Truth is I didn't know and kind of figured this out as I wrote it! Hope it gave light to something.

• This is a point to make - if you're able to input the numbers separately with multiple presses, it could reduce people's ability to interpret your password from marks on the buttons. However, I believe the lock in question doesn't actually have multiple possible inputs per button, and instead just has multiple labels. – Samthere May 4 '16 at 10:06

For a given length, the multiple numbers per button make it significantly harder, though by no means hard, for a casual soulder-surfer to memorize the password as they see being typed.

• This makes no sense, whatsoever. Forget what's printed on the face, and simply assign A, B, C, D, E or 1, 2, 3, 4, 5 to the 5 buttons, or memorize the pattern (of only 5 possible buttons). You might not know what password the user thinks about in his head, but that's not the point. – schroeder May 4 '16 at 15:04
• @schroeder What you just described seems "significantly harder, though by no means hard", then memorizing single digits neatly printed on each button. An even better approach would be to consider only the leftmost digit of each button. But a casual attacker with an unexpected opportunity might not think of any of that on the spot, and get lost trying to memorize "3 or 4, 7 or 8, ..." – Emilio M Bumachar May 4 '16 at 16:42
• Who memorizes strings? It's the pattern that would be memorized. – schroeder May 4 '16 at 16:47