Comment 8 for bug 1363214

Currently there is a constant 5-minute delay after 5 failed passcode attempts. So brute-forcing a randomly-chosen 4-digit passcode would take, on average, (10⁴÷2) attempts ✕ 1/5 timeouts/attempt ✕ 5 minutes/timeout = 16 hours 40 minutes, not counting the input time. If we had followed the design proposed in bug 1347907, with a constant 1-hour delay after 5 failed attempts, the time required would average (10⁴÷2) attempts ✕ 1/5 timeouts/attempt ✕ 1 hour/timeout = 8 days 8 hours, not counting input time. Alternatively, we could start with a 5-minute delay and double it after each five attempts; if my maths is correct, that would result in average time required somewhere in the vicinity of (5 minutes ✕ (1 – 2^(10⁴÷2))) ÷ (1 – 2) ≈ 9.8×10¹⁴⁸⁹ times the age of the universe.

Now, this bug report is not about delays. But the point is that we don't need hidden-length passcodes -- or even longer passcodes -- to be able to increase, as much as we want, the effort required to brute-force a passcode. We could increase security much more effectively by implementing increasing timeouts, and preventing people from choosing lazy passcodes like 1111 and 1234.

Having said all that, I'm happy with allowing variable-length passcodes. However, that does not mean requiring an Enter key at the end of the passcode is either necessary or desirable. It is not necessary, because as demonstrated, there are other ways to increase the brute-force effort as much as we want even while the attacker knows the passcode length. And it's not desirable, because it substantially increases the time required for legitimate passcode entry. For example, if you have a four-digit passcode, requiring Enter at the end would increase the time required by a little more than 25%. (More, because occasionally you will have mistyped it.)

There's also a practical reason not to allow passcodes of arbitrary length: the visual design of the unlock screen assumes that the passcode will not scroll off the screen edge. We could present the passcode in a scrollable field like a passphrase, but passcode and passphrase entry looking substantially different reduces confusion.

So, unless there are understandable objections, I plan to design for passcodes that can be from 4 to 8 digits, where the number of digits is visible whenever you are prompted.