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.
What is it?
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.
How it works
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 (aHash 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).
Example
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
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.
Your secret string should not be easily guessable based on what you have publicly revealed about yourself. For example, if you use your real name on Wikipedia, your address or telephone number might be guessable, so be sure to make part of your string an unguessable secret.
This is not a substitute for using a strong password on your account. It is better to never have your account stolen in the first place.
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)
Because this was part of a dated edition of the "Wikimedia Signpost," it would be inappropriate to edit the body of this page. However, it would be entirely appropriate to create a new information page about committed identities that is up-to-date. It should probably be named Wikipedia:Committed identity/2014 draft or something like that. Once it is created and accepted by the community, Wikipedia:Committed identity can be deleted and the new page moved into its place. Shortcuts listed here (e.g. WP:CID) would need to be adjusted and hatnotes would need to be added to the top of both the Signpost article and the new Committed identity page.
This article was published before I'd even started editing Wikipedia (before, indeed many did). I see this because it is on my mass-issue watchlist, which I'm not entirely sure isn't unique, so I'd advise you try to bring this up elsewhere (village pump?). ResMar05:52, 26 May 2015 (UTC)[reply]
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:
If someone has a general idea of what it could be, it could narrow the possibilities tremendously. For example, the example given in the article that says to change "Hewey, Dewey and Louie, October 17, 1937." to "Hewey October Dewey 17 Louie 1937. Egg salad is murder!" could still be brute-forced if someone knows the user's family members and has a powerful enough computer.
In the case that someone has a number of ideas, they would easily be able to verify whether one is correct.
Many users might not follow this advice and choose an insecure string, which would mean it could be brute-forced by guessing random characters
Vulnerable to repeat attacks: if an attacker reads the sent folder of someone's email, they can send the same code to Wikipedia and it would be impossible to determine who is the attacker and who is the legitimate user
It would involve sending the string to the Wikipedia administrators. A good string would be something nobody else knows, and I would assume that many of those things are not chosen because the user isn't comfortable with sharing that with the administrators.
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
The user comes up with a secret string and gets the SHA512 hash of the string "REFERENCE/<username>/" plus the secret string, such as "REFERENCE/User:DonaldDuck1/Hewey October Dewey 17 Louie 1937. Egg salad is murder!".
They then email this to the Wikimedia foundation, and they pepper the hash with a secret key only Wikipedia knows, then send it back to the user
The user adds this to their usercard
Recovering an account
The user takes the hash of "<random number>/<username>/<secret string>", for example "12345678/User:DonaldDuck1/Hewey October Dewey 17 Louie 1937. Egg salad is murder!".
They then email this to the Wikimedia foundation. If the random number has been used before or it is the wrong username, they ignore it.
If the peppered secret key (originally sent by the user) is equal to the string that was just emailed, this is the correct secret.
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'us12:24, 13 August 2023 (UTC)[reply]
Issues
When the secret is used, something needs to be done to mark it as being used, and then to replace it.
Peppering the secret with the result of an S/KEY output would assist. The disadvantage is increased complexity.
Users who fail to store their secret are potentially worse off than those who don't bother using the scheme.
Advice could be given, such as: including in the public part of the text a hint as to where the secret bit was stored.
Advice could be given, for the user to put an expiry time on the protection.
+ Add a comment
Discuss this story