We should have a way to mark that a user has been deleted #1585
Comments
When a user deletes their account in GitHub we don't receive any notification that this has happened. If another user creates an account with the same name, we will link to this new user on any crates owned by the old user, which can make it appear that the new user is an owner and lead to social engineering situations we don't want to permit. This isn't something we can reasonably automate detection of, but when we do find out that it's happened, we can now manually flag a user. We *can* detect this when a new user is created with the same gh_login as an existing user, which will be handled in a followup PR. Fixes rust-lang#1585
When a user deletes their account in GitHub we don't receive any notification that this has happened. If another user creates an account with the same name, we will link to this new user on any crates owned by the old user, which can make it appear that the new user is an owner and lead to social engineering situations we don't want to permit. The front-end is pretty coupled to the (false) concept that a user always has a GH login, and that we can display it. Ideally I'd like to move what we currently call "login" to the "id" field, but we have at least 2 places today where we use the actual user id in the URL, so we'll have to change those before we can make that happen. For now I've just introduced a `display_name` field (which is confusingly named since it's usually the same as `login`, not `name`, but I couldn't come up with a better name). When a user deletes their account (or renames it, we have no way of knowing which one happened), we will no longer report their old github name, and will instead report `deleted_123` where 123 is *our* user ID for them. This is then used in the users route to look them up, instead of their old GH login, which may be reused by another user. Since we don't necessarily want to allow crawling of user profiles, this can only be used to access deleted accounts. Attempting to visit /users/deleted_123 for a user ID that isn't deleted will 404. Additionally, since we can't generally tell if a user deleted their account or renamed it, logging back into crates.io (which will update gh_login with the new value) automatically marks them as undeleted. This isn't something we can reasonably automate detection of, but when we do find out that it's happened, we can now manually flag a user. We *can* detect this when a new user is created with the same gh_login as an existing user, which will be handled in a followup PR. Fixes rust-lang#1585
|
I don't understand why we need this, could you explain the benefit? |
This leads to confusion at best, and is a vector for social engineering attacks at worst. We're implying that some user who does not own a crate does |
So github user carols10cents owns crate foo. github user carols10cents deletes her github account. malicious user warols10cents registers now available name carols10cents and logs in to crates.io. Per this test, crates.io/users/carols10cents now links to warols10cents' carols10cents account and displays the crates that warols10cents has published. warols10cents doesn't have access to the crates carols10cents published. Can you clarify what the social engineering is that warols10cents would have the ability and motivation to do? |
|
You're missing that carols10cents still owns crates. Their crates.io
account still exists. We still need to link to it. Right now we're
literally just linking to a different account, implying they are the same.
You're correct that if you're paying attention you'll notice that they
aren't, but we shouldn't be putting that burden on our users to notice.
…On Thu, Dec 27, 2018, 5:57 PM Carol (Nichols || Goulding) < ***@***.***> wrote:
This leads to confusion at best, and is a vector for social engineering
attacks at worst. We're implying that some user who does not own a crate
does
So github user carols10cents owns crate foo. github user carols10cents
deletes her github account. malicious user warols10cents registers now
available name carols10cents and logs in to crates.io. Per this test
<https://github.com/rust-lang/crates.io/pull/1109/files#diff-e9f6217e1bee931c5ea3ec70dd63c636R94>,
crates.io/users/carols10cents now links to warols10cents' carols10cents
account and displays the crates that warols10cents has published.
warols10cents doesn't have access to the crates carols10cents published.
Can you clarify what the social engineering is that warols10cents would
have the ability and motivation to do?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1585 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABdWK3mEyMTyUNr1YD1yxqooJvI14QBQks5u9WxagaJpZM4Ziw0q>
.
|
The "confusing" aspect I see, it's the "social engineering" bit that I'm still not getting. I do think we should fix it, I just don't see the urgency that "social engineering attacks" prompts. |
|
I think I may have communicated poorly. I was not attempting to imply urgency, or that there's an obvious attack vector that is being exploited right now (if there were this would not have been opened publicly). By "confusing at best, and a vector for social engineering at worst" I was just trying to say that we should fix this no matter what, because it's definitely confusing and I think there is the possibility of someone using this for nefarious purposes by impersonating another user. |
carols10cents
added
the
C-internal 🔧
When a user deletes their account (or renames it and never logs back into crates.io), we are never able to find out about it. We continue to show that github username's avatar, and links to the github account with that name, even if someone else has created a new account with the same name.
We should have a flag we can set to mark that a user has been deleted, which shows the avatar of @ghost, and either removes all links to their github account, or links to @ghost. This does not affect repository links, which are just URLs given to us in Cargo.toml, and not coupled to Github in any way.
I do not think we should try to automate this, but we should have the ability to do this manually when we receive reports.
The main blocker here is how do we link to that user once we know they're deleted. We currently use gh_login as the identifier in /users, we will need to do something else in this case.
The text was updated successfully, but these errors were encountered: