Wikipedia:Wikipedia Signpost/2007-05-14/Committed identity

User committed identities provide protection against account hijacking

•  PDF download

 E-mail

 Mastodon

 LinkedIn

 Facebook

 X (Twitter)

 Reddit

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 (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).

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:

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.

• Do not lose your secret string.
• Although the template defaults to SHA-512, any cryptographic hash function can be used. See this web site ^{[dead link]} for information on alternatives.
• 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.

• Calculate some common hash values
• Calculate a SHA-3 hash value

In this issue

14 May 2007 (all comments)

Compromised accounts

Academic journal coverage

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.

You may be asking "but why not just edit Wikipedia:Committed identity "in place," why bother with a draft? The answer is that there are too many incoming links to Wikipedia:Committed identity and it would be a bad idea to have people clicking on those links see a draft-in-progress. davidwr/(talk)/(contribs) 03:00, 10 April 2014 (UTC)[reply]

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]

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?). ResMar 05:52, 26 May 2015 (UTC)[reply]

Addendum:  Steel1943:. ResMar 05: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.

Here is a different process that I propose:

1. 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!".
2. 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
3. The user adds this to their usercard

1. 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!".
2. 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.
3. 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 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]

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]

1. 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.
2. 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.
     

Archives

Newsroom

Subscribe

Suggestions

Languages