649495 - lock mozilla account for users who do not login for 6 (or 3) months

Status: RESOLVED INVALID

(Cloud Services :: Operations: Miscellaneous, task)

Description

[Chris Lyon [:clyon]]

We should delete the password hash for a dormant account forcing a password reset and delete their data off our servers for accounts older than 6 months.

Comment 1

[:Atoll]

Pete, two questions - Does LDAP record a "last successful authentication" timestamp for users?  Do you have any suggestions on how we can prevent LDAP users from binding until they reset their password through account portal?

Toby, two questions - Do our applications support a "password reset required" flag in LDAP, that is cleared by account portal when they reset?  Does the sync server implement an API that we can use to clear sync data for a user without requiring their credentials?

Comment 2

[Pete Fritchman [:petef]]

(In reply to comment #1)
> Pete, two questions - Does LDAP record a "last successful authentication"
> timestamp for users?

It does not (and would be too expensive for us, write-wise).

> Do you have any suggestions on how we can prevent LDAP
> users from binding until they reset their password through account portal?

It would have to be a UI thing. 401 + X-Password-Reset header?

Comment 3

[Toby Elliott [:telliott]]

I think the current plan is actually 3 months of no activity in terms of data. 

We don't currently support a reset-required flag, and implementing one would require API changes and client support.

Comment 4

[Toby Elliott [:telliott]]

As to the second question, no API. It would need to be a script.

Comment 5

[:Atoll]

Chris, one question: Do we want to purge sync data after 6 (or 3) months of sync inactivity, whether or not they're using other services such as identity or f1?

Comment 6

[:Atoll]

(In reply to comment #2)
> (In reply to comment #1)
> > Do you have any suggestions on how we can prevent LDAP
> > users from binding until they reset their password through account portal?
> 
> It would have to be a UI thing. 401 + X-Password-Reset header?

We can just set their password to a known constant with some random characters mixed in for safety, which will effectively lock them out until they reset password.

(In reply to comment #3)
> We don't currently support a reset-required flag, and implementing one would
> require API changes and client support.

The client already handles "password changed on server" by asking the user to re-login, and as part of that process we present them with a Reset Password link.  It's not truly optimal, but it's sufficient for the purposes of pruning stale accounts.  Improving reset-required handling is certainly an option, but does not block this request.

Comment 7

[Chris Lyon [:clyon]]

(In reply to comment #2)
> (In reply to comment #1)
> > Pete, two questions - Does LDAP record a "last successful authentication"
> > timestamp for users?
> 
> It does not (and would be too expensive for us, write-wise).

You mean expensive since we would do this per request? 

Can we just do this on a version ping? (I know, we are sending the version on each request now, but the version ping should still be there??) We should figure this out since we need to record this. 

> 
> > Do you have any suggestions on how we can prevent LDAP
> > users from binding until they reset their password through account portal?
> 
> It would have to be a UI thing. 401 + X-Password-Reset header?

We should have something like this built in in case we need to force password resets.

Comment 8

[:Atoll]

(In reply to comment #7)
> We should have something like this built in in case we need to force password
> resets.

+1. Could you file this specific request as a separate bug under Sync UI?

Comment 9

[Toby Elliott [:telliott]]

(In reply to comment #7)

> Can we just do this on a version ping? (I know, we are sending the version on
> each request now, but the version ping should still be there??) We should
> figure this out since we need to record this. 

Why do we need to record this? Isn't last-data-modification sufficient?

Comment 10

[:Atoll]

(In reply to comment #9)
> (In reply to comment #7)
> 
> > Can we just do this on a version ping? (I know, we are sending the version on
> > each request now, but the version ping should still be there??) We should
> > figure this out since we need to record this. 
> 
> Why do we need to record this? Isn't last-data-modification sufficient?

"Last data modification" implies Sync.  Identity users don't necessarily have to modify their identity to use our service.  Not sure we even have a concept of "data" for F1 users.

I think this is a multibug, and propose splitting into two bugs: One bug for "lock dormant services accounts", one bug for "purge stale sync data".

Comment 11

[:Atoll]

Moving the "purge stale sync data" issue to bug 592399.  Keeping this bug for "lock dormant services accounts".

Comment 12

[Joe Stevensen [:joe]]

Services, what is the status on this bug?

Comment 13

[:Atoll]

(In reply to Joe Stevensen [:joes] from comment #12)
> Services, what is the status on this bug?

Services Ops has no actions to take at this time. I can't speak for Eng, but I don't have enough information to ask them yet, either. This bug is at the "trying to negotiate infrasec requirements" stage. There are unanswered questions above that affect whether or not we can even do this, and whether or not it will require Eng to be involved as well.

Comment 14

[Toby Elliott [:telliott]]

Is this a sync bug any more? the sync-purge part is, but I think that the lock portion is now the purview of BID. What does locking your account mean in the new context? That given a valid BID assertion we'll deny them a token? That seems kind of weird, and I don't think there's a security concern there.

Comment 15

[Allison Naaktgeboren :ally]

I might point out that legal is pondering writing such a policy into the new ToS for sync 2.0, so this is an open concern, but Im not sure to what extent this bug is actionable?

Alex?

Comment 16

[:Atoll]

(In reply to Chris Lyon [:clyon] from comment #0)
> We should delete the password hash for a dormant account forcing a password
> reset and delete their data off our servers for accounts older than 6 months.

This incomplete meta-bug (with no actionable work) does not permit work and is not actionable.

We cannot implement this feature for pre-BrowserID services.

Post-BrowserID, only the BrowserID primaries have password hashes.  Mozilla is just one of many primaries.  We are incapable of satisfying the original pre-BrowserID request, as we have no control over the behavior of non-Mozilla primaries.

I'm closing this mis-filed meta bug as RESOLVED INVALID. Please do not reopen it without discussing with Operations out-of-band first.

(In reply to :Ally Naaktgeboren from comment #15)
> I might point out that legal is pondering writing such a policy into the new
> ToS for sync 2.0, so this is an open concern, but Im not sure to what extent
> this bug is actionable?

Any policy alterations related to data retention or user lockout policies should begin life as a metabug in the BrowserID product, assigned to the product manager for BrowserID. That PM will need to coordinate work between Legal, Engineering, and Operations to ensure that the new policy satisfies Legal requirements and is also technically feasible to implement.