On 08/12/2016 07:31 AM, Bryan Richter wrote:
> Since persona is shutting down, we have to migrate everyone to an
> email/passphrase authentication system.
> I did some analysis of the user table to see what that would require.
> I found a few different categories of user, which may need different
> treatments. I broke it down into six different groups[1].
> ##
> ##
> #
> # Group 1: Verified email and modern hash[2]
> #
> (Count: 218)
> "Modern hash" means a stored passphrase we can use in the new system.
> See footnote for more detail.
> #
> # Group 2: Unverified email and modern hash
> #
> (Count: 146)
> Four of them have ident=email, which might mean they joined with
> Persona, and created a password later. (?)

With Persona start and passphrase added, email would have gotten
verified if the pass was added after our verify-the-Persona-emails
action. I think the main reason for ident=email but unverified email is
someone simply manually making their ident be their email and including
email in the sign-up too, so they match, and never verifying (i.e. all
without Persona).

> #
> # Group 3: Verified email, but no modern hash
> #
> (Count: 425)
> 420 of these are people with no hash at all. They must have signed up
> with Persona.
> The remaining five have an old-style salt/hash combo. They're
> basically in the same bucket as people with no hash at all.
> #
> # Group 4: Unverified email, no modern hash, and ident!=email
> #
> (Count: 4)
> Three of these are probably people who signed up with Persona, but
> then changed their email and didn't verify it.
> One is just somebody with an old-style salt/hash combo.
> #
> # Group 5: Unverified email, no modern hash, ident=email
> #
> (Count: 11)
> All of these people must have signed up with Persona and can be
> automatically verified. Then they will become members of group 3.

When we verified all no-hash, no-email accounts and matched their ident
to email, perhaps we left out people who had manually already matching
their email to their ident? Otherwise I don't know why we missed these,
but I agree that any account with no hash at all must have been

> #
> # Group 6: No email
> #
> (Count: 254)
> These poor folks need to add and verify an email address to be part of
> the system.

Based on some cases of comments or profiles or other knowledge, we may
know who a few of these users are, but most will be impenetrable.

> ##
> ##
> I think the first thing to remember is that almost all of these users
> are diehard fans of the project. I won't feel bad about accidentally
> sending one extra email to them, and I don't feel especially worried
> about accidentally verifying a spammer[3] or identity theft victim.
> So.
> The biggest group is #3 (verified but no passphrase), with almost half
> our users. I suggest we send a one-time email to them after we go live
> with master, telling them to use ForgotPassphrase to initialize a
> passphrase.

Makes sense to me, just make the message specific to their case so it's

> The next biggest group is #6 (no email). That's bad. Things aren't
> hopeless, though. Half of them have an email address as an identifier!
> We can perhaps send them an email as well, telling them that now would
> be a good time to formally add an email address to their account. We
> can also just read through the list to see if we recognize any names.


> Next up is group #1 (verified and modern). Great. No action required.

Okay, interjection: if idents must be emails now, we still want to
maintain distinct ident vs email columns in the db? Maybe that's the
easiest and cleanest… Long-term, we'd like to support having multiple
emails available (like one for ident and one for notifications or
something). But if we were starting fresh, would we have the two columns
and make them match or just use ident *as* email?

> Group #2 is a tricky one (unverified but modern). We *could* just
> assume they're all good caring folks, and automatically verify their
> emails. I suggest instead that we send an email now asking them to
> verify their email using the existing system, so that they can become
> members of group #1. The rest would be out of luck.

I agree about sending email to verify.

> I can make everyone in group #5 (unverified, ident=email, no hash)
> become a member of group #3 by automatically verifying their email.
> This is safe to do since they *must* have signed up with Persona.
> For group #4 (unverified, ident!=email, no hash), I think we should
> reach out to them individually. There's just four of them.
> ##
> ##
> There's a really really easy solution to this migration question: blow
> away the entire user table and start over from scratch. Everyone
> creates a new account. (Plan HECK)
> There's also the super fine-grained deeply-considered maximally
> optimal solution, which I've basically laid out above. It would take
> at least a week to do it right (waiting around for users to act after
> we've sent them emails). (Plan ZOWIE)

It doesn't cost us a week of work to just wait for people. It's not a
blocker of anything is it?

> What we *could* do is just import the easy cases (group #1), and send
> a one-time email to everybody else, encouraging them to create a new
> account. (Plan WOW)
> For now, my proposal is to do the fine-grained actions (Plan ZOWIE),
> which would look like:
> 1. Automatically verify group #5
> 2. Send an email to group #2, encouraging them to verify their email
> 3. Send an email to group #6 (those we can reach, anyway)
> 4. Reach out to group #4
> 5. Wait a week
> 6. Import group #1 directly
> 7. Import group #3 directly
> 8. Go live with master
> 9. Send an email to group #3, telling them to use ForgotPassword
> Please vote for — or describe — your favorite plan. :)

I agree with Plan ZOWIE, assuming, as I said, that it isn't lots of work
and the waiting isn't blocking other progress in the mean time.

> Happy Friday,
> -Bryan
> [1]: First of all, there are 1070 total rows in "user". There are 27 emails
> that show up more than once — probably people who forgot and signed up
> again. Of those 27 dupes, there are twelve where one row is
> email-verified, and the other is not. In the groups, I made sure to
> not to double count any of the dupes. There end up being 1058 total
> emails that are considered.

I also have my own list of known duplicates (people who used two
different emails accidentally, forgetting which they used before, but I
know it's the same person who didn't intend to have multiple accounts)

> [2]: What I mean by "modern hash" is a passphrase that uses the secure
> PBKFD1 algorithm we use now. Old versions of Yesod.Auth didn't use it.
> We must have had some accounts created way back in the day that used
> the old bad method. Yesod.Auth "helpfully" still supported the old,
> insecure passwords, so they never got changed. That ends now. :)
> [3]: We did have a few spam accounts created, but they're all in group
> 6 and I'm not worried about them.

Will we keep the establishment stuff even though it isn't used at the
present time in the new master stuff?

Attachment: signature.asc
Description: OpenPGP digital signature

Discuss mailing list

Reply via email to