A mechanism is needed to invalidate account recovery codes. - Meta

Monica replying to Paul White

True, and some people enter bogus ones or disposable ones.  As a mod I saw plenty of that from people who thought they were being clever about socks...

Paul White replying to Monica

That's true to a point, but you still have to enter an email address (a made-up one will do) to contribute to SE as an unregistered user.

Monica replying to Paul White

Technically email addresses and (thus) account recovery are optional on SE; it's the difference between registered and unregistered accounts.  We don't have to require email addresses, but if a user is willing to hand one over in exchange for a means of recovering an account (or, you know, for opt-in notifications), let's not reject that on privacy grounds -- the user chose to give it to us, which is different from us demanding it.

Andriy M

Ah, that's right, I didn't think that it was only the login name and the picture that the owner could delete. Of course, since the account stays there, all other imports related to it would just link the new posts to the thrown away (but nevertheless existing) account. All is clear now, thanks for the explanation.

Jack Douglas

the only manual process then being the association process when someone claims to be the rights holder

Jack Douglas

the reasoning here is to shift the burden onto the person making the request — give them the power to disassociate rather than offering to do it for them via a manual process

Jack Douglas

If they want to disassociate 'per post', I was suggesting a 'disassociate' button on each post might be the most appropriate

Jack Douglas

In that scenario it isn't possible for a new account to be imported when another question/answer is imported because the original account still exists, and the link to SE is still there (and only one such link is allowed) — new imported posts would just get attributed to that now-anonymous account

Jack Douglas replying to Andriy M

imported account have an internal (ie not publicly visible or changeable) link to the SE user ID. If someone claims they are that real person and wants disassociation, that's the scenario I have in mind. In that case, if they can prove they are the rights holder, they can be give access to the account. They can then change the username to null and clear their cookies (thereby losing access again)

Andriy M

I realise I'm probably raising an entirely different issue from what was being discussed. It's just something that came to my mind as I was reading the messages.

Andriy M replying to Jack Douglas

Not sure what scenario you have in mind there. Do you mean someone's account gets imported, then compromised, and _then_ the person behind the imported account finds out about both the existence of the account and its being compromised? I don't know how likely that can be, but suppose the person in question does those four steps you've mentioned. Surely it's likely that their account can be – even inadvertently – re-imported, which could be rather confusing for the person in question, even though the re-imported account would probably have different internal credentials (auth token and such). I'm not even talking about the possibility of a new compromise, just the fact that someone deleted their account, but lo and behold, it's there again.

Jack Douglas

:P

Paul White

Well get on it. I really don't know what you do all day.

Jack Douglas replying to Paul White

not yet

Paul White

An answer doesn't generate a ping to the querent?

Jack Douglas

@Caleb pinging you in here to let you know I answered

Paul White replying to Jack Douglas

I don't know your schema but I would think every change would have some sort of history to it.  
Pretending one didn't ask the question one wants to answer seems a little dishonest to me.

Jack Douglas replying to Paul White

maybe but that would make it harder to undo which I guess might be necessary. burner accounts seem like they might be useful in all sorts of ways — I think selfies might sometimes be better is the question is from a burner

Jack Douglas replying to Paul White

sure JIT is early enough for most features

Paul White

I'm not really super interested in this until the need arises. I mentioned it as an aside.

Paul White replying to Jack Douglas

Would there be a benefit in having a 'special' account e.g. anonymous to hold such questions?

Jack Douglas replying to Paul White

that makes sense. a ' disassociate' button might be the lowest effort way of satisfying that — it would just create a burner account for the post perhaps?

Paul White replying to Jack Douglas

For all posts, yes, but people have the right to be dissociated per post I think

Jack Douglas

idk how this will work in practice, it just seems like it might be easier for us than SE

Jack Douglas

(1) prove you are the person (somehow) (2) get access (3) remove login name and profile pic (4) delete cookies

Jack Douglas

in which case the process will likely mirror an account recovery

Jack Douglas

but you may be referring to imported posts?

Jack Douglas

(1) remove login name and profile pic (2) delete cookies

Jack Douglas replying to Paul White

Well, unless the account is compromised, this could be pretty much DIY.

Paul White

Perhaps a Contact Jack link on the profile page :)

Paul White

Yes no doubt it would be manual, but there still needs to be a way to request it privately.

Jack Douglas replying to Paul White

Even SE do that manually at the moment — though my guess is that they have a bit of a backlog at the moment!

Paul White

It is worth thinking about how we support CC terms like removing the author's name on request.

Paul White

There are better things in life to worry about than what latest legislation from whatever country one might be violating accidentally.

Jack Douglas

allowing folk to add an email/twitter/whatever to their account purely for account recovery has been considered and might happen one day — for me the PII issue is about what info people are forced to give up, and what degree of access there is to the info (i.e. devs/mods/everyone etc).

Paul White

One of the other undocumented guiding principles is to not do stuff just because SE does.  
That might or might not be the right approach in every case, but it does seem to be serving us well so far.  
I don't think it is possible to not store user names or avatars, but those are at least optional in a way that login/recovery email would not be.

Caleb

And without 2FA.

Caleb

If you aren't storing emails or some other PII, server side resets are pretty meaningless. Either you lock/nuke the account or nothing, but resets risk turning somebody's public persona to mush if you let the wrong person in. Client side is pretty much a must to accompany resets in the event of compromise, but I don't know how you get a compromised account back into the right hands without a fallback.

Jack Douglas

well this is something we need to bear in mind and keep a close eye on at the very least

Jack Douglas

ouch

Caleb

I got fed up with at about 75 users which came from a small enough demographic that I could reasonably be expected to track down that they were the real people they claimed to be. At 350 and some users I had no way to personally verify I had to give up and authenticate another way. The tech savyness of the demographic was low too, that didn't help.

Jack Douglas replying to Caleb

you mean from the server or the client side?

Caleb

Okay fair enough, but not being able to invalidate sessions is another kind security issue. And the two are kind of a catch-22.

Jack Douglas

admittedly from a very small sample

Jack Douglas

I've been encouraged not to have any recovery requests so far

Jack Douglas

how many accounts (roughly) did you have on that system?

Caleb

Sure the email database has value, but having _tried_ to avoid collecting them for a system once and eventually being overloaded with account recovery requests I had to deal with by hand, farming that out to somewhere else does make things a lot easier.

Jack Douglas replying to Caleb

not quite true — the authentication tokens stored on each device are not invalidated when the recovery code is changed

Caleb replying to Jack Douglas

Actually that would have the negative effect of making compromised accounts unrecoverable by their owners the moment they were actually compromised. There is a reason "recovery codes" are usually used as a substitute for 2FA, not in place of the password or an off-site identity managed with more layers of backup (as long-running email accounts usually are).

Jack Douglas

btw I'm pretty sure the primary motivation for other sites using email for auth is not 'to make things easier' but because the email database has value.

2 Answers