This page contains information which may be out of date. In particular, some of the encryption and authentication algorithms mentioned are no longer considered secure. When creating a "committed identity", only use cryptographic algorithms which are considered strong. |
In the wake of last week's report of five administrator accounts being hijacked by having their passwords cracked, Mangojuice (with the help of several others) has proposed a method that editors can use to identify themselves as the original account holder to regain control of a hijacked account. At this writing, about 300 users have confirmed their identities using this method.
Template:User committed identity gives editors a way to later prove that they are the person who was in control of their account on the day the template was placed. This is done by putting a public commitment to a secret string on the user page so that, in the unlikely event that their account is compromised, they can convince someone else that they are the real person behind the username, even if the password has been changed by the hijacker.
An editor chooses a secret string; this is a group of words and numbers or a phrase known only to the account holder. The secret string can be any length; a good string will contain at least 15 characters and include unique information that only the account holder would know, such as a phone number or private e-mail address (not the address associated with your wikipedia account). The secret string is then processed through a cryptographic hash function such as SHA-2 (SHA-512, SHA-384, ...) or SHA-3 to generate a unique hash value or commitment. The commitment is placed somewhere in the editor's User space. If the account is compromised or hijacked, the editor provides the secret string to a trusted administrator or a developer, who verifies that the secret string matches the commitment value. Because the hash function is "one-way", it is impossible to calculate backwards to find a string value matching a given hash value, and the odds of a random string having the same hash value (a Hash collision) is negligible. Therefore, knowing the string that produces a given value is very strong evidence that the person giving the string is the person who originally published it. Once the string is verified, the developers can reset the password to allow the original account holder to regain control.
Alternatively, a user could create a PGP keypair and place the public key on their user page, and then prove their identity by using the private key to sign any message the challenger wants signed. However, this requires more technical competence, and it is necessary to ensure the private key file is well-protected (it is no longer a simple message, although it can of course be encrypted with a passphrase).
For example, User:DonaldDuck1 chooses a "secret string" that includes the names and birthdate of his nephews. His string is,
Hewey, Dewey and Louie, October 17, 1937.
However, if DonaldDuck1 has mentioned his family on Wikipedia, this might be too easily guessed. A useful variation would be
Hewey October Dewey 17 Louie 1937. Egg salad is murder!
Using this web site to calculate the SHA-512 hash value produces
b43f3e39de3f501217144badfc64687a2f516d5d1205d89e51c003715f8609adfbd085afcac3839f7d1008d185e4ab0040edecf62671dbf66a825823e7d3ad42
User:DonaldDuck1 would then put the hash value on his user page using Template:User committed identity like this:
{{user committed identity|b43f3e39de3f501217144badfc64687a2f516d5d1205d89e51c003715f8609adfbd085afcac3839f7d1008d185e4ab0040edecf62671dbf66a825823e7d3ad42|SHA-512}}
which looks like this:
Committed identity: b43f3e39de3f501217144badfc64687a2f516d5d1205d89e51c003715f8609adfbd085afcac3839f7d1008d185e4ab0040edecf62671dbf66a825823e7d3ad42 is a SHA-512 commitment to this user's real-life identity. |
In the event that DonaldDuck1's account is compromised or hijacked, he can e-mail the string to the Wikimedia Foundation office. If the hash value of the string matches the hash value previously posted on his user page, he will have proven that he is the rightful account owner.
Discuss this story
This page is tagged as out of date, and there's a recommendation from Feb 2014 to only use cryptographic algorighms which are considered strong. Does anyone know if there are instructions anywhere for how to do this? Or any plans to update this page? Or any change to the recommendation -- perhaps now that we're on a secure server, it's not as crucial? 08:58, 8 April 2014 (UTC)
Draft for "Committed identity" proposal at Draft:Wikipedia:Committed identity
I had started a rough draft of a page that could be considered an actual policy for Wikipedia:Committed identity. Any help with this task is welcome. Steel1943 (talk) 19:53, 25 May 2015 (UTC)[reply]
Making this more secure
Issues
This feature has great potential and I think this could be very useful. However, while following the advice "[the string should] contain at least 15 characters and include unique information that only the account holder would know" would make it impossible to brute-force it by guessing random characters, it still has a number of security holes:
While these methods take a lot of effort, there are millions of people who use Wikipedia, and if just one black-hat hacking group managed to compromise an interface administrator's account they could have Wikipedia steal everyone's passwords and install malware.
Proposed proccess
Here is a different process that I propose:
Setting the secret
Recovering an account
Automating this process
This is very cumbersome for both the user and the Wikimedia foundation. However it can easily be added as a [[Wikipedia:I will make a proof-of-concept script if this generates enough attention. Anonymous from Stack Overflow (talk) 18:42, 13 December 2021 (UTC)[reply]
Making this more robust
This is an attempt to improve the process, as I find mine is now broken. I realise this talk page isn't structured the way most are so hopefully I'm makinng edits the right way? Please just delete what's not needed. -- Silicosaur'us 12:24, 13 August 2023 (UTC)[reply]
Issues