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.
** Changed in: ubuntu-ux
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity8 in Ubuntu.
https://bugs.launchpad.net/bugs/1363214
Title:
[System Settings] [design] allow Passcodes of variable length instead
of just 4 digits
Status in Ubuntu UX bugs:
In Progress
Status in “ubuntu-system-settings” package in Ubuntu:
Confirmed
Status in “unity8” package in Ubuntu:
Confirmed
Bug description:
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'.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-ux/+bug/1363214/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
