touch-packages team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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