1675284 - Lockwise does not report website breaches or alerts

Status: RESOLVED FIXED

(Firefox :: about:logins, defect, P2)

Description

[sriram]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Enable "Show alerts about passwords for breached websites" in Options / Privacy & Security.
Go to "about:logins"

Actual results:

Breach alerts and the Sort by: "Alerts" is not displayed.

Expected results:

Breach alerts and sorting by "alerts" should be enabled.

Comment 1

[Sam Foster [:sfoster] (he/him)]

(In reply to sriram from comment #0)

Expected results:
Breach alerts and sorting by "alerts" should be enabled.

Do you know you have a login for a breached website? We only show the breach alerts and the sorting option when there are one or more logins whose modified dates pre-date the time of a breach.

To manually create a known-breached login to verify, you can use about:logins to create a new login for a breached site e.g. https://eatstreet.com, use about:support to find the profile directory. Then, close the browser, open the logins.json from your profile (take a copy as a back up first), find and edit the "timeCreated" and "timePasswordChanged" values to 1556773200000 (which is 1 day before that site was breached). When you use that profile again and view about:logins, you should now see the sort by "Alerts" option, and the breach icon and messaging on the eatstreet.com login entry.

You should also check in about:config that the preference "signon.management.page.breach-alerts.enabled" is set to true. It should be enabled by default for all firefox release channels.

Comment 2

[sriram]

No breach notification upon adding the entry (https://imgur.com/a/CgQN7fp). When I try to log on to the site and then check about:logins, I do get the breach notification, but after a restart the breach notification is gone again. I have tried creating a new profile and syncing, but I get the same behavior.

I do have another profile that is not synced and there the breach notifications and vulnerable password notifications persist across restarts.

Comment 3

[Sam Foster [:sfoster] (he/him)]

Attachment: about:logins screenshot from comment 2.

Comment 4

[Sam Foster [:sfoster] (he/him)]

We've not been able to reproduce this yet. If you have a new/clean profile with the eatstreet.com login, looking at the logins.json from that profile might have some clues - if you are able to share that?
Can you tell us if there is any exception logged in the browser console (main menu > web developer > browser console) when you reproduce this issue (i.e. load about:logins with an entry that should be marked as breach, but isn't.)

Comment 5

[sriram]

I create a new profile, added the eatstreet.com login, and adjusted the time in the logins.json. It reported the breach properly and the notification persisted across restarts.

I then copied key4.db and logins.json from my main profile (with the problems) to the new profile, and it exhibited the same problem.

This is what is reported in the web console:

Error: Can't find profile directory. 2 XULStore.jsm:66:15
load resource://gre/modules/XULStore.jsm:66
XULStore resource://gre/modules/XULStore.jsm:24
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIIOService.newURI] LoginBreaches.jsm:78

I will now try to start removing entries from my logins.json to see if there is one particular entry that is causing problems.

Comment 6

[sriram]

Attachment: logins.json

minimal json that causes bug

Comment 7

[sriram]

ok I've narrowed down the offending entry and am attaching a minimal logins.json

Comment 9

[Simona Rosu [:srosu], Ecosystem QA]

I also managed to reproduce this issue. I tried to create breached accounts using the steps from comment 1 for the following websites: https://www.universityofcalifornia.edu, https://www.shortediti,on.com, https://www.sephora.com.au, https://ordersnapp.com, https://www.dropbox.com, https://www.audiusa.com, https://eatstreet.com, and https://www.teespring.com. But, it seems that only the logins created on https://www.dropbox.com and https://eatstreet.com websites are recognized as breached.

Comment 10

[mrmbernardi]

I'm getting some weird behaviour, "Vulnerable Password" alerts do not show on my two home machines. They do show on my work machine. On one of my home machines I was able to get the "Website Breach" alert to show for https://eatstreet.com as per Sam's instructions.

All machines are using version 93.0

Comment 13

[sidikul]

I also managed to reproduce this issue. I tried to create breached accounts using the steps from my channle https://www.youtube.com/channel/UCrnA-MDgpB73aaNkxYRfy6Q/featured

Comment 14

[Sergey Galich [:serg]]

Dropping an idea here for exploration.

Sometimes users got confused with web site breach alert, they expect an alert but it doesn't happen. Quite often this is because login was modified after the site was breached. But this is not so obvious.

The solution is to add a menu entry to manually check login for breaches. Once invoked, it can tell user one of:

• there are no known breaches to this site
• there was a breach on specific date, but user's login was modified later
• there was a breach on specific date and user's login is not updated

That will help to reduce confusion without permanently staining entries with "it was breached 30 years ago" type of messages.

Comment 16

[sriram]

No, I think if you look at the json I posted above, the website breach checking code crashes or errors out whenever it encounters a non http/https hostname, and doesn't continue checking other entries down the list.

Comment 17

[Sergey Galich [:serg]]

Attachment: Bug 1675284 - Lockwise does not report website breaches or alerts. r=dimi!

Comment 18

[Sergey Galich [:serg]]

:sriram,

Thank you for pointing at that detail. Indeed it's a coding error, fix is coming.
I'll split manual breach check idea into a separate bug.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b5d30b753a4
Lockwise does not report website breaches or alerts. r=dimi,MattN

Comment 20

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/6b5d30b753a4

Comment 21

[Alice Varro [avarro], Ecosystem QA]

I have verified this issue using the latest Firefox Nightly 101.0a1 (Build ID - 20220419214607) on Windows 10x64 and macOS 12.3.1 by creating breached accounts for the following websites: https://www.universityofcalifornia.edu, https://www.shortedition.com, https://www.sephora.com.au, https://ordersnapp.com, https://www.dropbox.com, https://www.audiusa.com, https://eatstreet.com, and https://www.teespring.com , but it seems that only the logins for https://www.dropbox.com and https://eatstreet.com websites are recognized as being breached.
@Serghey, could you please provide us some more information about how we can verify this issue on the websites listed above that are not recognized as breached?

Comment 22

[Sergey Galich [:serg]]

Alice, this particular bug was due to the chrome://grwatcher URL in the first entry, it was crashing breach detection loop and never tried to verify other sites.

I can see dropbox.com and eatstreet.com in breaches list here https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/fxmonitor-breaches/records but I can not find universityofcalifornia.edu there. Even though HIBP reports it as breached https://haveibeenpwned.com/api/v3/breaches?domain=universityofcalifornia.edu

Lets talk offline and figure out what else is going wrong, this seems to be beyond scope of this bug.