927482 - [B2G][Lockscreen][Passcode] Slow resetting when entering an incorrect passcode for many times

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[sarsenyev]

Attachment: Video_attachment

Description:
When entering an incorrect passcode for many times, the passcode field is very slow on resetting the incorrect result.

Repro Steps:
1) Updated Buri BuildID: 20131016040202
2) Open "Settings" from the home screen
3) Navigate to "Screen lock" menu under "Privacy & Security"
4) Toggle the "Passcode lock" to "on" position
5) Set a passcode and confirm with "Create" button
6) Press the "power" button for sleeping option
7) Press the "power" button again to wake up the phone
8) Tape an incorrect passcode for 7-10 times

Actual:
The incorrect passcode is resetting very slow

Expected:
The incorrect passcode resetting quickly as for the first time

Environmental Variables:
Device: Buri v1.3 Central Mozilla RIL
BuildID: 20131016040202
Gaia: 3d4f1107e6e91e5f5649edc0f2565ac837111d7d
Gecko: 9f63bbc00527
Version: 27.0a1
Firmware Version: US_20130912

Notes:

Repro frequency: 100%
See attached: video attachment

Comment 1

[sarsenyev]

Same issue with the latest Buri Aurora 1.2 MOZ RIL

Device: Buri v1.2 Aurora Mozilla RIL
BuildID: 20131016004005
Gaia: 5ef3535021286ccab7af639897feaaf5955720a0
Gecko: 75b0b968f3ed
Version: 26.0a2
Firmware Version: US_20130912

The issue doesn't reproduce on the latest Leo 1.1 
Device: Leo v1.1 Mozilla RIL
BuildID: 20131016041201
Gaia: 680f3b86b1e4ff1411ece6ba397b8b0e56b4b31c
Gecko: 3cbd02abb840
Version: 18.0

Comment 2

[sarsenyev]

Regression window:

Doesn't reproduces on Buri 1.2 Master build
Device:  Buri Master v1.2 Mozilla RIL
BuildID: 20130912040201
Gaia: 9ffd2899eb91388f7fc1ce6f7a895a6f5f922c05
Gecko: a98569f21abe
Version: 26.0a1
Firmware revision:US_20130912

The issue reproduces on:
Device:  Buri Master v1.2 Mozilla RIL
BuildID: 20130913040201
Gaia: 8ccb741b6adcfe9a78b842c17e5874242c0f8b86
Gecko: b9029b1de410
Version: 26.0a1
Firmware Version: US_20130912

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I believe this is a "feature" implemented in bug 888911. If that not correct please reopen this bug.

Comment 4

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #3)
> I believe this is a "feature" implemented in bug 888911. If that not correct
> please reopen this bug.

That's umm...strange as a security approach, but okay. Did anyone from UX review this?

Comment 5

[Hubert Figuiere [:hub]]

This is actually quite a common approach to slow down the brute force attack for password. Even the UNIX login does that. Android pattern lock does that. Etc.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Hubert Figuiere [:hub] from comment #5)
> This is actually quite a common approach to slow down the brute force attack
> for password. Even the UNIX login does that. Android pattern lock does that.
> Etc.

Fair enough. I'll pull the needinfo then.

Comment 7

[Stephany Wilkes]

UX has not reviewed this, nor were we even aware of the feature in bug #888911. We should review this. An increasingly lengthy delay may not necessarily be clear to the user as to *why* it's happening, which it would be nice to check for. 

We don't generally just say "common approach" justifies new UX (as one person points out what's a common approach on iOS, while for someone else it's Android, while for someone else it may be something unrelated to mobile devices). Given the amount of work that has gone into the lock screen in the past release, I'd like to review this.

Comment 8

[Jason Smith [:jsmith]]

Thanks Stephany. I'm going to reopen this given your comment to evaluate the UX make improvements in alignment with what UX desires.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #8)
> Thanks Stephany. I'm going to reopen this given your comment to evaluate the
> UX make improvements in alignment with what UX desires.

Meant to say - evaluate the UX improvements we need to make to be in alignment with what UX wants in this implementation.

Comment 10

[Stephany Wilkes]

I've reviewed this with Francis Djabri, a member of the UX team, and the product owner for System Front-end, Peter Dolanjski. Here is our compiled feedback.

First, in future, module owners should consult with UX for something this user facing, for review before landing. Everything doesn't need a spec, but UX input should be given for something like this.

UX *is* a fan of this feature for the purpose of mitigating brute force attacks.  BlackBerry used to do this by forcing the user to type "blackberry" after x incorrect password attempts.  This would break up the entry to help discourage such attacks.

But the implementation here needs some usability improvements.  The key missing piece is informing the user why there is a delay.  When a delay is introduced, we need to tell the user "incorrect password, try re-entering in x seconds" (potentially with a count down) or something to that effect. 

If we can add some UX for this, we suggest also considering how we might present a prompt that will let the user know that their device will be wiped after x number of failed attempts.  In a stolen device scenario this is the only way to stop brute force attacks completely.  This feature is already in the Systems Front-end backlog. It's not top priority, but they may deliver it at some point.

Comment 11

[Greg Weng [:snowmantw][:gweng][:λ]]

On the recently (2.0+) master this is unable to reproduce. Maybe you can check it again and we can close this old bug.

Comment 12

[Jason Smith [:jsmith]]

The person needinfo'd no longer works here, so I'm switching to qawanted.

Comment 13

[Pi Wei Cheng [:piwei] (inactive)]

Issue is still reproducible on today's Buri 2.1 master. Note step 8 of original repro is:

> 8) Tape an incorrect passcode for 7-10 times

Following the above quoted step will reproduce the bug. 

Tested on:
Device: Buri
Build ID: 20140618040513
Gaia: 431aed0a7c7560c6eacd35ea69aa0a7a4ebe72c7
Gecko: 37f08ddaea48
Version: 33.0a1 (2.1 - Master) 
Firmware Version: v1.2device.cfg

Comment 15

[BMO Automation]

Firefox OS is not being worked on