or
completed feature-request
Caleb
The account system here is a little bit wonky. I understand some of the technical benefits, but not working how people expect (how every other user account system works) will eventually have its own cost.

In the mean time at least one technical aspect should be dealt with asap. The short lifetime PIN for validating another sessions is okay if both devices are at hand, but often that is not the case. Hence the recovery code will get used a lot, and saved, and passed around between computers by who knows what mechanism. Mistakes happen. These will get compromised. If you don't believe me:

    6a2271e8-2f4c-663b-43ac-2e245414fedd

Yes that's my actual account recovery code — before I fiddled with it and typed over some hex values.

The point is that "treating something like a password" doesn't mean it will stay private. Just a couple months ago a series of mistakes with my password manager and its autotype mechanism led me to post my real SE password into an SE chat session. Thankfully somebody pointed this out and I reset the password and all sessions in a hurry, but mistakes happen. Recovery codes should not be permanent any more than passwords. A mechanism to reset them is required.
Top Answer
Jack Douglas
> A mechanism is needed to invalidate account recovery codes.

Thanks for suggesting this, I think you were right that it's urgent to get a mechanism in place.

We've just rolled out the feature:

![Screenshot 2019-11-28 at 13.56.54.png](/image?hash=8e5281e7c01cbd4f00af8976c4ab30c468edf7104371448eb14792fc3ea84570)

> Yes that's my actual account recovery code — before I fiddled with it and typed over some hex values.

I suggest you test the feature now :P
Answer #2
Paul White
It does make sense to allow a user to generate a new recovery token. That action should invalidate the previous token.

>...but not working how people expect (how every other user account system works) will eventually have its own cost.

I think the benefits of not storing an email address outweigh that cost.
A mechanism is needed to invalidate account recovery codes.
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.
Jack Douglas
@Caleb as well as a manual way of regenerating account recovery codes, does it make sense to automatically regenerate it each time it is used? My first thought is 'yes it does'.
Caleb
Selam!
Jack Douglas
also 'hi' :)
Caleb
At the end of the day I think as things scale it will become apparent that shuffling responsibility for identify off to email providers has a lot going for it. Not insurmountable and I'm actually really curious how viable this will be, but the other systems I've tried have been a constant source of frustration.
Jack Douglas replying to Caleb
not really documented anywhere outside of chat — but the main PII that we are *not* forcing you to hand over is email addresses
Caleb
Where is the non-storage of PII documented? I also would argue my name and avitar (which clearly _are_ stored) and my IP address (which even if you have a policy about flushing logs does need to be stored at least briefly to handle abuse) are more personal than my password (which seems to be the thing not being stored in this scheme).