Template:User committed identity
This template gives you a way to later prove that you are the person who was in control of your account on the day this template was placed. This is done by putting a code (called a "hash") on your user page so that, in the event that your account is compromised, you can convince someone else that you are really the person behind your username.
Why?
The intended use of this template is to help in the hopefully unlikely event that your account is compromised. If you published your real-life identity, then that identity could be used to reestablish contact with you if your account were compromised; keep in mind, in this scenario contact could not be established with you through your account, since it may be under the control of someone else. However, many Wikipedia users do not disclose their real-life identities, or disclose little enough of them that it may be difficult to establish their identity.
This is not a replacement for having a strong password, nor for registering an email address for your account. You should still do everything you can to prevent your account being compromised, including using a strong password and remembering to log yourself out when using a computer others may have access to. If you have one, it may also be helpful to post your PGP public key. But even with the best of precautions, your account could become compromised, for instance, via a trojan horse or a brute-force attack on your password. This is intended to be a last resort.
How
The idea is to use cryptographic hashes; you choose a secret string known only to yourself, put it through a one-way hash function, and publish the result somewhere. It is infeasible to determine the secret string corresponding to the hash; hence, an attacker compromising an account presumably would not be able to supply the secret string.
Syntax
{{User committed identity|hash|hash function used|background=CSS color|border=CSS color|article=grammatical article for the hash function}}
Italicized text should be replaced with appropriate input, or its parameter should be removed. Parameters are represented by 'parameter=value", and separated by vertical bars |.
- Replace "hash" with the hash produced from your secret string. The implicit name of this parameter is "1" (see numeric parameters).
- The "hash function used" parameter, if not included, defaults to SHA-512. (This hash function is strongly recommended.) If you would like to link the hash function to a wikipedia page, you can supply the interwiki link. For example, using
[[en:Whirlpool (cryptography)|WHIRLPOOL]]will show WHIRLPOOL in the template - The "background" parameter, if not included, defaults to #E0E8FF (light blue, see en:Web colors#Hex triplet)
- The "border" parameter, if not included, also defaults to #E0E8FF.
- The "article" parameter, if not included, defaults to "a". The other likely value is "an".
For example, if your hash is "ef7c4c55a176bd20ed558aaefde21c4803080195" using SHA-1, and you want a light orange box with a black border, use the following code
- {{User committed identity|ef7c4c55a176bd20ed558aaefde21c4803080195|SHA-1|background=#FC9|border=#000}}
to produce
Choosing a good secret string
- Your secret string should not be easy to guess. If your string is easy to guess, then the fact that you know the string is not likely to be very persuasive. For example, a string of 'joe' will be less convincing than 'My name is Joe Schmoe, and I can be contacted at: joe@example.com'
- Your secret string should specify enough of your identity that, if the string were revealed, you could unambiguously prove you match that identity. For instance, your secret string could include a telephone number or email address at which you can be reached.
- Try not to choose a secret string that represents your identity that could go completely out of date. So, for instance, it may be bad to choose a string that specifies only your telephone number as that number might change.
- If you want to change your secret string, do so, but keep track of all your old secret strings. It is best to reveal all of them if you ever want to confirm your identity, as this will establish that you are the same person who used your account from the first moment the committed identity was published.
- Your secret string should not be short. A dedicated attacker could, by brute force, try short strings until they find your secret string, but if your string is longer that attack would be impractical. If your string is 15 characters long, there are around 1027 strings of that length, or an octillion (and that's just counting alphanumeric strings with spaces).
- Your secret string should not only contain an email address, name or phone number, but should contain hard to guess components. "jsmith@hotmail.com" for example may be vulnerable to both en:dictionary attacks and a search of email addresses, enabling attackers to check 'only' those hundred million names against all published hashed identities, which is computationally much easier than trying to identify a randomly chosen string.
No description.
| Parameter | Description | Type | Status | |||
|---|---|---|---|---|---|---|
| No parameters specified | ||||||
Heading text
Getting the hash
Be sure to note the exact string you enter into the form, in case you need to use it later. It is important that this string be both easily remembered exactly by you and hard to guess or find by any intruder - if an intruder knows the secret string, then this scheme is useless and provides no security. One's username is public and trivially guessable; one's password is not a good choice either, as in the event of a compromised account, the password is likely to have been guessed.
You can use Fastily's browser tool to generate the hash. The use of other online hash generators is not recommended, as they are outside Wikipedia's control and should not be trusted with your secret string.
You can also use software on your computer to obtain a hash. On Unix-like operating systems the md5sum, sha1sum, sha224sum, sha256sum, sha384sum, and sha512sum programs are provided in the en:GNU Core Utilities. Windows users may use one of the methods mentioned below; those who have PowerShell installed can generate a hash using the following command. Provide your secret phrase in the location indicated:
[bitconverter]::tostring((new-object security.cryptography.sha512managed).computehash([text.encoding]::utf8.getbytes("Secret phrase here"))).replace("-", "")
It is recommended that SHA-512 be used, as recent cryptographic research has cast doubt on the long-term security of SHA-1. The template defaults to SHA-512 if the hash function parameter is omitted. For security, you should only use locally executed programs, or client-side javascript, to create your hash. Examples of such hash calculators include jsSHA and HashCalc 2.01.
To verify that you are correctly hashing your secret string, you can try hashing 'My name is Joe Schmoe, and I can be contacted at: joe@example.com' (without the enclosing single-quotes). Your SHA-512 hash should be: b7a84efbbd843545666957384e874c894fdc17f48ced53abd231c2e4d08e45ad10287b1225432e3ed9794c12994ff1e82aecf66a2ded61ad4baf6d8b9c81dab8
Compromised identities
In case your account is compromised, to make use of your committed identity to someone and prove you are the same person who originally controlled the account, give a trusted user the exact secret string you originally entered into the box. They can then compute the appropriate hash of that same string and verify that it is the same result and that you are who you say you are.
Once you've established your identity, and set up a new account or regained control of the original account, you'll probably want to create a new hash as now someone (possibly multiple someones depending on who and how you told the secret string to) else knows the secret string.
Weakness
This technique of establishing identity by revealing the secret string behind the hash is not inherently attack proof; it increases attacker effort substantially (if the secret string is chosen and handled properly) which is worthwhile, and does so at little effort to the legitimate user. But it is attackable in that anyone can invent their own secret string, hash it, and claim an identity.
An attacker with access to the account could overwrite the hash with their own one. They could then say that the previous owner of the account was an attacker who claimed their identity and generated his own hash.
An attacker without access to the account could claim that the current account's owner stole their identity. The attacker could state that they did not publish a hash when they used to own the account, or that they did not register an account and that someone else is using their name.
An attacker may want to know the secret passphrase, pretending he wants to verify your ownership. He will use social behavior to convince you that you must reveal it. Then by revealing him the passphrase to him, he can pretend he is now the "legitimate" owner of your account, and act on your behalf without asking you anything. The passphrase verification (necessarily made by someone else) is inherently unsecure.
This weakness does not indicate the en:commitment scheme is worthless, because the commit phase did not apply to all interested parties (the real person and all potential attackers).
Better protection
But a real protection should use a two-keys echange mechanism based on asymetric key pairs:
- these keys are used to encrypt on one side (and decrypt on the other side) the hashes of the plain-text request (that does not need to be encrypted itself) which also contains in clear text the public key of the sender; the hash then terminates each message and authenticates its sender. When replying, your response must contain (in its clear text) the initial encrypted hash that was in the verifier request, so that your reply cannot be reused as a formal acceptation for an unrelated request. In both cases, the hashes are encrypted using the private key (never revealed to any one) of each message sender: each one "reveals" only his public key.
- The hashes should be computed by including the content of the clear-text message, so that this message cannot be altered maliciously by anyone else (the hash asserts that the text is authentic and comes only from the user that owns the private key, and because this public hash is then followed by a secretly encrypted hash of all the previous content, it cannot be reused for unrelated responses; and it's still easy to assert that this second encrypted hash can be decrypted successfully using the public key of the message sender, to check that it matches his public key also present in the clear-text message and as well the public key can assert that the first message and its hash was not altered).
- But for that goal you still need a strong hashing algorithm (SHA256 at least) in addition to the encryption algorithm with asymetric key pairs used to sign the hashes and authenticate each sender. Asymetric encryption is known to be slow for long messages, but this should not be a problem because it will encrypt only strong hashes (this also secures the asymetric encryption to protect the private keys which are typically longer than hashes and cannot be infered from the public keys that are also longer than the hashes). With SHA256 or SHA512 used for the hash, you can then use asymetric encryption with 1024-bit asymetric keys. With that the "commitment" of each one can be trustable because everyone keeps his secrets but signed authenticated messages can be safely archived, and published as an evidence, a proof that cannot be later denied by any one (not even by the sender of each signed message that should attest with his signature that he is alone to own and control the private key).
- The mechanism can be used as a proof of authenticity for any kind of message, request, or reply: what is authentic is the clear-text text of the message that contains any kind of public information that one can trust, so it can contain a public account name, or the date of the message and the nature of the request. Its authenticity is proven by the fact it still contains the encrypted hashes that were kept unseparable from the clear-text message containing all the necessary public information that cannot be altered without breaking the secure hashes (which can no longer be decrypted with the public key of the orignal message sender. It can then be used to authenticate a verification request, and its reply.
- Each user must only publish his own public key and never has to give his private key. The user can also change the public key (and his private key) later on his public page at any time (and this change can be verified by issuing a request to the account owner to prove that he still also owns the former private key (that must be kept for a reasonnable time) and not just the new public key that replaced the old one on the account.
Such mechanism is used in emails (e.g. with PGP), or for authenticating web sites (using server certificates that contain their public key and other proof of their alleged identity, because it has been signed by a third-party using exchanges based also an asymetric cryptography with key pairs for the site owner and key pairs for the third-party signatory).
Wikimedia also uses such mechanism for VRTS (for authenticating the licencing agreement and the opposable assertions made by the publisher that either he owns the legal rights on the published content, or that he received the necessary and proovable formal authorization of publication from the legal owner of these rights).