[System Settings] [design] allow Passcodes of variable length instead of just 4 digits

[Jamie Strandboge]

Currently when setting a Passcode on the device, it must be 4 digits. This is artificially limiting. Other platforms (eg Android) allow longer Passcodes. It has always been my understanding that we should support Swipe, Passphrase and Passcode where Passphrase and Passcode can be arbitrarily long.

However, once longer Passcodes are supported, we will have to add an Enter key. Right now, the lockscreen checks the Passcode once 4 digits are added so that you don't have to press Enter. I guess this was done for usability, but would be a security issue because an attacker can easily determine the Passcode length, which makes it easier to for an attacker to guess the Passcode. Eg, if I have a 5 digit Passcode set, then an attacker need only type '11111' and know that the Passcode is only five characters. Now, a Passcode isn't strong to begin with and an automated attack could rather quickly brute force Passcodes, but we shouldn't make it easier for someone manually trying to guess the Passcode.

The passphrase lockscreen prompt correctly allows variable length passphrases and requires you to press Enter.

I suggest moving the 'X' up t the left of '0' and an Enter symbol to the rigth of '0'.

[Michał Sawicz (saviq)]

This (4 digit and auto-confirmation) was an explicit and reiterated design request. Added ubuntu-ux for reflection then.

FWIW the lockscreen will only allow you typing the PIN a few times before getting locked up for 5 minutes (or reboot...), that should help slightly with the robustness of the lock.

[Olga Kemmet (olga-kemmet)]

I understand the concern, however it is up to the user in the end to set either a PIN (less security) or a passphrase (more security).
We just need to educate users about what each setting so that he can make a decision.

[Jamie Strandboge (jdstrand)]

It is more than just education. Some users may find passphrases on devices too cumbersome and want to use a PIN, but a 4 digit PIN is artificially limiting. There is no reason why it couldn't be 8 characters or more. Having a minimum PIN length of 4 seems reasonable.

[Michael Zanetti (mzanetti)]

Confirming that I always used pins longer than 4 characters. But I don't want to fiddle with the tiny OSK to enter a passphrase when I'm on the go with my phone. I fully support Jamie's opinion on this matter.

[Antti Kaijanmäki (kaijanmaki)]

updated PIN -> Passcode

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Riccardo Padovani (rpadovani)]

I totally agree with Michael and Jamie: a pin is definitely better then a passcode to insert because you have bigger buttons: however, a 4 long digit pin is pretty useless, also because there is no limit on how many tries could be done

[Matthew Paul Thomas (mpt)]

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.

[Jamie Strandboge (jdstrand)]

4-8 digits is fine and what Olga, Michael and I discussed several weeks ago.

[Michael Zanetti (mzanetti)]

@Matthew:

I think we have to agree to disagree that having to press the enter key "substiantially" increases the required time to enter the pin. 25% of very short is still quite short :) Also the variable pin length would allow you to enter a 3 digits pin if you don't care about security and really don't to press 5 keys :)

Now on a serious note, if we allow variable pin lengths we have to use the enter key, because we can't get the password length from PAM, we'd need to store it externally which is something I'm sure Jamie disagrees with and is also not really feasible from a technical point of view.

Regarding the scrolling field, that's also not really true as we use the exact same visuals already for the passphrase and the passkey logins, both cope with a flexible amount of letters/digits without having to scroll. The passphrase one already allowing an infinite length (It shrinks the dots and reduces spacings between them as the passphrase grows).

Note that the passkey screen is also used for SIM PIN/PUK entry which allows 4-8 digits. If you have a SIM PIN enabled, I find it quite confusing that you get 2 (3 on dual sim) unlock screens, one after another, all looking exactly the same, except the first ones requires you to confirm the ping with enter, the last one doesn't.

[Michael Mess (michael-michaelmess)]

I would suggest the following solution:

---------------
   Enter
Device PIN

(1) (2) (3)
(4) (5) (6)
(7) (8) (9)
      (0)
(X) (<) (/)
---------------
The numbers could be grey or blue.
The (X) button is red and locks the screen.
The (<) button is yellow deletes the last cipher of the entered PIN
The (/) is green and acts as Enter button. Note: the "/" here should of course really be a tick character.

Give the user the choice (Settings) how to input the PIN:
Mode 1) The current behaviour (No enter required), but you can guess the length of the PIN just by typing arbitrary numbers.

Mode 2) Entering the correct PIN matches and auto-enters, but the wrong pin won't tell you there is no match possible by entering more characters. Only pressing (/) will tell you that the PIN is wrong.

Assuming the pin is 12345
Entering 23456 does not match and you can enter any amount of more ciphers. Pressing (/) will tell you that the PIN is wrong. You can delete characters with (<).
Entering 12345 matches and immediately unlocks the screen.

Mode 3) Entering the correct PIN does not auto-enter, you have to press (/) always to let the dialog check if the entered PIN is correct.

[Michael Mess (michael-michaelmess)]

In the PIN PAD example above the (0) should be centered in the row as it is already now in the lock screen. I have just entered too many leading spaces there.

The number of digits to be entered as PIN should be at least 4.

When entering 112 and (/) the dialog should ask if it is intended to dial an emergency call. But it should not do that too easy as I don't like to dial 112 by accident when the mobile phone is just in my pocket.

[Launchpad Janitor (janitor)]

[Expired for unity8 (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for ubuntu-system-settings (Ubuntu) because there has been no activity for 60 days.]