Template talk:Committed identity/Archive 1

Archive 1

---

Real life identity

Isn't there some advice somewhere that you shouldn't use your middle names, birthdays, pet names, phone number or your address as a password because the hacker is also likely to know it (or at least be able to guess it in a short time). This seems similar. I suggest the passphrase should not be related to real life identity. All you have to do is prove you know the phrase - there is no reason to link it to identity, in fact linking to identity is a serious risk. -- zzuuzz ^(talk) 19:03, 9 May 2007 (UTC)

The docs could probably be improved. My key consists of my name, my email, my phone number, and a sequence of 16 random characters from a password generator. The random bytes will prevent brute force attacks. You could equally well use a passphrase instead of the random bytes if you want.

The point of adding some contact info (a phone number, for example) is that the person who verifies your identity can avoid being tricked by actually calling the person the key identifies. Presumably the hacker can't reroute my cell phone number... CMummert · talk 19:21, 9 May 2007 (UTC)

If your identity is known, then it's not a good secret. ie, Jimbo shouldn't use his full name, address, phone number or anything. But for a pseudonymous user, her identity is as secret as her password, and using the identity has the benefit CMummert points out or adding another communication channel. If you confirm yourself through email, something signed with your private key, the hash secret, and exist as the identity the hash claims, then you're even more likely to regain your account. --Gwern (contribs) 23:38 9 May 2007 (GMT)

At a minimum, this is just a "second password" that an attacker is less likely to guess than your normal password (because it's hopefully longer, because it's not frequently used, not sent over plaintext, because an attacker just wants to create havoc and they don't need to take extra time to figure out what the second password is to do that). If you confirmed the second password, but it didn't have any personal info in it, I struggle to see why bureaucrats shouldn't unblock/re-admin you at that point... (and if they wouldn't accept you as you, then they certainly wouldn't trust email, I'd think, since the attacker might have all your passwords at that point... how else do you get a never-used password, other than finding the place someone stores all their passwords?) --Interiot 16:49, 10 May 2007 (UTC)

Problem

The problem is that a hacker could write down your hash and wait. SHA-1 has been broken, and I wouldn't be surprised if it became easy to go backwards soon. When that happens, the hacker could look at all the possible strings, find the likely one, claim the account has been compromised, and provide the information. At the very least, he will get the user's personal info. I recommend SHA-512 instead. mrholybrain's talk 16:43, 10 May 2007 (UTC)

Yes, I second this. We should either avoid pointing people to a website for creating hashes or have one on the toolserver, and we should definitely recommend as good a hash as is reasonably available, and SHA-512 is in the coreutils last I checked and so is quite available. I suggest we replace mention of SHA-1 with SHA-512. --Gwern (contribs) 03:34 11 May 2007 (GMT)

Check the template; the option already exists to use a different hash :) -- Avi 04:08, 11 May 2007 (UTC)

I came here for the same reason noted by mrholybrain and Gwern. We should use the long hash like SHA-512 as the default. I am concerned that someone could use brute force in a forward manner to find all possible combinations and look up people's secret phrase. Royalbroil 15:50, 15 May 2007 (UTC)

The site

We're directed here:

• http://www.cs.eku.edu/faculty/styer/460/Encrypt/JS-SHA1.html

If this is to be any use at all, in my opinion, it must be on servers carrying a valid SSL certificate for Wikimedia or a very highly trusted third party. And this document should perhaps be protected to prevent the link being changed by someone for the purpose of phishing. --Tony Sidaway 17:49, 10 May 2007 (UTC)

I found another SHA-1 calculator, but it's a very bad choice because it purposely caches all queries and will "decrypt" any hash values it has previously produced. So it could be quite bad if someone changed that link. Mango juice^talk 17:58, 10 May 2007 (UTC)

The safest thing is to use sha1sum on your own machine. (Humor: all reasonable computers already have it installed, and there must be a windows version available somewhere.) Seriously, can't someone put a cgi script on toolserver to do it? I could, but I don't have a toolserver account. CMummert · talk 18:03, 10 May 2007 (UTC)

Offline software

• HashCalc 2.01 Freeware: Free calculator to compute multiple hashes, checksums and HMACs for files, text and hex strings. It allows to calculate hash (message digest), checksum and HMAC values based on the most popular algorithms: MD2, MD4, MD5, SHA1, SHA2 (SHA256, SHA384, SHA512), RIPEMD160, PANAMA, TIGER, CRC32, ADLER32, and the hash used in eDonkey (eDonkey2000,ed2k) and eMule tools. It supports 3 input data formats: file, text string and hexadecimal string.
• Advanced Hash Calculator 1.31 Freeware: Calculates CRC32 control sum, GOST hash, MD2, MD4,.MD5, SHA-1, HA2 (256), SHA2 (384), SHA2 (512), for Windows.

-- Avi 19:37, 10 May 2007 (UTC)

GPG would be the best option for offline software: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 -- zzuuzz ^(talk) 19:42, 10 May 2007 (UTC)

Agree with zzuuzz, since you can never trust unknown software to stay offline. The two above sites don't exactly inspire confidence, especially since they appear to be binary distributions. — Feezo (Talk) 19:54, 19 May 2007 (UTC)

• See also Comparison of file verification software for a list of checksum calculators (though I'd recommend HashCalc too, as it's easy to use, and if it didn't stay offline it would make my personal firewall software cry wolf). --IByte 16:10, 12 August 2007 (UTC)

Calculator for multiple hashes

http://www.johnmaguire.us/tools/hashcalc/

SHA-1 may be compromised, based on work by Xiaoyun Wang. Using SHA-256 or RIPEMD-160 may be a better choice.

--Avi 18:19, 10 May 2007 (UTC)

• See http://csrc.nist.gov/CryptoToolkit/tkhash.html for USGovt seemingly stopping to use SHA-1. -- Avi 18:21, 10 May 2007 (UTC)
• I am tempted to make the hash function an input, so that multiple hashes may be used. For example, hashing the string "Jimbo" would look like this:

Committed identity: fd5c301adb6963372c886709c3281b0a0736fceb is an SHA-1 commitment to this user's real-life identity.

Or

Committed identity: 65a2300e4575bc9f8db3ac012bca81010065a7f0 is an RIPEMD-160 commitment to this user's real-life identity.

Or

Committed identity: 9c1970afa4a4a591b47391ac60284cba945d436e9ab7cde463a1de731bcc0703ef614ad5c97fb75796a9b99a3695073f is an SHA-256 commitment to this user's real-life identity.

-- Avi 18:24, 10 May 2007 (UTC)

I was saying the same thing above. I think that any user that does this should make a subpage with the subst'ed template on it. The template would be the best hash available at the time (currently SHA-512 I believe). When a new hash came out, the user would resubst the template with the new hash, and have the old hashcode oversighted so that it could never be broken. With all this complexity, I'm tempted to create WikiProject User Integrity. mrholybrain's talk 19:06, 10 May 2007 (UTC)

Perhaps there's another way to go about this then? Maybe make a log of everyone's changes to their registered email address (the one in preferences), and make that log visible to checkusers only... that way, if an account is compromised, (and if the attacker changes the email address) then checkusers may accept email communications with the previous email address as legitimate (taking into consideration, of course, that email From headers can be spoofed to some extent).

Or make this a proper "second password" implemented in MediaWiki itself, to make sure that most users never get to see the hashed version? --Interiot 19:31, 10 May 2007 (UTC)

I agree with the second password scheme, this template just seems like a stopgap. mrholybrain's talk 00:02, 11 May 2007 (UTC)

Well, strictly speaking, it shouldn't be necessary. The rationale behind moving the hashes to /etc/shadow was basically that, at that time, the traditional Unix eight character password limit (ie. characters 9+ would be discarded) couldn't be done away with for compatibility reasons. (The concept was to use "pseudo-salted" DES and to used the password as a key to encrypt a string. With DES keys being 56 bits long (which one could have reasonably considered to be secure in the early '70s) and ASCII being a 7 bit code all conceivable (and useable) passwords can be specified in at most eight characters.)

The salt was added to prevent the exact same attack vector we're talking about here and hashes were moved to /etc/shadow to prevent logged in users (back then most systems actually had 'guest' accounts, so that practically equaled 'everybody with Internet access') from easily discovering the hash. In this case, we don't have to worry about that because the very point of these hash functions is to not just prevent collision attacks (essentially useless; even if successful, the text will never be human readable which would be a dead giveaway) but also preimage attacks. IOW, the hash does by definition not need to be secret. On the other hand, I guess it does add another (albeit) thin layer in the very unlikely case that an algorithm gets completely broken. Realistically, it shouldn't really be necessary though (particularly since most, if not all threat models would make it far more attractive, ie. computationally inexpensive, to just attack the password or the meatware). -- Seed 2.0 22:59, 19 May 2007 (UTC)

Updated template

Template and documentation updated with hash function choice. Defaults to SHA-1 so that existing users need make no change. I now have to read up on #ifexist to see if I can get the input to be self-wikilinking :) -- Avi 19:28, 10 May 2007 (UTC)

I think we should move the template to default to SHA-256 or SHA-512 (as discussed elsewhere); right now, there's not even 50 users of the template, so it wouldn't be too problematic to copy the current template to a deprecated name and repoint those 20 or 30 users' pages at it (so as to not break it). --Gwern (contribs) 04:37 13 May 2007 (GMT)

Default is now SHA-512. I manually went through the users and believe I changed all those necessary. -- Avi 16:50, 15 May 2007 (UTC)

Great. It's best to get these sort of things cleaned up at the beginning before it's too late. I'll update the documentation? (Wonder if we should protect it.) --Gwern (contribs) 17:32 15 May 2007 (GMT)

The template itself is already protected; I do not believe the documentation needs to be protected. -- Avi 18:28, 15 May 2007 (UTC)

GnuPG key

Why don't those who want to certify their identity just publish their GnuPG keys? We could even have signing sessions and whatnot. Here's a cheap and reasonably good way of getting your key signed: upload a media file containing your voice reading out the fingerprint of your key and link to it from your user page. Call some other Wikipedian, by prior arrangement, and read out your fingerprint to him, then he checks your voice recording electronically signs your key to certify that he knows your voice on the phone. --Tony Sidaway 19:31, 10 May 2007 (UTC)

This problem seems somewhat related to the How can living wikipedians ensure that news of their death reaches Wikipedia? problem, and it might be nice if people could fix both issues at the same time... at the same time you're confirming the identity of each other, you could exchange some contact info of a few family members in case someone's account goes silent? It seems like most people aren't willing to publish key identity information, but they might be willing to trust a few specific users with a larger amount of personal information, even if they've never met face-to-face. --Interiot 20:11, 10 May 2007 (UTC)

Yes, and also this could be used to build up a chain, or matrix, of trust. Someone known to Jimbo signs somebody's key, who signs some others keys, and so on. I just know I'll regret this when the first "This user's J-number is..." userboxes show up. --Tony Sidaway 20:19, 10 May 2007 (UTC)

Tony, did you see WP:ANI#Admins (or any users) with PGP keys -- Avi 20:35, 10 May 2007 (UTC)

If people have them, they can publish their public keys. Of course, someone could web-search your key and if you've ever published it before, they might learn your identity that way. If you haven't published your key, that's okay, but if the point here is to keep your identity secret, I think that doesn't work so well. Mangojuice 21:14, 10 May 2007 (UTC)

True, which is why some of us created new keys specifically for wikipedia. -- Avi 21:20, 10 May 2007 (UTC)

I thought the whole point of having this key was to let people know your identity, not to keep it secret. But yes if you want to be semi-anonymous you could make a new key and have someone sign that. To get it signed you have to actually give some trusted person some idea of how you can be recognised. --Tony Sidaway 00:11, 11 May 2007 (UTC)

Yes, the whole point of having the key is to verify the identity, but the identity can be the wiki username, as opposed to the realname. For example, at this point, I have signed cleartext messages with my wiki key both on wikipedia and wiki mailing lists, so if I ever need to reverify who I am from another ID, being able to decrypt a message sent to that key basically proves I'm still user Avraham, which should be sufficient for re-sysopping. -- Avi 03:08, 11 May 2007 (UTC)

• Public keys are meant to be public, pgp can be used to verify ID by:

1. Publish your PGP public key, post it on your userpage (e.g. User:Xaosflux/PGP)
2. Maintain your private key and passphrase
3. You can now later prove your self by signing a statement (e.g. "I am the real xaosflux") with your private key and passphrase, and anyone can verify you by verifying the signature with the prior public key.

• Now, using the web of trust of multiple signers allows for more verification, but this method offers all of the features, plus more, of just using a hashing function. (Now that I sound foolproof, please debunk). — xaosflux ^Talk 03:15, 17 May 2007 (UTC)

Very difficult to setup; if Schneier has taught us anything, it's that security which is solid but hard to use or setup is bad security. Plus, your private key is obviously still resident on your hard drive. A hashing system can be very easy to use, is relatively simple to explain (like why the secret string should not be easily guessable), and doesn't require the secret string to exist anywhere but your head. --Gwern (contribs) 03:41 17 May 2007 (GMT)

Agree that it is harder to use, (a negative), but has the benefit of having other uses, and does not have the drawback of the verification requirement of releasing the secret key. Aside from the technical logistics, is there any thing cryptographically unsound here? — xaosflux ^Talk 03:51, 17 May 2007 (UTC)

But the secret will exist somewhere besides your head because you are forced to reveal it, and then the person you reveal it to could claim to be you. Public key encryption as XaosFlux described doesn't have that problem. Generally the secret key is symettrically encrypted on the disk with a passphrase which should be only in your head. As others have said, rainbow tables may weaken this hash scheme because the strings that people use are going to be guessable, as they are short and contain mostly names and words. edit: i also meant to say that all the key-signing and web-of-trust stuff is unnecessary for our purposes. -- Diletante 03:19, 22 May 2007 (UTC)

ehhhh

While technically cute, this template seems like too much of a nerd secret handshake club. As someone mentioned it basically implements a backup password, which among other things discloses the user's secret string and IP address to that off-wiki server. Why not just use a good password in the first place, or if secondary passwords are deemed a good idea, implement them in the wiki software? Re 512-bit hashes: Wikipedia generally is willing to reset user passwords and send the new password by unencrypted email, so fancy cryptography stuff is wasted effort once it's harder to break into than the email. I suppose the template could say that if the user's WP account is compromised then admins should assume that the user's email is also compromised (so new password shouldn't be sent by email), but what happens if the user later gives up on the scheme and removes the template? How do we know they're not an imposter?

One alternative idea is to modify the wiki software so that when a user changes their email address, the old address is saved for at least a month or so, and the date/time of the address change is saved. That would help with the recent situation where the admins were reluctant to reset some compromised passwords by email, because the attacker might have changed the addresses on the compromised accounts.

If you really want to do this hashing stuff and get around the IP address and data-in-flight issues, it's probably easiest to use a client side javascript implementation of the hash function, and put it on a static page on the wikipedia server that users would access through the SSL port. Anyone geeky enough to deal with this probably uses PGP anyway though, so can just put a public key on their user page. 75.62.6.237 05:53, 11 May 2007 (UTC)

Because this is not meant, and cannot be meant, as a stronger password. This is administrator reaction to the password-hack and desysopping that has occurred recently; it is a way to help restore the sysop flag. However, it is somewhat incongruous in that anyone who, as you say, is "geeky" enough to use a commitment scheme, likely is knowledgeable enough to use strong passwords, making use of this scheme almost unnecessary. C'est la vie -- Avi 13:41, 11 May 2007 (UTC)

Anyone could forget to log out of their account, though, and it's hard to be immune to a trojan horse or to a session hijacking. Anything could happen. Mango juice^talk 11:42, 13 May 2007 (UTC)

I share 75.62.6.237's concern that using the links provided so far "discloses the user's secret string and IP address to that off-wiki server." I don't want to use the first link because of potential vulnerabilities with SHA-1. The second link has two problems: it sends the secret string to the web server, which potentially could record and/or share that information; and it sends the secret string in plaintext using HTTP GET, which is not secure. Avi, how did you choose that particular site to recommend? For my current hash, I downloaded GnuPG for Windows then used 'echo -n "secret string here" | gpg --print-md sha512' (at a Cygwin bash prompt). A JavaScript solution would be more secure than the johnmaguire site, but just as easy to use; and easier and more user-friendly than the user's having to install GPG. I think it could be done well enough that one would not necessarily have to be "geeky" to use it. I wish I could commit the time right now to write it myself.

Regarding the vulnerability of sharing the secret string with someone else when proving your identity, I have an idea. Use a "super-secret" string to create a hash H1. This can contain any sort of information you wish, because you're not going to disclose it to anyone. Then, include the hash H1 in the "semi-secret" string used to create a second hash H2; for instance, the "semi-secret" string might look like "billgates@microsoft.com A9993E364706816ABA3E25717850C26C9CD0D89D". You would put the hash of that string, H2, on your user page. It would be very difficult for an attacker to guess the "semi-secret" string because it is NOT short and is not made up of dictionary words. When you reveal this "semi-secret" string to a third party for identity verification, the only piece of information they gain is your email address; however, they are sufficiently convinced that you must be the person who originally created the hash H2, because how could anyone possible have guessed the hash part of the secret string you gave them!? To prevent that person from impersonating you in the future, you can change some small part of the "super-secret" string, creating a very different hash H3, which becomes part of the secret string for hash H4, which you post on your user page. Yes, it's complex, but it reduces the amount of private information given to the third party; without compromising the whole thing by using a short secret string ("billgates@microsoft.com", without anything else, for instance).

Comments? Charm ©† 06:49, 9 July 2007 (UTC)

Cautionary note: the hash given above (A9993E364706816ABA3E25717850C26C9CD0D89D) is for example purposes only and should not actually be used! It is (one of?) the most easily guessed SHA-1 hash(es) in the world! Charm ©† 06:59, 9 July 2007 (UTC)

The more complex the system, the more likely someone will trip up implementing it. And a badly implemented security system can be worse than no system at all. It is absolutely foolish to use an online hashing tool. Many are simply data collectors for rainbow tables, which then show up at sites like these. Feezo (Talk) 07:31, 9 July 2007 (UTC)

Some changes to the appearance.

Resolved

 – Done, I think

This may seem a little picky on my part, but would it be possibly to quickly slip in text that would allow border color and background color changes? Changing this line:

{| cellspacing="0" style="background:#E0E8FF"

To this line:

{| cellspacing="0" style="background:{{{background|#E0E8FF}}}; border:1px solid {{{border|#E0E8FF}}}"

Also, maybe put a return between the end of the table and the includeonly in this line:

}}<includeonly>

Thanks to the person who does this! _└^Jared_┘^┌_t^┐  18:00, 13 May 2007 (UTC)

Please check it now. -- Avi 18:20, 13 May 2007 (UTC)

Thank you. _└^Jared_┘^┌_t^┐  18:47, 13 May 2007 (UTC)

#ifexist

The template should now automatically pick up if the selected hash function has a page on wiki, and self-wiki link to it. -- Avi 18:08, 14 May 2007 (UTC)

Userbox

I realize userboxes are a bit of a touchy subject for some but how about adding an option to get the template down to userbox dimensions? Right now, it looks a bit... bannerish, and a userbox might integrate a bit more smoothly into userpages that are, well, light on content.

I suppose another way would be to use a div to get the template to stay at the bottom of the userpage (regardless of browser and screen resolution used) and keeping the hash on a subpage, like perhaps ~/hash, would work as well (and might in fact be necessary since the hash is too long to not break the standard 45px userbox layout). I think I'm leaning towards the latter since I see little point in keeping the hash sum itself (which isn't actually useful unless there's no other password recovery method available or after an account has been compromised) prominently displayed on a userpage.

Comments? -- Seed 2.0 15:50, 15 May 2007 (UTC)

Well, one thing we could do is not actually display the hash. I mean, as long as it's there in the history, it doesn't have to be visible. But yeah, I think a userbox linking to [[{{{FULLPAGENAME}}}/hash]] could work. Mango juice^talk 15:55, 15 May 2007 (UTC)

Great. I'm a bit busy at the moment but I'll see what I can come up with. -- Seed 2.0 12:34, 16 May 2007 (UTC)

I'd prefer that a new box be created for those who want userboxes, similar to the difference between {{User PGP}} and {{PGP top}}/{{PGP bottom}}, as a number of users have this horizantally accross their page as opposed to it being in the userbox section. -- Avi 16:49, 15 May 2007 (UTC)

That's a good point. I suppose having a separate userbox instead of adding display/formatting options to the template has the added benefit of not having to add clutter to the code. -- Seed 2.0 12:34, 16 May 2007 (UTC)

This user does not have a committed identity.

This user has an SHA-512 committed identity.
See this userbox's invocation.

This user has a WHIRLPOOL committed identity.
See /subpage.

I decided to try to create such a userbox. Based on the comments above, I made it accept either the hash string directly (which is not displayed, as there is not room) or the name of a subpage containing the hash string. If neither hash string nor subpage name is provided, it will state that no identity is available. My attempt is at User:Anomie/Userbox committed identity for now, and examples of the various usages are at the right. I welcome any comments; if you know what you're doing, feel free to edit User:Anomie/Userbox committed identity as well. The instructions section in particular needs cleaning up.

I would like to move it into the Template namespace (please suggest names), once people decide it's good enough. Anomie 19:11, 4 June 2007 (UTC)

Too complex

A simpler and saner solution seems to be to simply supply identifying and contact information to the Foundation. --Golbez 04:16, 16 May 2007 (UTC)

That would of course entail a 100% chance of having to trust the Foundation beforehand, instead of having to trust them only in the event of a compromise. And does the Foundation really want to take on the responsibility of securely storing and verifying that information? --Gwern (contribs) 04:55 16 May 2007 (GMT)

I agree and your second point is a probably a complete dealbreaker since the cost, not to mention the liability aspect, of storing and verifying all that personal information would probably be prohibitive. On top of that, it really doesn't scale all that well. If I used my wife's name as part of the textblock I use to generate the hash and ten years down the line, I decide to get a divorce, I can just regenerate a new hash. If my information is stored somewhere else, I have to involve at least another person. Even if we were to do that just for users with the sysop/bureaucrat/steward/oversight/checkuser bit(s) set, there'd still be a significant amount of work to do just to get the information of everybody who feels comfortable with such a system. -- Seed 2.0 12:34, 16 May 2007 (UTC)

Rainbow Tables

Rainbow Tables are the problem. They all over for SHA-1, and I found some SHA-512 tables by searching google. This is great, but if a hacker wanted to do some damage, it would be no problem. Maybe one of these days I will get the answer to one of the hashes posted on a user page already, just to show people how easy it really is. What we really need is some strong passwords, login on an encrypted https: protocol, some requirements for passwords, and some admins that don't pick lame passwords (i.e. "Password"...). Sorry to be mean to the admins, but please have strong passwords. We need to really think about this idea. Maybe talk to some of the tech guys if it is actually a change on the webpage (https or password requirements). Any suggestions? - Hairchrm 04:32, 17 May 2007 (UTC)

Agreed, this is not, and never was meant to be, a substitute for a strong password. This is only in the event that a password IS cracked, that the sysop has some sort of proof that they are who they say they are. -- Avi 14:45, 17 May 2007 (UTC)

Good points but using SSL would really only eliminate two attack vectors: network sniffing and some forms of spoofing (if the browser is properly set up and if the user has at least a basic understanding of how SSL/CAs work). It something I'm in favor of but I wanted to point out that requiring secure logins isn't very likely to stop account compromises. As you said, strong passwords is where it's at.

Another solution, albeit an inconvenient one: mandatory one-time passwords for all privileged accounts. That would effectively stop all attacks with the exception of real time-intercept MITM attacks and special-purpose spyware. On the other hand, that would make the system very impractical to use for the average, less-than-tech-savvy user, particularly so without using OTP tokens. -- Seed 2.0 15:37, 17 May 2007 (UTC)

Necessity of exact string

If this is to become a real world method for ordinary users (and ordinary admins) there needs to be better information about the "exact string" mentioned under "Getting the hash".

I suggest in "Choosing a good string":

Punctuation, spacing and upper/lower case letters all affect the hash that is produced. Make a clear note of exactly which characters are used in your string.

Also, the acceptibility of special characters and symbols should be noted.

In practice, most people would use a web hash calculator so I agree a Wikimedia-vouched secure server would be necessary. Thincat 09:24, 22 May 2007 (UTC)

Hmm, hemlock (ie. the most obvious hosting choice) doesn't seem to have port 443 open. Since we need encryption and authentication (well, it's not like there's going to be a lot fingerprint verification going on), we'd have to get the SSL (and certificate) issue taken care of first.

Another thing: since we're not talking nuclear facility-grade security here, how about advising people to use a real-life document as the basis of their string? Something like their marriage license or child's birth certificate should suffice (not secret but secret enough as a base string) and could then be used in conjunction with other information to make a secure enough string. The idea obviously being that a secure string is great but it doesn't do anyone any good when it's so secure that it can't be remembered. -- Seed 2.0 13:38, 22 May 2007 (UTC)

Fussy, Writer issue

Has nothing to do with the performance and use, but instead, using 'an' before the encryption type, which may or may not be the correct precedor. Could be changed to '...d6a729d38b442 - SHA-512 commitment to this user's real-life identity.' or the whole thing to: SHA-512 Committed real-life identity: a8f95...b442 --Thespian 07:37, 29 May 2007 (UTC)

The easier change would be to add an option to change the article. I did that - you can now use this syntax: {{User committed identity|hash|DES|article=a}} to change the article. CMummert · talk 12:22, 29 May 2007 (UTC)

Minor fixes for ease of use

{{editprotected}} This is just me being picky. These are just minor changes to the "Usage" part, to make it easier to copy and paste. hash string and hash function need an equal sign after them. And can the parentheses be changed to HTML comments, so they don't have to be removed? Mr.Z-mantalk¢ 02:58, 30 May 2007 (UTC)

Never mind the first part, I didn't realize these are actaully numbered params. Mr.Z-mantalk¢ 02:59, 30 May 2007 (UTC)

Y Done CMummert · talk 03:16, 30 May 2007 (UTC)

Article Awkwardness

{{editprotected}} Is there an advantage to saying "an" SHA/MD5/TEA/CRC32 (in decreasing order of preference ;))? Seems like it should be "a". Jouster  (whisper) 21:17, 7 June 2007 (UTC)

Since choice of "a" versus "an" depends on whether the following word begins with a vowel sound, I would say "an M-D-5" but "a C-R-C-32". The default article is "an" because the default hash is SHA-512, and no one has come along with a consensus that "SHA" is pronounced like "shake" or "share" rather than "S-H-A". Anyway, the template has an "article" parameter in case "an" is inappropriate for any particular hash function name. Anomie 21:39, 7 June 2007 (UTC)

Just specify article= . Cheers. --MZMcBride 22:47, 7 June 2007 (UTC)

formatting problems when using SHA-512

When using SHA-512, the annotation wraps in the middle of "SHA-512 commitment" on my display. Further, the template consumes a preceding bullet.

Committed identity: a80f9c92955bbb71e1ff8b516a88ee50db36cde1a23d50438cd72793346ac641e20f9b520efd4c710dc5e26a8b71569198323e4002c1824420b86e3577fef9c0 is a SHA-512 commitment to this user's real-life identity.

--Jtir 19:22, 12 June 2007 (UTC)

You can't assume other people have the same screen size and font size as you. But you can add spaces to the hash, as on my user page, to let it wrap more easily. — Carl (CBM · talk) 00:07, 13 June 2007 (UTC)

Proposal - Protection

I suggest that a new parameter is added - 'protect' - with the options 'yes', 'no', 'undo'.

If yes, the page would be added to a category for protected pages or a subcategory of WP:RFPP and an admin could protect the page, preventing unauthorised users from changing the string.

The page would default to 'no' - obviously leaving the page unprotected.

If 'undo', the page could be added to a category requesting unprotection for the page.

Both 'yes' and 'undo' categories would be monitored by an admin, who would check whether the last edit was by the user who runs the page.

Any comments? ck lostsword • T • C 18:50, 17 June 2007 (UTC)

In general, user pages shouldn't be protected. But we can verify that the string was not changed by verifying the edit in the user's edit history, and nobody is going to change it there. — Carl (CBM · talk) 19:03, 17 June 2007 (UTC)

Perhaps we could stipulate it'd be on a subpage? User pages and talk pages are more or less verboten, but I've never heard of any problems arising if a userspace subpage (consisting of one template) was protected. --Gwern (contribs) 19:09 17 June 2007 (GMT)

I was referring to subpages - users could be required to transclude their subpage onto their userpage if they wanted. ck lostsword • T • C 19:33, 17 June 2007 (UTC)

I agree with Carl, the edit history is more useful than a protected page if there is doubt about the string—if the edit history can be changed, there are bigger problems involved than a compromised account. Also, I'm not sure how this "undo" is supposed to work. If the user can edit their own protected page, then if the account is compromised the compromiser can change the string. And if they can't change their own protected page, they can never set it to "undo" in the first place. Anomie 19:40, 17 June 2007 (UTC)

Good point - hadn't thought of that. Ah well - just a thought - unless someone else has a different way of doing it? ck lostsword • T • C 19:48, 17 June 2007 (UTC)

<div> instead of table

Would it be possible to make this template out of <div>s instead of a table. I constructed a prototype at User:Jared/sandbox8. I think that it looks just as good (if not better) and eliminates the problems of spacing that tables cause. _└^Jared_┘^┌_t^┐  20:41, 17 June 2007 (UTC)

Sounds like a good idea to me - unless there is a need for the current formatting style? ck lostsword • T • C 21:05, 17 June 2007 (UTC)

I've made the change based on the lack of objections. Resurgent insurgent 09:57, 21 June 2007 (UTC)

My knowledge of html/wikimarkup is poor. Was change made to make the code better? Also now the blue background stretches all the way across a page, instead of just where the text is. Was this the point of the <div> or a byproduct? If it is a byproduct could it be fixed? If it was the point then I'll accept it and get used to it. Thanks for any comments. Mehmet Karatay 19:58, 21 June 2007 (UTC)

I think that it was just a "byproduct" as you put it. What happens is that it now stretches 100% the width of whatever it is placed in, just because that is the nature of the div tag. If it is placed in a box that only spans half of your user page, however, or in an invisible table, it will be contained in that box, however wide it is. See this for example:

Committed identity: BLAH BLAH BLAH is a SHA-512 commitment to this user's real-life identity.

{| width=50%
| {{User committed identity|BLAH BLAH BLAH}}
|}

That is how you could in theory make it any width you want, if you want. Personally, I don't care what it does, but I think that making the template not a table is best just because most other wikipedia boxes use the div tag. See my user page for how I've used the tag myself. Note the space below it, too, which I could not make when it was in table form.

Now, if we could fix the spacing issues now, we'd be good, because right now I think there's a little too much padding between lines and on the top, bottom, and sides. No big deal, but it takes up a lot of unneeded space for a template that is supposed to be out of the way. _└^Jared_┘^┌_t^┐  20:29, 21 June 2007 (UTC)

Thank you. It's always nice to learn a bit more about the actual code. Mehmet Karatay 22:00, 21 June 2007 (UTC)

Edit request

{{editprotected}} It is utterly poor security practice to instruct people to send their supposedly secret strings to an unknown, untrusted server to be hashed. Thus, http://www.johnmaguire.us/tools/hashcalc/ should be removed, or listed with the caveat that it only be used for test purposes.

The other link, http://www.cs.eku.edu/faculty/styer/460/Encrypt/JS-SHA1.html, is acceptable as it runs in client side javascript. However, it should link to http://people.eku.edu/styere/460/Encrypt/JS-SHA1.html, where the current link now redirects. Feezo (Talk) 16:50, 16 July 2007 (UTC)

If what the user says is true, which I don't doubt, then I would agree with what the user says. It makes sense. _└^Jared_┘^┌_t^┐  16:56, 16 July 2007 (UTC)

The documentation is on an unprotected subpage, so there is no need for an editprotected request. I edited it some, and everyone else is also able to edit the doc page. — Carl (CBM · talk) 17:49, 16 July 2007 (UTC)

Oh, heh. Oops. Thanks. Feezo (Talk) 18:40, 16 July 2007 (UTC)

Help

I don't get how this works. Could somebody explain this to me? RuneWiki⁷⁷⁷ 18:38, 13 August 2007 (UTC)

Uh, thousand trillion trillion?

This cumbersome phrase is equivalent to "octillion" in modern short scale of US and British standards. See names of large numbers. Since I cannot edit the template page info here I would like someone else to do it, no matter how trivial it seems. People should learn their numbers, y'know.204.56.7.1 20:36, 16 August 2007 (UTC)

You can do this yourself — only the template itself is protected. The documentation is transcluded from Template:User committed identity/doc, which you should be able to edit. By the way, there's a template you can use on talk pages to make requests such as this; just prepend {{editprotected}} to your message. Feezo (Talk) 05:06, 18 August 2007 (UTC)

Changing

We need to include a section on changing the hash. I propose that from now on you need to get an admin to approve it. Or, if you claim your account was taken within 1 week of a change, then the change does not count. I think that an admin approving the change would be best so a hacker doesn't change the hash, then wait a month, then attack, which is possible. It would mearly consist of (securely) sending your passphrase to an admin who would hash it and check to make sure it is you, then the admin would edit your page with the new hash on it that you also send to them (but not the passphrase). I think that this might be controversial though, so we ought to have a disscussion. We will need to add this eventually, as people are bound to either (a) forget (like I just did....) or (b) want to upgrade the hash from perhaps the original SHA-1 that was advised when this first came out to a SHA-512 or a whirlpool, or whatever they want. What do you guys think?? - Hairchrm 04:55, 17 September 2007 (UTC)

That's one way of doing it. Another would be to just change the hash, but pick a new secret string that is related to the old secret string. Actually, I've been rolling around the back of my head the idea to make a new version of this based on an unconditionally hiding commitment: then people wouldn't need to worry about this brute-force attack. (Which, by the way, is an equally bad problem for every hash function people are throwing around.) Mangojuice^talk 11:41, 17 September 2007 (UTC)

I only know a bit of crypto, could you explain the uncondittionally hiding stuff? Or just wiki link it, I can read about it myself. As for everything else you said: Yes, if someone wanted to they could brute force and/or rainbow table an admin's account. It isn't like people are req. to change it every month. So after 3 months of the same one, someone could claim they lost their password, and remembered their UCId. They could regain the account and vandalize all over. Whoops. Some WP:BEANS on that one. Which also brings up the fact that there should be a mandatory 2 week period where a message is posted to the user page announcing that someone has claimed that this account has been 'jacked and that they responded with the UCId key. Then the real person would have time to ask for a checkuser and all that stuff. There are obviously some serious holes in the software that need to be changed sooner or later. Both for the whole WP and this template. Eventually, someone will hack more admins. No doubt about it. My guess would be sooner than later. - Hairchrm 00:57, 18 September 2007 (UTC)

I was going to point you to Commitment scheme but it barely mentions it, which is unfortunate. I think I had meant to add more info on this but hadn't gotten around to it. Ok, so basically, an unconditionally hiding scheme is one in which the commitment (which is really what we're using a hash for in this application) information theoretically reveals no information about the value that is being committed. An example is the Pedersen commitment scheme, which is similar to the El Gamal cryptosystem. In this commitment scheme, a large prime-order group is chosen with two random, distinct generators: g and h. To commit a value m (up to the order of the group), you pick a random value r (again, up to the order of the group) and publish g^mh^r. To prove your commitment is to m you reveal both m and r. The key thing to realize is that any commitment can be decommitted to any message in some way, but being able to find two different ways to decommit would be equivalent to solving the discrete log problem (ie, finding x such that g^x = h.) So, a very powerful adversary could break the binding property of the scheme, but no adversary could ever break the secrecy. Of course, there are difficulties using this scheme here. For one thing, this needs to be accessible to people, so a program would have to be widely available. Second, the choice of g and h and the group is sensitive: if done improperly, that person, and anyone they share the information with, can open anyone's commitment to anything, so the one who generates the g and h has to be trusted. Third, where will r come from? People will need access to a cryptographically strong pseudorandom number generator, which is another level of complexity. And also, people might do it improperly which might void the property we're looking for. However this is all pretty pointless because the attack people are concerned about doesn't work anyway. Mangojuice^talk 14:08, 18 September 2007 (UTC)

What do you mean it doesn't work anyways? I thought that the idea here is that if someone hacks your account (packet monitoring or whatever because it isn't TSL) then you could reveal that you have been hacked and that you are the real person. Thereby regaining your account. Of course, a simple checkuser might give the same reasoning... Why is this not possible? But I get your point that this would all have to be done easily for people. Getting the thousands of editor's here to do so without messing up would be quite a task. - Hairchrm 15:53, 18 September 2007 (UTC)

The attack that doesn't work is the so-called "brute force" attack; see my comment in the next section for why that doesn't work. The scheme here should work, if it is ever needed again, which it probably won't be. Mangojuice^talk 18:52, 19 September 2007 (UTC)

For normal cases, it shouldn't matter: if your account is compromised too close to your hash change, you can be asked to supply the information for both hashes. Similarly, if you forget your hash and change it and your account is not compromised any time soon you're also in the clear. All this seems to be far too much trouble for what is hopefully an extremely uncommon case: forgetting your hash information and then getting your account compromised soon after changing it; more likely is that you forget your hash information and don't realize it until you need it.

The best solution, IMO, would be to start using GPG if you're worried about forgetting the hash information and post the public key on your user page; then if you forget your hash you can prove you're you by signing your email with the corresponding private key. Or else you could beg CheckUser to verify that the hash-changing edit was made from your IP instead of the compromiser's ;) Anomie 12:01, 17 September 2007 (UTC)

Yeah, but that cannot be large-scale advocated by en.WP. Hopefully this won't happen much, but I would not be surprised to see some more accounts get taken soon. As computer speed increases, passphrases are less secure. - Hairchrm 00:57, 18 September 2007 (UTC)

WHAT??????????

When I first saw this template my thought was: "This is stupid, why publicly publish the hash, put it in the DB where no one can brute force it."

Then it occurred to me: MediaWiki does and it's called your password!

Providing a second hash is functionally identical to having a "backup password" on the account...except the hash is publicly published! This template should be immediately deleted because it's a thinly veiled attempt at security. Proving you know the secret key to a publicly published hash is asinine and farcical.

Believing that this "solves the internet identity problem" is ridiculously humorous. Not to mention that wikipedia doesn't use secure connections (TLS or SSL) so you immediately have a trust issue of the hash itself. Nothing is proven here except that cryptography cannot be done by laymen. Cburnett 16:38, 19 September 2007 (UTC)

People are always going on about this stupid "brute force" thing, so let me debunk it now. Hash functions compress data, they are inherently lossy. There is no such thing as a true "inversion attack" against a hash function. Rather, it is possible, given a hash value, to find some input that creates that output, by brute force. Put it this way: with 2^160 output values from SHA-1, there would be about 2^40 input values of 199 bits or less that lead to any arbitrary output. Each of those values woult take about 2^160 time to find by brute force, which is well beyond the threshold typically considered secure. And let's think carefully: if someone found all those 2^40 values, they might be able to identify which one was your actual secret string that contained your identity (imaging that your secret string was even that short, which it might be), by seeing which input is in mostly text in ASCII form. So the actual identity contained in the hash is, in fact, very well protected from brute force attacks. Unlike a password, the secret string here is not meant to be short, because it doesn't have to be remembered and typed accurately on a daily basis.

On the other hand, if someone just found a preimage that wasn't actually the secret string, I think it wouldn't fool anyone into granting access to the account in question: who's going to believe that I am Mr. @#)KLMNG90j3290(A:l1-20?

Eh. The article itself gives as an example 'My name is Joe Schmoe, and I can be contacted at: joe@example.com; random bits:fFfwq0DuDmMXj8hYTM3NTKeDhk'. As long as you're allowed to stuff the secret string with random bits, getting a pre-image is just a matter of exploiting the birthday attack.

Worse, even if you don't allow stuffing random bits, pick a bunch of fact(oid)s about the user, Include/exclude some of them, valid spelling variations, different ordering, valid punctuation variations, valid variations in capitalisation, and before you can google SHA1ZAM you'll have 80 bits to shuffle around without even having to stuff their dead childhood pet.

I love the idea btw. It's a good idea. I mean, somewhere, deep down, it's got the makings of a good idea in it. Just, when you're trying to be cryptographically secure, better not kneejerk like that when people point out vulnerabilities. Just accept them and fix it. — Preceding unsigned comment added by 94.212.39.49 (talk • contribs) 08:43, 9 March 2011 (UTC)

I added those random bits because I was worried folks would take the example string and substitute their name/email, thus making an easily guessable string. Like you said, typical birthday-attack shenanigans like punctuation/etc can be used anyway; so given that do you think the random bits are problematic? ErikHaugen (talk | contribs) 14:16, 9 March 2011 (UTC)

So such an attack, which is at least based on the strength of the hash function, doesn't accomplish anything much. This is not a password scheme after all - knowing the secret string doesn't just log you in to the account, you have to convince someone that the target account has been compromised and the password has been changed, and that you not only know the secret string but also you are the person described in the secret string. So, no hacker with a brain is going to spend any real effort attacking this, when it requires such huge effort and has such a dubious payoff... especially considering that these are Wikipedia accounts, which anyone can have for free if they want one... it's not like there's a big payoff.

As for the trust issue of the hash, I actually don't believe that is true. I am a trusted community member, and I have been acting in my relatively consistent way for a while now, and during that time I posted my hash value. If someone doesn't believe that *I* am the one who posted it, they have to believe that an attacker got control of my account and for some reason made valuable contributions to the encyclopedia for months, while I didn't notice the situation. In which case, the attacker is such a valued contributor, we might as well give them my account anyway. Mangojuice^talk 18:50, 19 September 2007 (UTC)

Your rationality is right inline with someone who doesn't see and understand the faultiness of this method.

1. I, for one, would use an arbitrary string ("@#)KLMNG90j3290(A:l1-20" would be a poorly random string at that) if it were the decider of my identity. I don't want it to be guessable in any way.
2. There is zero reason to publish the hash publicly. None. You aren't proving your identity to the world, just the WMF.
3. Not a big payoff? If there is no big payoff then why go through the whole shenanigan of what this template is for? If your account as an admin is worth nothing, then why bother?
4. Don't believe the trust issue with the hash is true? You have never heard of man in the middle attack or traffic sniffing in general, have you?

I really hope your PhD isn't in cryptography because you don't seem to understand even the basics to it (though you're quick to whip out the exponential like it was).

Let me recap: you have a publicly viewable, publicly writable hash which is read and posted over an insecure channel for the purposes of identifying a user whose account was compromised and whose authentication happens to be sent over the same insecure, public internet whereby the whole identity challenge is setup because compromised accounts do have a payoff...but not only do you not have a problem with this setup...you're proud of it. Not only am I completely mystified by your position but I'll have to give cryptography a once-over "just in case" because your complete and utter lack of concern makes me question your contributions on the subject of cryptography.

I'm not a cryptographer but I can quickly see the mistakes in people's reasoning regarding basic cryptography and security. I'm sure the creators of RC4, DES, SHA-0, and others thought their algorithm was pretty good. But trusting this identity system as a whole is a complete farce even if you discount brute force attack.

Please excuse me if my tone is condescending or curt, but contrary to the length of my reply you have left me otherwise speechless and mystified. And don't get me started on financial institutions using mother's maiden name and/or SSN as a security question...then you will hear true, intentional condescension. :) Cburnett 20:39, 19 September 2007 (UTC)

If wikipedia needed to have absolute security in each admin account, we would not have wikipedia hosted on a non SSL-TSL server. But, the WMF has decided that it is not necessary to have a SSL-TSL server (yet.) and hence I would argue that we do not need to have security on the account. A publicly posted hash could be considered a folly in some situations, but it is enough to protect the identity from a casual vandal. As Mangojuice said, even if the hash was cracked it would still be difficult to prove that they were the person. A simple checkuser could determine that it came from a computer somewhere else. The fact that WP doesn't use TSL is also a concern, but not a major one. Yes, of course a man in the middle would work. But who cares? The value of the accounts is to the user themselves, not the community. It takes years to become an admin, days to clean the mess. - ђαίгснгм ^таιќ 01:24, 20 September 2007 (UTC)

Thank you for recognizing the point of my argument. However.  :) You pawn off the severity of a compromised account when the login page spells out the opposite pretty clearly:

"If your account is compromised, it may be permanently blocked unless you can prove you are its rightful owner."

Sounds much more "deathly" than "oh, yeah, same IP...sounds good...your password is reset" like you're telling me here. Calling this template "insurance" against permanently having your account locked also bumps up the severity of having your account compromised.

The login page and this template indicate it's a [very?] big deal. You and mango indicate its a minor, trivial issue. If it's trivial then why have this template to begin with?? Is it just for the paranoid? Then why discuss ways to get the whole community to use it? Why put it on the login page?

Which is it: trivial or big? Cburnett 04:52, 20 September 2007 (UTC)

There is an SSL login at secure.wikimedia.org. --Gwern (contribs) 01:28 20 September 2007 (GMT)

I get: "Wiki does not exist" Cburnett 04:52, 20 September 2007 (UTC)

Yes, it's very user-unfriendly. secure.wikimedia.org is the root so to speak and it contains all the Wikipedias within subdirectories. So to actually visit, say, your watchlist on E, you'd have to visit https://secure.wikimedia.org/wikipedia/en/wiki/Special:Watchlist . --Gwern (contribs) 18:08 20 September 2007 (GMT)

I know this is not a fool-proof system, but the good thing about it is that it is a lightweight system. It doesn't require the developers to write any code, nor does it require a big infrastructure. Instead, it is a simple idea that is easy to deploy and adds a feature that, while not foolproof, is a good one. Obviously I know about the man in the middle attack, but Cburnett is making a mistake that a lot of amateur cryptographers make - not considering at all the kind of adversary we should be concerned about here. Should we be concerned about a very powerful adversary who can actually tap any internet lines in any place in order to launch an attack to corrupt a single Wikipedia account? No, not really: an attacker that powerful would have better things to do. What we should worry about is the attack that actually happened: an amateur hacker/vandal picking admin accounts and trying to guess the password. If you want to consider a maximally powerful adversary, yes, there are some ways around this system but nothing that would cause a serious problem.

Maybe a "better" system could be made where you had to get a digital signature from a trusted authority applied to your string first, and where the hashes were stored in the Wikimedia servers instead of in public, and could be accessed by any steward or bureaucrat. but that would require a lot of extra coding for the developers, who have more important things to worry about (like Bug 9213), and would require a bunch of extra education for those who would have to access that information so that the system would be usable. Not to mention that truly verifying someone's identity over the internet is basically impossible, and most users would find even the request to do this an intrusion on their privacy. Plus, the users would have to trust Wikimedia to keep their info secret, or would have to trust some outside group they know even less about. And, we'd have to upgrade to secure servers to avoid a man-in-the-middle attack when the Wikimedia foundation doesn't feel it's necessary (and I agree with them).

I'm reminded of the technique we use in packaging bottles of water, supposedly to prevent tampering: we have a cap that separates into two pieces, one of which is hard to get off the bottle. This system really doesn't do anything against someone powerful devoted to breaking it (you could just make your own bottles and cap them, with contaminated water inside, and it wouldn't be that hard to make your own bootleg copies of recognizable labels) but it prevents someone from going to their local store and poisoning someone by simply opening a bottle. And, the system is cheap: it's basically as cheap to produce those enhanced caps as it is to produce non-enhanced ones, once you upgrade the machinery. And it enhances the product's value because people feel safer buying them.

Obviously, a lightweight solution isn't a good idea if it creates a vulnerability. But there is none created here - finding a hash preimage of any admin's committed identity would allow you to try to spoof that a corruption had occurred, but without the admin's account having already gone rogue and having been blocked, this would not convince anyone, at least not without someone looking into it more carefully. Plus, it's very difficult to find that preimage to begin with. So, you'd have to do both: hack their account and their committed identity. Even if it requires no effort to break the committed identity, this is still not worse than it was before. And the attack required to actually recover someone's identity is not realistic. Mangojuice^talk 13:55, 20 September 2007 (UTC)

Mango makes some pretty good points here, and I think that we will all agree that this is not the most perfect solution ever. But, it provides an extra layer of security. It isn't hurting anyone, and it uses very low resources compared with actually programming a measure into the mediawiki software. I would say that its possible benefits much outway the detriments. I would say that this will go under a few revisions before finally making a really good way of saving your account. In fact, it already has, it originally started as a SHA-1 hash, which is way less secure than the current 256 standard. I believe, and obviously the community does too as they are using this template, that its benefits outway the problems, and that it is worth it too add to your page. 207.145.61.58 19:01, 20 September 2007 (UTC) (That is unlogged in User:Hairchrm)

Let us make security simple but unbreakable

User should sign up two accounts with two different long passwords. And let the user declare on two security user pages that two users are one and the same.

Something like this...

1. User:viran- I do declare that user:viran and user:xyz are one and the same person.

2. User:xyz- I also declare that user:viran and user:xyz are one and the same person.

If one account is compromised, user can log in with second account and alert admin.

Also user should openly give email addresses on two security user pages from two different reputed sites like gmail and yahoo which he/she provided at the time of signing up. If both wiki accounts are compromised, user can send email from addresses he declared to administrators and administrator can send new passwords by email.

After declaration, these two security userpages should be locked by admin. User can also do it automatically by inserting specific template.

By security user page, I mean other page created by wiki specifically for security purpose only.

The hacker will have to break two accounts on wiki and two accounts on gmail and yahoo.

I can extend it to 5 usernames and 5 email addresses but two are enough.

But in first place, if the user enter wrong password three times, his account should be frozen for few hours. The real user can still acces his account because he/she is permanently logged in on his/her computer.

If there is some flaw in my security, please let me know.

This is neo !!! 19:22, 23 September 2007 (UTC)

It's not a bad system, but (1) there's no reason to have those pages "locked by admin" - anyone can go back through the history of the page and make sure that only the right people made the important changes, and (2) I'd rather not endorse a scheme that gets people making unnecessary extra accounts. A simpler but very similar method would be for you to just post an email address on your user page -- doesn't have to be your main email address, just one you can access... and then use that if your account gets compromised, and point back to the diff of you posting it on your userpage if it is no longer up. Mangojuice^talk 21:54, 23 September 2007 (UTC)

I don't know how long history of page is stored, hence I said locking it.

And I agree with you. One email address is enough.

I don't understand this hash, cryptography stuff. I think most of users don't. This is neo !!! 22:34, 23 September 2007 (UTC)

History is supposed to be stored forever; there was a server crash once but that shouldn't be an issue anymore. If you don't understand the system proposed here, you might as well use another one if it makes sense to you. This is not really something that is likely to be an issue for anyone, it's just to make you feel safer. Mangojuice^talk 02:41, 24 September 2007 (UTC)

I think it goes like this:

1. You put your secret string through the hasher, and put the output on this template on your userpage.
2. You're account is comprimised, and you have been blocked. But, you have a hash.
3. Hacker leaves your account.
4. You post on your talkpage or e-mail an admin your secret hash string. That string, once put through the hasher, will match the hash which is displayed by this template, and the admins are convinced it's you.

I think that's it. --əˈnongahy ♫Look What I've Done!♫ 22:45, 23 September 2007 (UTC)

Yes, that's what goes on now. I think that User:Viran(This is Neo) has a good point, but I don't think that we would need to go to such great lengths to do that. Instead of two accounts, two passwords: also known as this template as your secondary password. As for email, you can already choose to put them on. I don't think that people should be forced to keep their accounts secure; unless, of course, they are an admin or crat. Nobody cares if some user like me goes on a rampage. In 1 minute I'm blocked and my edits rolled back. On the other hand, an emergency de-sysoping takes a b-crat to do it. Even if we got one in 5 minutes, if the main page is unprotected and some other major articles along with perhaps a bot attack by this rogue (the most likely story if the account is actually hacked by a professional) account, then it will cause some trouble. So some form of security is necessary for those accounts. This template is not security; it is a safeguard. Or maybe an ambulance. Everyone thinks your dead. Lucky for you, you have a UCI. Hopefully, the docs will bring you back to life. I don't think the acount should be frozen, but the captchas that are up now seem to work. - ђαίгснгм ^таιќ 23:29, 24 September 2007 (UTC)

When we login and go to preferences, we see user Id number. Nobody knows it except user. So that user ID can also be used to convince admin that it is indeed your account.This is neo !!! 12:22, 25 September 2007 (UTC)

Admins can't see that number for other users, and in any case, they can't change other users' passwords for them. I'm not sure how that ID number can be seen by other people. Mangojuice^talk 18:04, 25 September 2007 (UTC)

If anyone logged into the account can see the number, then whoever hijacked the account can see that number. Also, unless you use the secure gateway that number can be seen by anyone sniffing the network. Anomie 13:51, 26 September 2007 (UTC)

Not to mention that anyone with toolserver access can look up any user ID, and in all probability anyone who has downloaded a SQL dump could also run such a query. For example, Jimbo Wales's account ID is '24'. --Gwern (contribs) 01:55 21 October 2007 (GMT)

Gwern beat me to it. Almost anyone can figure this out:

mysql> select * from user_ids where user_name = 'Viran' or user_name='Mangojuice' or user_name='Anomie';
+------------+---------+
| user_name  | user_id |
+------------+---------+
| Anomie     |  301903 | 
| Mangojuice |  178098 | 
| Viran      | 5309441 | 
+------------+---------+
3 rows in set (0.03 sec)

That's from a very simple query, and the same data is likely to be in the dumps. ANY INFORMATION ASSOCIATED WITH YOUR WIKIPEDIA ACCOUNT, INCLUDING USER ID NUMBER OR EMAIL ADDRESS, IS NOT SECURE. These are certainly good components that would help protect against brute force scans, however there must be something that no one else on Wikipedia can associate with you - where you live, a phone number, whatever. --uǝʌǝsʎʇɹnoɟʇs 02:00, 21 October 2007 (UTC)

Am I less safe now?

Okay, I just did this for the heck of it, but now that I read this page I am confused...am I *less* safe now that I have posted that Hash String thingy on my user page? I cannot undo it, it is in my history forever. But, my further question is, why would someone *want to* commandeer my cheese-ass account in the first place? All I do is nit pick grammar and bring obscure artist articles over from the French wiki, and maybe, sometimes, argue a point on a talk page somewhere just out of boredom. And anyone can edit. Wiki isn't the Manhattan Project! Why is secrecy necessary? Saudade7 21:04, 8 October 2007 (UTC)

I don't think you're less safe. I'm trying to figure out what is this template for. Imagine that :

1. You're married to a beautiful woman.
2. She discovers that you are seeing her sister (!), and quits you.
3. She wants revenge and she
   1. knows your usual password
   2. changes your wikipedia password
   3. changes your mail password
   4. you're stuck !
4. Now she starts to publish things on wikipedia. Things on your own page ("I'm zoophile", "Bill Gates is my friend", "I love proprietary technology", ...). Terrible things.
5. What can you do to stop this ? Well if you placed a hash on your page, you can now ask to have a new password sent to your new mail address.

I think that's what this template is for, simply. As said above, it's a bit like a second passsword, without the overhead of implementing it inside mediawiki, without the need to make it mandatory. It is not a template against hackers. It's against malicious relatives.--Fenring 14:53, 12 October 2007 (UTC)

Grammar mistake

You think we can change an to a(n)? Thanks. -Domthedude001 22:27, 18 October 2007 (UTC)

Use {{User committed identity|...|article=a}} if you prefer "a." I think better not to modify the template, some people like it one way while others like it the other way. Mangojuice^talk 02:33, 19 October 2007 (UTC)

See the archive for the last time this came up. Anomie 02:39, 19 October 2007 (UTC)

You know, actually, I think we should change the default to "a". "SHA" is pronounceable as a word, so I think most people pronounce it that way. Plus, see this from GoogleFight: "a SHA-1" is much more popular on the web. Mangojuice^talk 02:54, 19 October 2007 (UTC)

That "GoogleFight" site doesn't seem to be very good. It claimed 0 to 226, but actually running the searches gives about 15,200 to about 46,600. For SHA-512, it seems to be 2,020 to 1,730, and SHA-256 gives 1,330 to 637. Personally, I suggest just using the article parameter to match your pronunciation on your userpage. Anomie 03:24, 19 October 2007 (UTC)

Sorry, you should adjust your searches to include "-wikipedia." The use on Wikipedia (probably from this template) seriously skews the results. For SHA-512 without Wikipedia hits, I get 1310 to 191 in favor of "a"; for SHA512 (no dash), I get 297 to 75 in favor of "a". For SHA-256, I get 600 to 1190 in favor of "an", but for SHA-1, I get 43,700 to 12,800 in favor of "a". Also instructive is to look at where those hits occur: "a SHA-1" is used at prominent sites like apple.com, rsa.com, and Bruce Schneier's blog. So I am going to make the change: you're quite right, people should have the choice, but this makes it clear that "a" is much more popular, and therefore should be the default. Mangojuice^talk 03:43, 19 October 2007 (UTC)

I have suggested changing the choice of indefinite articles to the definite article, "the". "The SHA-512" "The MD-5" etc. This removes one more parameter that confuses the non-techie. Less is more. Occam's razor. Principle of least privilege. KISS. "“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” -- Antoine de Saint-Exupery Regards, Unimaginative Username (talk) 06:01, 15 June 2008 (UTC)

Secure the login page

I have been wondering for a while, since the main Login page has warnings against phishing, etc., why this login page isn't secure. Non-secure sites like Yahoo still use secure connections for the transmission of login info. I didn't know where to ask, but this seems like a good place. Unimaginative Username 09:02, 11 November 2007 (UTC)

Well, using an encrypted connection wouldn't help with phishing since that's an off-site issue. Packet sniffing, possibly, but that shouldn't be an issue unless your wikistalker happens to live across the street. =] — xDanielx ^T/_C\^R 09:23, 21 November 2007 (UTC)

Can't many people along the Net view the traffic? Why else would banks, etc. use SSL? That's why Yahoo uses SSL for the login. My Wikistalker could live anywhere, work for a Net backbone provider, etc. "Best Practice" is that logins aren't sent in the clear. I know it isn't a phishing issue; I was just contrasting the care exhibited in that area with the lack of security in the login area. Regards, Unimaginative Username (talk) 05:15, 15 June 2008 (UTC)

Factual error about brute forcing

15 alphanumeric characters means about 10^23 possible combinations, not 10^27. There are 37 different kinds of alphanumeric characters, and 15 of them together means 37^15 different combinations, which works out to 10^23.523

--Simon80 (talk) 13:38, 18 November 2007 (UTC)

26 lowercase letters, 26 uppercase letters, 10 digits, and space is 63 characters, not 37. $\log _{10}\left(63^{15}\right)\approx 26.9901082$. Anomie⚔ 15:47, 18 November 2007 (UTC)

What is this?

Can someone please explain to me what this whole thing is exactly? Thanks. —Preceding unsigned comment added by 70.146.3.191 (talk) 23:14, 6 December 2007 (UTC)

On a related note will someone please put up a list of simple instructions that simpletons like me can follow to use this "hash" thingy thing? Thanks.<br. />--NBahn (talk) 18:50, 17 December 2007 (UTC)

To answer both queries: look at Template:User committed identity; both things are pretty well-documented. Mangojuice^talk 20:22, 17 December 2007 (UTC)

Basically, you put something in a hash calculator (it encrypts/encodes text) like [this one] and take the result, then put it on your userpage. If your account gets hacked, you can tell someone what the original text was, and when they encrypt it and get the same result, they'll know you're you. Simpler example: Pretend reversing the letters in a word is a secure code that you can't figure out. Just pretend that you can never figure out that tac backwards is cat. So you use the word cat, and get tac. You put tac on your profile, so if you get hacked, the word cat proves that you're you, because no one else would know that the original word was cat. See also Commitment_scheme --cuckooman4 (^t/_c) 04:24, 19 December 2007 (UTC)

It seems the documentation is not so clear; I found what looks like a misuse at User:Q_Valda where the user just typed in his chosen string, without getting a hash. I agree with NBahn that simple instructions (with examples of a chosen text, resulting hash string, and a template using that hash string) would be helpful. Reading through the instructions it speaks of choosing a string and entering the hash string; the equivocal uses of the word "string" might be part of the problem; maybe speaking of choosing a text and entering a hash string would help clear up that ambiguity. --SteveMcCluskey (talk) 23:07, 19 February 2008 (UTC)

Please see if this new section below is helpful. Thanks, Unimaginative Username (talk) 06:15, 15 June 2008 (UTC)

How to use sha512sum?

So if i want to create a hash using sha512sum, i would type

   sha512sum<Enter>SecretString<Ctrl+D>

and not

   sha512sum<Enter>SecretString<Enter><Ctrl+D>

as these two create two different hash'es? Kagee (talk) 08:48, 3 January 2008 (UTC)

If you read the sha512sum(1) man page, you're supposed to provide your secret string via standard input, with no filename as parameter to sha512sum, or "-" as the filename (indicating stdin). Like such:

   echo "The quick brown fox jumps over the lazy dog" | sha512sum -

which yields, on my system:

a12ac6bdd854ac30c5cc5b576e1ee2c060c0d8c2bec8797423d7119aa2b962f7f30ce2e39879cbff0109c8f0a3fd9389a369daae45df7d7b286d7d98272dc5b1  -

(i don't know why it suffixes it with the spaces + dash, it does it whether or not i specify the dash option to sha512sum)

Now, what troubles me is that i thought i'd check with the suggested web site (the sample passphrase is their example), and there i get a different string:

07e547d9586f6a73f73fbac0435ed76951218fb7d0c8d788a309d785436bbb642e93a252a954f23912547d1e8a3b5ed6e1bfd7097821233fa0538f3db854fee6

This troubles me. I did select "SHA 512bit", and it reports it used "sha512". What did i do wrong? --Jerome Potts (talk) 22:15, 22 March 2008 (UTC)

Echoing the text and piping it into sha512sum will append an EOL on it. If you type sha512sum, type "The quick brown fox jumps over the lazy dog^D^D", you'll get the right answer. -- ShinmaWa^(talk) 12:47, 3 July 2008 (UTC)

Or use the "-n" option to echo. Anomie⚔ 23:08, 3 July 2008 (UTC)

Jerome, the hyphen at the end is the name of the file that was hashed, in this case standard input. The format is designed so that you can hash a whole series of files, save the hashes to a file, and later use the -c hash-list option to automatically check the hashes stored therein. I believe all of the *sum utilities use the same format. This is used especially in e.g. package repositories, liveCDs, etc.; if you have a liveCD or liveDVD of Knoppix, have a look at /KNOPPIX/md5sums on the disc to see what I mean. HTH. ddawson (talk) 17:19, 9 July 2008 (UTC)

Public Key-based Equivalent?

Someone please correct me if I'm wrong, but, say that someone like me has a GPG / PGP key.

They post their public key on their user page.

That's it.

If the account gets compromised, the person can send an e-mail consisting of, well, anything, signed with that key to the designated person, the person verifies the signature with the posted public key, and the account is returned to the rightful owner.

Advantages of this, I suppose, would be:

• The secret (in this case the private key) never has to be given to another person, not even the admin verifying you.
• The message sent to the admin can be anything, it doesn't have to be a precomposed and then remembered-forever string.

At least in my mind, this seems to be superior to the current (hash-based) method. Has this idea been considered previously and rejected for some reason?

Yvh11a (Talk • Contribs) 04:35, 18 February 2008 (UTC)

• Update Disregard that last bit--I didn't read the archives. Turns out it has been discussed already. However, since no consensus was reached, I still say public keys make more sense than a hash method. Yvh11a (Talk • Contribs) 07:28, 18 February 2008 (UTC)

You probably store your private GPG key on your PC, and if someone has access to your password, he probably has to your GPG key as well. The hashed string is supposed to be in your head only. The only way is to force the string out of you, by torture ;-) --Fenring (talk) 09:54, 18 February 2008 (UTC)

When I designed this, I chose to use hashes rather than a public-key method because I think it's easier to set up for an average user. Also, I wouldn't use the simple post-a-PK method because the secret string should mean something rather than just being random. There are public-key crypto methods that can incorporate an arbitrary string (many discussions on here have made me want this to work with a perfectly hiding commitment scheme, for instance) but those seem technologically intimidating for what is meant to be a lightweight system. Mangojuice^talk 17:20, 18 February 2008 (UTC)

Valid point, Mangojuice. I'm going to stick with my public key, but for the average joe, you're right; good enough is good enough. For clarity's sake, I'd like to mention here that I wasn't advocating the use of a random secret string...you're absolutely right that the string should mean something, my point was simply that the string need not be chosen beforehand. Yvh11a (Talk • Contribs) 04:50, 27 February 2008 (UTC)

I forgot. Also, another problem with posting your public key is that if you use the same public key for Wikipedia as you do for everything else, it may create a way for someone to find out more information about you. (You don't seem to be doing this, though, but I just wanted to mention it.) Mangojuice^talk 12:05, 24 March 2008 (UTC)

Which is why many of us have created new public keys specifically for wikipedia. -- Avi (talk) 12:13, 24 March 2008 (UTC)

Actually I did exactly that, and then realized that I just wound up using my primary key for everything anyway. I figure a possible, minor loss of privacy is within my risk tolerance given the huge, certain gain in security. --Yvh11a (Talk • Contribs) 00:16, 25 March 2008 (UTC)

If you ever change your mind, let me know; I'm willing to delete old versions of your user page to hide the public key. Mangojuice^talk 14:42, 25 March 2008 (UTC)

Ditto. -- Avi (talk) 15:09, 25 March 2008 (UTC)

You may also want to look at Category:Wikipedians who use PGP. Many of us have posted our public keys on our user pages, and generic-level certification has been known to have occurred via encrypted challenge-responses. -- Avi (talk) 01:12, 3 March 2008 (UTC)

Cool. My public key is up. Appreciate the link. Yvh11a (Talk • Contribs) 01:08, 24 March 2008 (UTC)

I would like to add to this discussion that it's easier to listen in on a user's password than to play man in the middle when someone likes to confirm your identity using the PGP method. And you can post your public key using the secure sever, to be certain that the public key on your user page is actually your key and not the key of someone pulling a man in the middle attack. That would be true for this template too, but the use of a public key would have the additional benefit of establishing a secure channel of communication. Shinobu (talk) 09:34, 25 April 2008 (UTC)

I also think that hash-based verifications are completely useless:

• first, you need to reveal your secret to someone that will verify it, however there's absolutely no way to assert that you can trust anyone for keeping your revelation secret.
• second, even if you trust that person, there's no way to find a secure communication link with that person you trust and being sure that you are talking to the right trusted person.
• third, the communication link may be monitored, listened by a third party, so he will receive also your revelation.

May I suggest to completely deprecate this method that will not help anyone in the case an account has been compromized? Looks like there's not even any established secure link to allow such verification. At least to make this hash-based scheme workable, it should be performed by a robot hosted by the WMF, possibly through a SSL-secuired form, but not any person (not even an admin). The robot will just be able to indicate to admins that some IP at a given time has effectively verified the listed hash. Then the admin could use the robot log listing the IP, time, and hash, and an IP verificator could assert that the published online discussions or contributions are effectively from the right person within a limited timeframe (not exceeding 24 hours). 16:28, 18 June 2008 (UTC)

Feel free to suggest, but you are overreacting to the circumstances. First off, the whole point of this was to be lightweight, so that the WMF non-profit doesn't have to spend valuable time and resources implementing a built-in solution. Second, if you are really concerned about someone snooping your message to the restorer, you could always use traditional PK cryptography to encrypt your message. Furthermore, if you're this security-conscious you probably don't need this: just choose a good strong password and you'll be fine. I am also unaware of anyone having EVER actually used this system to recover an account: this is really for peace of mind more than anything else. And in fact it probably won't ever happen. Mangojuice^talk 18:55, 9 July 2008 (UTC)

And of course (I'm surprised Mango didn't say this), a bot can't verify that the secret contains meaningful information. And besides, given that it's controlled by humans, can you trust it any more than a human? ddawson (talk) 20:34, 15 July 2008 (UTC)

Suggestion for commitment value

I had a thought recently: what if someone were to simply copy the commitment and use it as their own, say on some other site? If this person were to then do something malicious with his/her account at that site, it would appear (at least to a naïve person) that the perpetrator is the same person who originally made the commitment. I'm sure it's extremely foolish and/or useless to do something bad with one's own identity committed, so this might not fool anyone, even someone who didn't try to prove the identity.

Still, for the sake of paranoia, I think there is an easy fix: tie the commitment to the page on which it appears, by including the URL or the name of the site, or something similar, in the secret. Does this sound...well...sound? Maybe something to consider suggesting in the template docs? Ddawson (talk) 00:35, 25 February 2008 (UTC)

A naive person could just as easily be fooled by a user perpetrating abuse elsewhere that shares a username with a Wikipedian, or claims to be them explicitly. The commitment itself proves nothing, it's the ability to open it up that proves something. That said, someone could copy a committed identity, and if they are able to observe the original user actually opening it, they could open theirs as well. That said, I see no reason why the secret string shouldn't include all sorts of corroborating data, like "this is for Wikipedia only" or whatever. I hesitate at the idea of adding this to the docs, but only because this whole concept is hard enough for users to understand without the more subtle aspects being highlighted. Mangojuice^talk 06:21, 26 February 2008 (UTC)

Easy how to

I consider myself rather computer literate, but after reading this page I am still not sure how to 'commit myself'. If somebody can create an 'dummy guide' for a user using Windows it would be great. My guess is that one should go to http://www.hashemall.com/ ; enter some text in the top box, and then use it as the hash string parameter in the template, leaving the hash function used blank. But if this is the case, the current geek-to-enlightened geek text does not make it obvious (remember that most people have trouble editing a wiki or understanding what a strong password is, so if we want them to have a 'committed identity' we should make the 'how to' as clear as possible.--_{Piotr Konieczny aka Prokonsul Piotrus| talk} 22:57, 3 March 2008 (UTC)

No, don't use an external service to get the hash value! You don't want to have the secret string available outside your own computer (otherwise it's not really a secret). Don't trust anyone else with it (at least unless you have to open the commitment); you never know what some web server out there will do with the secret. Better to use a hash generator that you can run on your own system. Best to use one that's open-source, so it's verifiably clean. Ddawson (talk) 11:34, 4 March 2008 (UTC)

Piotr, I can help you set one up: email me. Ddawson is right that you shouldn't use a web hash calculator. Mangojuice^talk 13:48, 4 March 2008 (UTC)

Template talk:User committed identity/Archive 1#Offline software -- Avi (talk) 17:23, 4 March 2008 (UTC)

I see; it would be a good idea to clarify that point in the template how to and provide links to those softs.--_{Piotr Konieczny aka Prokonsul Piotrus| talk} 17:53, 4 March 2008 (UTC)

I've added them to the doc; thanks for the suggestion. -- Avi (talk) 17:58, 4 March 2008 (UTC)

Your wish is my command. Dummy guide here, and I added a new topic to this page to try to help others who come here looking. Regards, Unimaginative Username (talk) 05:46, 15 June 2008 (UTC)

Whirlpool

There needs to be some clarification in the instructions for using the Whirlpool algorithm. When entering SHA-1, the parameter is

{{User committed identity|0000000|SHA-1|background=#FC9|border=#000}}

but the correct parameter for use with whirlpool is

{{User committed identity|0000000|[[Whirlpool (cryptography)|Whirlpool]]|background=#FC9|border=#000}}

  — C M B J   00:10, 19 May 2008 (UTC)

I don't get how to use this....

so...would I place this on my Userpage or something?

Would it be something like

{{User committed identity|something here like a phone number/email combination|SHA-512|background=#00FFFF|border=#CC0000|article=Lupin the 3rd}}

to get

Committed identity: something here like a phone number/email combination? is Lupin the 3rd SHA-512 commitment to this user's real-life identity.

???--AutoGyro (talk) 19:54, 21 May 2008

Or do I enter the email/phone number combination into something that would give me a code, and then I take that code and enter it into the hash string field? What's the point of the "article" field?--AutoGyro (talk) 19:57, 21 May 2008 (UTC)(UTC)

Enter the email/phone number combination into something that gives you a code, as described at Template:User committed identity#Getting the hash. The 'article' field is to select "a" versus "an" for correct grammar. Anomie⚔ 22:39, 21 May 2008 (UTC)

Code override option

Can we get an option to remove the padding? I'd like to have the ability to incorporate it into my userpage better. Or perhaps an option to override the entire header and footer (everything before and after the text itself)? +Hexagon1 ^(t) 02:02, 25 May 2008 (UTC)

I don't think that's going to be such a common request. Why not just subst the template and then modify the result however you like? Mangojuice^talk 14:03, 26 May 2008 (UTC)

I was assuming there's some sort of horrible code construction and subst'ing it would break the Internet.. +Hexagon1 ^(t) 06:05, 6 June 2008 (UTC)

Here's one more of those uncommon requests: I don't know what the heck "subst"-ing is, but I would like to enter some text at the end, after "...user's real-life identity", and keep it inside the same orange box, with no more than a typical sentence space between "identity" and the next sentence. Can anyone tell this dummy in *simple English* how to modify the template to do this? Thanks, Unimaginative Username (talk) 05:44, 12 June 2008 (UTC)

You have to subst it. Here's what you do. Instead of putting "{{User committed identity|(other inputs)}}", put "{{subst:User committed identity|(other inputs)}}", save your page, and then edit it again. The text inside the box will now be there, and you can just add some more stuff after "user's real-life identity" or modify it however you like. You can't do this without substing the template. Mangojuice^talk 16:03, 13 June 2008 (UTC)

Excellent! A nice, simple, plain-English explanation, and now I've learned about "subst". I also had to move the </div> things around, take out some space, etc., but I got it done. Thanks for helping the markuply-challenged! Unimaginative Username (talk) 04:38, 14 June 2008 (UTC)

Simple, plain-English, step-by-step instructions here

In response to numerous questions about this process, I wrote a guide for my fellow dummies. Please try it out and see if it helps. User:Unimaginative_Username/Simple_Committed_ID_Instructions Regards, Unimaginative Username (talk) 05:44, 15 June 2008 (UTC)

I wish you wouldn't recommend people away from including their identity in the secret. This is, after all, part of the idea. Put your identity in there, it can be only part of the string, but that way you have an extra layer of assurance. If someone else did guess my secret, they'd then have to convince an admin that they are me in real life. Mangojuice^talk 13:50, 16 June 2008 (UTC)

I debated that. It's a tough issue. The cons are: The more your secret is tied to you, the more likely it is to be guessed by someone who knows, or discovers, your address, phone, email, etc. And, that WPians differ greatly in how much of themselves they care to reveal online. Someone might not want to have to tell an admin or whatever her real phone #, address, etc. just to recapture her account. I could e-mail my secret to (uh, who would I email it to?) from the email address that is linked to my account, and if it hashes correctly, wouldn't that be pretty strong proof that I'm the account owner, while still preserving my privacy? Even if someone also compromised the linked email account, they'd have to guess the secret to complete the hack. Hence my recommendation. Kind of like the old "mother's maiden name" thing -- anyone can go online and look at your birth certificate, then your mother's birth certificate. When I get challenges like that from a bank as "extra security" (haha), I make up something like "Koznowlofskiya" or 34%%^vD2@. I'd like to see someone guess that :-)

Thanks for the thoughtful reply. I'm open to hearing other sides of this issue, and also what you thought of the simplified version generally. Regards, Unimaginative Username (talk) 07:05, 17 June 2008 (UTC)

My thoughts:

• How exactly is "Bears dance with chickens" harder to guess than "J. Random Wikipedian -- Bears dance with chickens" or "j-random@example.com -- Bears dance with chickens"?
  • It isn't. But the guesser knows that you are JRW, and might know you are JRE@E.com, and some of the non-techies who have asked questions have been confused by the various pieces of advice. (Check the topic and archives.) So in the interest of KISS, I went with random nonsense rather than have the novice read through the extensive debate on what to put in your string.
• In step 14 you say "do nothing to 'hash function used'", which will result in the template displaying "This is a hash function used committed identity...".
  • I may have misunderstood the instruction, "The "hash function used" parameter, if not included, defaults to SHA-512. (This hash is recommended.)" Which proves my point: that dummies like myself find the instructions confusing. I guess what was meant was that The "hash function used" parameter, if deleted (i. e., from the template) defaults to SHA-512... . Please confirm if this is correct, if so, I'll gladly change the SI. Thanks for the catch -- that is one reason I asked here for feedback.
• As for using the definite article, IMO it sounds a bit off to use that instead of the indefinite article in this circumstance. YMMV.
  • I don't know what YMMV means. (Over-assumption of recipient knowledge base being a pandemic disease of our time, not just here.) I don't get what's wrong with "ABCD is the SHA-512 hash..." but again, if you look at the queries here, you'll see that this "article" parameter has confused more than one Earthling. See generic comment below.
• For a simplified version, why get into telling the reader how to change the colors or to pick an arbitrary hash (they might end up with CRC32) or to leave out the SHA-512; just tell them to pick either SHA-512 or SHA-256, and then to copy-paste their hash into whichever version of the example matches their choice.
  • Not a bad idea. I guess I was contradicting my stated intentions in a way, but I also have the belief, as an acknowledged dummy, that it's a bit easier to follow instructions if one can be told *why*, in language they understand. Plus, they might actually learn something, again, at their own level. But it's a good point. Will give it serious thought. Edit: I just realized that I could start with the color-included template under "Syntax" instead of the general template, and cut out a lot of the steps. Will do within the next day or two. Super idea - Thanks!! Unimaginative Username (talk) 07:41, 18 June 2008 (UTC)
• Also, IMO, the tone of your writing there is far too chatty and trying-to-be-funny for a howto. Steps 22 and 23, for example, are completely unnecessary.
  • Taking those in reverse order, Step 22 is there because many zero- or low-knowledge users prefer to do a test case first, where they can compare the outcome to the proper one. Please go back to Step 7. The user is invited to hash "Fargo, North Dakota" with two different hash algorithms and compare results, to be certain that they are using and interpreting HashCalc correctly. For example, please see Template_talk:User_committed_identity#What_is_this.3F, where it was noted that user Q_Valda had simply posted his/her unhashed secret. This would likely not happen had Q_Valda done the test run as suggested.
  • Regarding #23, I do believe it's useful to point out to the user how to use the result of this process if needed. And I did ask somewhere on this page where and how the compromised user should send the secret.
• IIRC, you're wrong in step 23; this actually was created after a rash of admin-account breakins a while back.
  • I wasn't aware of the rash of break-ins. If you do indeed remember correctly, please point me there, and I'll edit this section. Thanks.

Hope this helps. Anomie⚔ 11:15, 17 June 2008 (UTC)

• • It is very helpful, Anomie. This is why I asked for other eyes to review the work. As for the chatty tone: I have taught professionally in many different areas, ranging from academic to athletic to business, often remedially (i. e. to those who "didn't get it"), and often to brand-new, absolute zero-knowledge beginners. It has been my own experience that a more casual and friendly tone connects better with those who might already be intimidated, frightened, discouraged, etc. People who are comfortable with coding don't need my help. Those who know nothing of it, or of any other subject, often appreciate and do better with a guide who exhibits empathy for them.
    
    Please allow me to bore you further by telling you what inspired this article. I came here to try to add the hash to my page. I am a coding dummy, but I enjoy playing around with stuff and learning new things. Eventually, I got it figured out. But (not to embarrass anyone) I saw the many other queries, including this one from 21 May 2008. You gave a concise and perfectly correct answer. But being curious about the many inquiries, I went to that user's page to see if the ID was there. It wasn't. I left the user a message asking if he were still interested in the ID and would like a simple walk-through, and received an enthusiastic "yes". (No links -- please dig it up if you like. I'm putting this user on the spot enough already.) I then looked at several more such inquiries, noting that in most cases, after the questions were answered, the ID still did not get on the user's page. Hence the conclusion that Simple Inx might be needed, and my humble opinion that a lot of people who were originally interested came here, took a look, said "WTF "huh?" and left, never to return.
    
    It is very difficult for the cognoscenti in any field to comprehend how puzzling their jargon and inner knowledge are to novices. (Trust me on this.) Not everyone who can use a computer can program one. For those of you who were born after the Internet was, all of this comes very naturally. For those of us who were born before the Internet, learning all of this is like starting to learn a foreign language, with minimal instruction, on one's own time, without a teacher, at the age of... n/m. Regrettably using self-example again, this user is/was a multi-Barnstarred copy-editor, blah, blah, but still has not mastered all Wiki markup. One gets a computer, starts participating -- need to use a little HTML. OK, learned a tiny bit of HTML and its principles. Join a forum. Uh-oh, HTML not working here. Forum uses BBC. Must learn a little BBC. OK, come to WP. Must learn WMarkup. Want protected identity. Must start learning some coding. (Believe it or not, the overwhelming majority of computer users don't know the code-specific meaning of words like "parameter" and "string". If that's hard to believe, that proves my point about the difficulty of empathy by the knowledgeable.) I guess I would like to make this process available to as much of the masses as possible -- just as WP's mission is to make *all* knowledge available etc. I am very much open to guidance and feedback in doing so, just as the experts should be open to feedback from the puzzled, if they truly wish for all to use their techniques. Thank you so much for your thoughtful feedback, past and future. Regards, Unimaginative Username (talk) 07:18, 18 June 2008 (UTC)

UU, as for the email account linked to the account, if an account gets compromised, the email account can be easily changed, so it wouldn't prove anything to use it. Mangojuice^talk 12:37, 17 June 2008 (UTC)

• Good point. But if I use the e-mail that was linked to the WP account at the time the hashed ID was posted on the userpage (surely this history would be available to admins, no?), and send the correct secret, wouldn't that support me? Also, a challenge could be sent to the "new" account created and linked by the haxor, requesting the secret. If I answer from the Old Email, and David Lightman, who is pretending to be me from the New Email, can't, don't I win? Using my WOPR (Wikipedia Ownership Proof of Reality). (Uh-oh, there I go again, violating WP:NOHUMOR. There, I've been warned.) Seriously, MJ, I would like to understand the "recovery" process so I can explain it to my cult readers. Your help is greatly appreciated. Regards, Unimaginative Username (talk) 07:31, 18 June 2008 (UTC)

As far as I know there is no way to go back and look at old email addresses a user might have registered in the past. (Admins as well as ordinary users cannot even see a user's email address, we can only send email to it via Wikipedia's interface.) And we probably shouldn't, either -- it strikes me as a severe privacy issue. So, my recommendation, as I have stated from the beginning, is that you commit to who you are (plus a random hard-to-guess string, for security). Then if your account is compromised you reveal the exact string you committed to (your identity plus the hard to guess part), and then you can go about proving you are the person described in that commitment, for instance by having the other person email you at an email address included in the commitment, or call you at a phone number listed in the commitment. This avoids the catch-22 of having to rely on Wikipedia account information for anything after the account is corrupted. Mangojuice^talk 21:58, 21 June 2008 (UTC)

• Thanks. I knew users couldn't see the linked e-mail, which is good, but thought someone higher up in the hierarchy could. I guess for the really privacy-sensitive, one could set up an e-mail for this use only (maybeWP_ID_Hash@emailprovider.com?). IMHO, I'm not giving my phone # or address to any stranger on the Net, admin or not -- no offense, of course. Regards, Unimaginative Username (talk) 22:43, 21 June 2008 (UTC)

Revised using above feedback

The first version was simplified and shortened considerably, with substantial help from Anomie's suggestions. Everyone else is invited to review and provide additional feedback or suggestions. I hope this helps spread the adoption of the Committed Identity. Thank you all so much, Unimaginative Username (talk) 00:15, 19 June 2008 (UTC)

Much better, by the way! I like the personal tone without the bad jokes. I fixed a few minor typos for you, and in the process found an error in your instructions: you say to use {{User committed identity|aaaa|}}, but the pipe after the hash makes the template use "" instead of the default "SHA-512". I didn't fix that because I don't know how you would like to adjust your instructions, either to remove the extra pipe or just use "SHA-512" explicitly. Oh, and "YMMV" is an abbreviation for the idiom "your mileage may vary". Anomie⚔ 01:24, 19 June 2008 (UTC)

:-) I fixed the typo. That's another reason I asked for review -- it is a well-known principle of Human Factors Engineering that it is physically impossible for any single human to do anything exactly right; outside review is always required. The funny thing is, I test-drove ("drove" -- "mileage", get it?) all of my simplified templates in my own sandbox, copying them without the nowiki, to make sure that they parsed properly. Don't know how this one slipped by, or, as you said, just a clumsy finger on the keyboard. Whenever you have a spare moment, could you be kind enough to double-check that? Hate to ask, as you've done so much for it already, but clearly, you've a sharp eye. Thanks for helping this old dog to learn new tricks -- your mileage is outstanding. Unimaginative Username (talk) 04:41, 19 June 2008 (UTC)

Oops. Realized that fixing that single pipe error required editing a number of the other templates and instructions. No wonder you didn't want to touch it! :-) Don't know how they made it past the test-drive. I think it's correct now -- but what do I know? Thanks in advance to all who review and respond, Unimaginative Username (talk) 05:36, 19 June 2008 (UTC)

Revising documentation

I am making some changes to the documentation. In the example parameter for a SHA-1 hash, I replaced aaaa with ef7c4c55a176bd20ed558aaefde21c4803080195 (which is the hash of the following sentence: This is an example secret text string.) The reason is that for users who have not previously worked with hashes, it needs to be made obvious that their own hash is supposed to look pretty ugly, not something neat and short. Also I am going to eliminate the term "hash string" in the documentation and replace it with "hash". SteveMcCluskey pointed out above that it is less confusing to neophytes if the documentation uses "string" to refer to the item being hashed only. (Even though the resulting hash value is also a string.) Finally I notice that the documentation currently links to hashemall.com, which is a server-side hash calculator. Isn't that a potential security leak? Or is the risk considered negligible? I won't change that; it seems to have been discussed above so maybe someone thought it should stay there? --Mathew5000 (talk) 10:43, 25 August 2008 (UTC)

All of the discussion I see above includes several recommendations not to use a server-side hash calculator, so I suggest removing it. Anomie⚔ 11:20, 25 August 2008 (UTC)

I agree. --Mathew5000 (talk) 11:32, 25 August 2008 (UTC)

I think the instructions at User:Unimaginative Username/Simple Committed ID Instructions are good; I would change, however, the part that says “the important thing is that your secret is easy for you to remember”. It is unrealistic to expect someone to come up with a secret string now and then remember it exactly when it is needed, which might be years away. The instructions should not say “You can write it down on a piece of paper” as if that is optional. Rather, users should be instructed to write down their secret string and store it somewhere safe and secure for the long term, because someone who cryptographically commits an account and then cannot provide the secret string is in a worse position than someone who did not commit at all. --Mathew5000 (talk) 11:33, 25 August 2008 (UTC)

Also, some expansion is needed to the instructions at the end about what to do if your account is hacked. The instructions currently say “contact an admin, perhaps from the e-mail account that is linked to your account, and tell of your account having been stolen”. But it doesn’t say how to find an admin that you can email. As far as I can tell, if a hacker steals your account from you, then you will have to create a new account before you can get back control of your original account. Is that correct? If so it should be mentioned in the instructions. And even then, I’m still not sure exactly what procedure you would follow to provide your secret string (corresponding to the hash published on the user page) and thus get back your original account. Do administrators even have the power to transfer control of an account, and if so, would a typical administrator be comfortable using that power, without first reading up on the security of hash functions? --Mathew5000 (talk) 12:05, 25 August 2008 (UTC)

And, emailing an admin doesn't help anyway because admins can't reset passwords. I don't think Bureaucrats can either. But presumably there's some users out there who can really do this; developers, maybe? Mangojuice^talk 14:34, 25 August 2008 (UTC)

• Mathew5000, thank you for your review and thoughtful comments. I don't actually know the exact procedure for regaining an account. I am not an admin. I would hope someone with that knowledge would provide it, here or where easily located if needed. I was trying only to give the neophyte some idea of the purpose of all this time and effort. With regard to secrets and passwords, that has been a subject of much controversy at levels of the cryptographic and human-factors communities far, far above me. One problem is that people who can't remember passwords tend to do things like put them on sticky notes in that most secret of all places, the bottom of the keyboard (like hiding your door key under the doormat). Yet, truly random passwords/encryption keys/secrets are very difficult to memorize if you are not Rain Man. One answer has been the passphrase, if not obvious, or if created using Diceware or similar methods. But you are right, it should be recorded *somewhere* very safe, as human memory fails us all at times, even on the easiest of things. I'll edit the piece accordingly. Thanks again, Unimaginative Username (talk) 04:26, 25 September 2008 (UTC)
• Done. When you have a moment, please review Para. 4 and see if you think it suffices. Also, please note that I have always recommended your own local hash tool versus online calculators. Thanks, Unimaginative Username (talk) 04:38, 25 September 2008 (UTC)

• It’s one thing to remember a passphrase that you use several times a month. Some people are capable of that, some aren’t. But here we are contemplating a passphrase that you won’t use regularly; you won’t ever use it until you need it, which might be years in the future. And at that time you will have to remember the passphrase exactly. I would argue that almost nobody is reliably capable of that. I like your recent change to paragraph 4, but if it were up to me I would go further and emphasize that if you can’t remember your passphrase after your account has been hacked you will be worse off than if you had never used the user-committed-identity template in the first place. I would also emphasize the need to remember it exactly (including punctuation, spacing, and capitalization) — if you mostly remember the passphrase then again you will be worse off than if you had never used the template in the first place. --Mathew5000 (talk) 17:23, 25 September 2008 (UTC)

Yes, you're right about frequency of usage. I thought that using the word "recorded", as in, "most important... that it be recorded (emphasis added)..." covered that, but if you have a suggestion for improved language, please do post it on my talk page. Thanks again, Unimaginative Username (talk) 02:04, 26 September 2008 (UTC)

Remaining problems with the user-commitment scheme

Consider this thought-experiment. Suppose my name is Herbert Bloggs, my Wikipedia username is HJBloggs, and following the suggestions in the documentation, I choose the following for my secret string: My name is Herbert Jason Bloggs and I can be contacted at: sexyboy@example.com. I compute the SHA-512 hash and post it on my userpage. Now jump ahead three years, when a hacker has broken into my account and changed the password. I remember that I used my name and email address as my secret string, but when I now compute the hash for "My name is Herbert J. Bloggs and I can be contacted at sexyboy@example.com", it comes out to something different. Well, maybe I used my telephone number as well, so I try that, but still can't match the hash. Well, there's a few different formats I could have used for the phone number; was it an unbroken string of ten digits, or did I use parentheses around the area code, or hyphens, or what? I could try all of those, and of course it still wouldn't hash to the right value because in fact I didn't use my phone number at all. But then I think, what if I put my name as "H.J. Bloggs" or "Herbert Bloggs" or something else, rather than "Herbert J. Bloggs"? Did I put a period at the end of the sentence or not? Did I say "and I can be contacted at sexyboy@example.com", or "my email address is sexyboy@example.com", or maybe I spelled it "e-mail". Well, even if I remember with certainty that my secret string was just an expression of my name and email address, there are still dozens of combinations of how specifically I could have expressed it; am I supposed to write myself a script to test them all? Well I have no idea how to write scripts so I have to test them all by hand. And I might still never get it, because it hasn't occurred to me that I originally included a colon before the email address.

And what if the hacker who now controls my account decides to delete my user page with {{db-userreq}}? Then, I have no way of checking my recollection of my secret string against what it is supposed to hash to. I have to figure out where to go to protest the deletion of that userpage, and even then it may be greeted with skepticism if I say, posting from an unregistered IP or from a new account I just made for this purpose, "I am really HJBloggs and someone stole my account, and I can't remember exactly what secret string I used, so please undelete the user page so I can see the hash value and then I will hopefully be able to provide the secret string."

But let's say that I manage to recollect my secret string exactly. Now, there's no specific instructions in the template documentation on where precisely I find a Wikipedia functionary to help me out. After looking around through the Wikipedia documentation, I come across Wikipedia:Requests for administrator attention, which still doesn't tell me specifically where to go for this issue. Meanwhile, the HJBloggs account is making all sorts of mischievous edits in my name (or if I am an Admin, then the hacker may be abusing the sysop functions in my name). It might take a couple of days to find the person with the power to return control of the account to me, but it is imperative that the account be blocked as soon as possible. The fastest way to get this done would probably be to post the following on Wikipedia:Administrators' noticeboard:

I am HJBloggs but a hacker has taken over my account. Please block that account immediately until I can get control of the account returned to me. The proof that I am the real HJBloggs is that my secret string is My name is Herbert Jason Bloggs and I can be contacted at: sexyboy@example.com and if you take the SHA-512 hash of that string, it will agree with the hash published at User:HJBloggs -- and in addition you could email me at that email address for additional confirmation.

If I make this posting from either a new account or an unregistered IP number, any administrator could reasonably use that information to issue a 24-hour block on the HJBloggs account, likely within minutes of my making the posting. But that requires me to tell everyone that my email address is sexyboy@example.com which might be embarrassing. And then, now that I've given up my secret string, the hacker knows it too, and the hacker can just say, "that is my secret string, I am the real HJBloggs but I lost control of my old email address, sexyboy@example.com when someone hacked it." So now, how can I ever get back access to the HJBloggs account? First of all, since I posted that message on WP:ANB from an unregistered IP number, how can I now prove that I was the one who posted it? And second, the real hacker who stole the HJBloggs account from me has a reasonable argument in favour of maintaining control of that account, because it is plausible that someone who hacked the email account could then have come up with the secret string (which constists essentially of a name and email address — as recommended in the template documentation).

I did not intend to be so verbose here, but I think the scenario I pose here is realistic, and exposes some problems with the recommended use of the template. Here are partial solutions that I would propose to deal with these problems:

• Instruct users to place the template on their Talk page, not their User page, because Talk pages are not subject to deletion under WP:CSD#U1.

• Instruct users to choose (at least) two different secret strings and include the hash values of both. The first is for requesting an "ex parte" temporary block of the account by an Admin as soon as it is hacked. The second secret string would be used in the process of persuading a Steward to return control of the account permanently to the rightful owner (this might take some time because the hacker currently in control of the account would be given reasonable notice and have a chance to make submissions).

• • The phrasing within the template should also provide the purpose explicitly (as in the French version). For example, one version could say "Please block User:[accountname]" for 48 hours if anyone presents a passphrase of which the SHA-256 hash is [hash value]", and the other version could say "In case of an allegation that the account User:[accountname] has been compromised, please give control of the account to the individual who presents a passphrase of which the SHA-512 hash is [hash value]".

• Remove the instruction to choose a secret string that is "easily remembered exactly by you" because that is unrealistic considering that the user may need to remember the string years in the future, without ever having thought about it in the meantime. Instead users should be instructed to write down the secret string and store it somewhere that will be secure and accessible over the long term.

Sorry again to be so verbose but I hope this is helpful. --Mathew5000 (talk) 02:54, 27 August 2008 (UTC)

The hash is not a panacea, you are correct. However, a couple of points. Unless the user page has been oversighted, any admin can see the deleted page. Also, talk pages may be subject to CSD#U1 as sub-pages if the parent is deleted. The admin can be approached by e-mail if the hash is too personal. This, by the way, is another reason to also use a public-key based system like PGP, where if you have already accepted that Key "X" is related to E-mail "Y" and User "Z", sending a signed e-mail from "X" will be sufficient to return control of "Z" to the sender. -- Avi (talk) 03:04, 27 August 2008 (UTC)

User Talk pages are not subject to CSD#U1 because a Talk page is not a subpage. Approaching an admin by email is problematic where time is of the essence i.e. you want the account blocked within minutes. --Mathew5000 (talk) 04:04, 27 August 2008 (UTC)

If you want an account back within minutes, you're screwed anyway. If someone is really using the account for vandalism and such, getting someone to block it probably is not going to be the problem. Anomie⚔ 10:35, 27 August 2008 (UTC)

If the account is being used for vandalism it can be blocked on that basis alone. The issue is where the hacker is using the account in nonvandalistic ways, for example taking positions on Talk pages or RfAs that you do not agree with. There are lots of ways to do mischief with someone else's account that are not obviously vandalism. And it's worse if the account has sysop powers. Also I never said you should be able to get the account back within minutes. My point is that you would want the account blocked within minutes of when you realize that someone else is using it. After the account is blocked, there presumably would be some process for getting it returned to you, and for that second stage it would be useful to have a second hash value. --Mathew5000 (talk) 12:07, 27 August 2008 (UTC)

The point in this?

Forgive me if I'm missing something... but what is there to stop a hacker getting rid of the hash on your profile, or even updating it to a new hash? Then it wouldn't matter what my secret phrase was, as it would come out wrong compared to the one the hacker has installed! Unless every person I decided to talk to saves my has in advance in case anything happened. —Preceding unsigned comment added by Ronius (talk • contribs) 22:41, 24 September 2008 (UTC)

I think maybe the admins could look at previous versions of the page, before the change, and see if your secret hashes to that. Keeping in mind that *all* previous versions and revisions to pages are stored here forever. Unimaginative Username (talk) 04:14, 25 September 2008 (UTC)

Can I, should I, use an Openid persona "Wikipedia User: X" to provide part of the secret string?

The Openid efforts encourage people to define multiple "personas" secured under one strong password or other authentication method.

I just registered a myopenid.com account (see Openid reference to JanRain and recent Press Release )

I created a persona "Wikipedia User: X" and I see that the persona has the URL

"https://www.myopenid.com/persona_chooser?chosen_persona_id=NNNNNNN&tid=XXXXXXXX"

It occurs to me that the above URL would be a good choice for part of the secret string.

If one assumes the security of Openid (and your usage of it) is sufficient, can't one even use the URL as the entire secret string? Using such a secret string is a clear message to the Admin that you claim to be the owner of that Openid persona, and you are suggesting using Openid authentication to verify and reclaim your true identity and your compromised Wikipedia account.

Apologies for the anon., I'm trying to be less insecure. If this method is secure, I will identify myself here later. 75.60.29.223 (talk) 06:08, 29 November 2008 (UTC)

Cryptographic hashs take plaintext (your string), an algorithm (publicly known), and turn it in to a one-way hash. Hashes are traditionally part of an integrity check (to ensure that one plaintext is identical to another plaintext), to use it for authentication as described here, there are two constraints: (1) The original plaintext must be kept secret until validation; (2) it can only ever be used once for authentication (as the authentication process will cause the plaintext to no longer be secret). Having someone else create your secret plaintext violates constraint #1 above. — xaosflux ^Talk 17:24, 30 November 2008 (UTC)

You could always use the URL as only part of your secret string. As long as you can convince someone to give you your account back, it doesn't matter how that is accomplished. Mangojuice^talk 05:26, 2 December 2008 (UTC)

Who needs this?

I happened on this interesting topic as a tyro, and don't know at what point in a Wiki career someone would need to worry about this issue, nor what the consequences might be, nor a guess at how much trouble is it worth to avoid those anticipated consequences. —Preceding unsigned comment added by 71.246.234.139 (talk) 02:13, 21 December 2008 (UTC)

See Wikipedia:Wikipedia Signpost/2007-05-14/Compromised accounts and Wikipedia:Wikipedia Signpost/2007-05-14/Committed identity for a description of the events leading to the creation of this template. The short version is that there was a rash of admin account hacks, and some users decided this would be a good way for a user that was the victim of this sort of thing to regain access to their account, instead of having to start over with a new account. Anomie⚔ 03:17, 21 December 2008 (UTC)

Also note that it's not difficult for someone to accidently compromise an account if, for example, if one leaves his/her account logged in on a public computer, or if (s)he has relatives or friends at home that go onto his/her computer when (s)he has his/her account logged in, but the user would likely be experience the same problem as (s)he would if his/her account had been deliberately hacked. Also, if someone gets a virus in his/her computer, hackers might make malicious edits just to screw with the editor, even if the main purpose wasn't just to hack a Wikipedia account, but rather to give an internet user a headache. However, there are other ways to get unlocked than to have one of these codes. PCHS-NJROTC ^(Messages) 18:11, 22 December 2008 (UTC)

Fix colors, please

Please change the foreground color, or don't change the background color. I have the light on dark preference set, which makes this close to unreadable.--Elvey (talk) 23:08, 12 May 2009 (UTC)

Please read the documentation; there already are variables that will allow you to set your own colors. -- Avi (talk) 00:06, 13 May 2009 (UTC)

What documentation are you talking about? this? The template contains this: "background:#E0E8FF;" however the text color is not set. Perhaps you don't understand what I'm saying. Are you familiar with the light on dark preference (inside http://en.wikipedia.org/wiki/Special:Preferences ? ) When I go to a random page that uses this template, it it close to unreadable. The way to fix that isn't via use of the "background" parameter, that's for sure. The template itself needs changing. Understand?--Elvey (talk) 07:05, 31 July 2009 (UTC)

comma needs fixing I think

"Once you've established your identity, and set up a new account..."- I don't think it's grammatically correct to have that comma there. It's in the COMPROMISED IDENTITY section. Siince I'm not an administrator, I cannot edit it. May someone please look into this? Thanks, Airplaneman (talk) 23:48, 1 June 2009 (UTC)

You're correct, and there are several more errors in the sentence. Proper version would be:

"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 else (possibly multiple someones, depending on how and to whom you told the secret string) knows the secret string."

But I'm not sure that proper English is a high priority among those to whom proper sytax coding is absolutely critical, since no one's responded to you in six months. I can't edit it, either. Unimaginative Username (talk) 07:55, 24 January 2010 (UTC)

Link to simpler version for user with much less knowledge

Hi!

I think it would help to put an link - somewhere in the lead section of the 'How' section - to the version for dummies that user 'Unimaginative Username' has created here (User:Unimaginative_Username/Simple_Committed_ID_Instructions). Something like - "Much longer but simpler version of instructions for User with less technical knowledge."

I am computer interested but I just didnt get these instructions. So I think a link would help. Those with some knowledge can speed-read or skip the obvious.

Regards, --Kmw2700 (talk) 15:51, 19 January 2010 (UTC)

Add Python example

There should be an example in order to calculate the sum in Python. It's easy:

import hashlib
hashlib.sha512('my-secret-string').hexdigest()

Thanks, Andewz111 (no 'r') (nudge me) 19:28, 2 April 2010 (UTC)

Disambiguate SHA hash functions

The SHA hash functions article was recently split into SHA-1 and SHA-2. Please change the "SHA-512" link to SHA-2 (or just avoid the pointless pipe in the first place, it makes splitting articles a PITA). -- intgr [talk] 20:59, 5 April 2010 (UTC)

 Done, you can use {{editrequest}} next time to draw attention to such small changes to protected pages. —TheDJ (talk • contribs) 13:50, 7 April 2010 (UTC)

Text overflow

Is there any way so that when a person is browsing someone's committed identity and their browser is small that the some of the string wont appear out of the box. I browse the internet in a browser that is smaller than usual and when I see a SHA-512 string, the overflow appears out of the box and makes me have to scroll horizontally to see the remainder of the string. Forenti^talk 07:51, 7 April 2010 (UTC)

I have added "word-wrap: break-word" to the CSS of the template. Browsers that support it will break the string if needed. —TheDJ (talk • contribs) 12:13, 7 April 2010 (UTC)

Thanks a lot, it's perfect now - it has always bothered me. Forenti^talk 12:56, 7 April 2010 (UTC)

Example domain name

The example should be joe.schmoe@example.com, not joe@schmoe.com, as per RFC2606. --Doradus (talk) 18:15, 27 April 2010 (UTC)

Recommend removing the md5sum suggestion

MD5 is completely insecure: "MD5 is a broken hash function" and "no one should be using MD5 anymore." . Alternate secret strings (collisions) can be generated programmatically, thus are not secure nor provable for identity purposes. Groxx (talk) 16:36, 4 May 2010 (UTC)

To be fair, MD5 is still secure for identity confirmation-purposes -- because the input is supposed to be a secret anyway (you need a preimage attack for that, but MD5 is only vulnerable to a collision attack. See hash function security summary). But you are right, we should stop promoting MD5 and SHA-1 for new users, because attacks only get better. -- intgr [talk] 16:41, 4 May 2010 (UTC)

Inconsistent Results for Example?

I tried using the example, "My name is Joe Schmoe, and I can be contacted at: joe@example.com" (without the quotation marks at beginning and end) using the SHA-512 algorithms both at http://dev.zer0day.com/PHP%20Hasher.php and http://dev.zer0day.com/PHP%20Hasher.php and using sha512sum, and instead of getting the result described in the page, 9f7ca074acf9a59efce75b871c8f256886d57482ed291de3f55b8ef172dcd8bedecddba476f71c34cee51d8f76aa295fc171d368b0600e91d2ce8316ab731417, I got b7a84efbbd843545666957384e874c894fdc17f48ced53abd231c2e4d08e45ad10287b1225432e3ed9794c12994ff1e82aecf66a2ded61ad4baf6d8b9c81dab8 instead. Is there something I'm doing wrong? If not, this should probably be fixed. CyanSnapdragon (talk) 18:34, 16 May 2010 (UTC)

I get the same results as you, and also using a different hash site, http://www.whatsmyip.org/hash_generator/ - it looks to me as if the template example is wrong -- Boing! said Zebedee 19:49, 16 May 2010 (UTC)

I was just about to post a message regarding this, yes, I am also getting the b7a84... hash. —Vartan Simonian ^{talk | contribs} 01:12, 19 May 2010 (UTC)

Same here, with two websites and HashCalc. I've altered the documentation appropriately. 75.154.77.43 (talk) —Preceding undated comment added 01:26, 20 May 2010 (UTC).

And I've discovered the problem: http://en.wikipedia.org/w/index.php?title=Template:User_committed_identity/doc&diff=358707985&oldid=358707790 75.154.77.43 (talk) —Preceding undated comment added 01:27, 20 May 2010 (UTC).

That will do it! Someone is unclear. Thanks for fixing, anon. ErikHaugen (talk) 03:40, 20 May 2010 (UTC)

I'm not sure this correction is correct.

[03:19 PM] 150Mb$ echo 'My name is Joe Schmoe, and I can be contacted at: joe@example.com'
My name is Joe Schmoe, and I can be contacted at: joe@example.com
[03:19 PM] 150Mb$ echo 'My name is Joe Schmoe, and I can be contacted at: joe@example.com' | sha512sum
22673dcd0fea42e1cf1b0b821e50065d1df9d5008be27e35745da2c4543839923fd1840fb262c3bfeb119dc68a41ea34898f4cb54d1fe97a968470c1cae0754b  -
[03:19 PM] 150Mb$ echo My name is Joe Schmoe, and I can be contacted at: joe@example.com | sha512sum
22673dcd0fea42e1cf1b0b821e50065d1df9d5008be27e35745da2c4543839923fd1840fb262c3bfeb119dc68a41ea34898f4cb54d1fe97a968470c1cae0754b  -
[03:19 PM] 150Mb$ echo My name is Joe Schmoe, and I can be contacted at: joe@example.com| sha512sum
22673dcd0fea42e1cf1b0b821e50065d1df9d5008be27e35745da2c4543839923fd1840fb262c3bfeb119dc68a41ea34898f4cb54d1fe97a968470c1cae0754b  -
[03:19 PM] 150Mb$ echo "My name is Joe Schmoe, and I can be contacted at: joe@example.com"| sha512sum
22673dcd0fea42e1cf1b0b821e50065d1df9d5008be27e35745da2c4543839923fd1840fb262c3bfeb119dc68a41ea34898f4cb54d1fe97a968470c1cae0754b  -
[03:19 PM] 150Mb$ echo "My name is Joe Schmoe, and I can be contacted at: joe@example.com"| sha512sum -b
22673dcd0fea42e1cf1b0b821e50065d1df9d5008be27e35745da2c4543839923fd1840fb262c3bfeb119dc68a41ea34898f4cb54d1fe97a968470c1cae0754b *-

--Gwern (contribs) 19:22 28 May 2010 (GMT)

It is correct, use "echo -n" -- intgr [talk] 20:07, 28 May 2010 (UTC)

Nay, use printf. It won't put any extra chars in that you don't explicity specify.

 printf "this is my secret string 0987654321" | sha512sum

Felipe1982 (talk) 15:41, 3 November 2010 (UTC)

Hmmmm.

What if somebody stole the hash, then contacted Wikipedia claiming to be the owner? —Preceding unsigned comment added by Yckepedia-111 (talk • contribs) 23:57, 18 September 2010 (UTC)

The goal is that the only person who knows what words will make the hash is you. Hashes only go one way. Vistro (talk) 00:17, 19 September 2010 (UTC)

Yep, that's right. My hash is "8e6ad9971299e6264a17e1ef8dd6a27511b094fe9aff2539dd029da7fa07033660b844abbcac39632b00bcaa27fbd04967c6921a0b9f496ffdecc39cb6ef68a1", and that's freely visible (as they have to be). However, nobody knows the plain text that I encrypted to make that hash, because I've kept it confidential, and there's no practical way to reverse the encryption and recover the text. If my account were to be compromised and I wished to recover it, I would send the original plain text to the appropriate Wikipeople. However, if you disclosed your original plain text to other people, they would indeed be able to gain control over your account as you suggest. -- Boing! said Zebedee (talk) 07:48, 19 September 2010 (UTC)

windows powershell code in template

i am trying to use this powershell code (below)given inthe template instructions to get a hash. this gives me an error at character 87. is there a correction or some other way i can get my hash, i have a secret phrase i will always rememeber exactly, and i would like to use it. TIA

[bitconverter]::tostring((new-object security.cryptography.sha512managed).computehash([text.encoding]::utf8.getbytes("Secret phrase here"))).replace("-", "")Sam90403 (talk) 17:06, 1 July 2011 (UTC)

Wording

I'd remove "real-life" from "...this user's real-life identity", since it could be easily misinterpreted as requiring that the string contain identifying personal information. Feezo (send a signal | watch the sky) 11:13, 2 July 2011 (UTC)

Get rid of this

These "committed identity" userboxes are pretty much useless. To verify the account, the user would have to tell me their secret string. Once they do that, I can use it to impersonate them.

What if someone lost their password, then an attacker impersonated me and the user gave their secret string to the attacker? What if the user sent their secret string to me insecurely, and the communication was compromised?

The risks of communicating the secret string are so severe that nobody would ever want to do it for routine identity verification. You would only ever do it if you had actually lost access to your account, and only then with reluctance.

If you got rid of this concept and used PGP key fingerprints or full public keys instead, all of these problems would go away. You could use it for routine account verification as well as securing private communications. It's not especially more difficult, I put up a tutorial for Windows users at User:Tim Starling/Gpg4win tutorial. -- Tim Starling (talk) 01:27, 5 July 2011 (UTC)

As noted in the documentation, the security is enhanced by including contact information in the string, such as a phone number, which could be used to reach the person trying to use the string to prove their identity. This makes it very difficult for the person being given the string to abuse it. Additionally, the documentation suggests changing the string in the event you have to use it anyway.

I'm not discounting the fact that PGP/GPG are more secure, but it's way more than most average editors will ever need. —Darkwind (talk) 06:00, 22 August 2011 (UTC)

archive failure

I just archived old topics/sections from the current talk page, and they're not here, but they're not displaying on the Archive 1 page, although they're in the edit field of that archive page. I've archived from other talk pages before and don't recall ever seeing this problem. I didn't see anything between the prior topics/sections in the archive and the new ones I added that might not belong. My second attempt was apparently rejected by a server, as would be normal if the new saved page is identical to the previous, as it should be, and the second attempt does not appear in my watchlist, but the display is still wrong. (In the meantime, the missing topics/sections can be seen through the talk page's history.) What should I do? Nick Levinson (talk) 21:23, 29 October 2011 (UTC)

Interesting. There were actually a lot more invisible sections than the ones you just archived. I think I have tracked the problem to where an editor originally wanted to disable a section by enclosing it in <noinclude><includeonly> and </includeonly></noinclude>. However, sometime later the closing tags appear to have been removed. I have tried to fix the situation by restoring these tags; please feel free to sanity check what I did. – Wdchk (talk) 16:46, 30 October 2011 (UTC)

Thank you. I guess that worked (I'm not doing a line-by-line comparison, so I hope it did). It might raise a question for Wikipedians generally about what to include in posts that might unintentionally prevent display, especially of posts that don't have that but are denied display, as a spillover effect. But I don't know enough about what to say. I'll likely post something shortly to Village Pump (Technical) referring to this instance, so someone can consider it. Nick Levinson (talk) 21:53, 30 October 2011 (UTC)

If you want to look closer at what happened, this is the original edit. (We're going back to 2007 here.) The editor explained why he/she did it, and it seems at the time it had the desired effect of only hiding that one section. The closing tags </includeonly></noinclude> must have been removed later, but I haven't trawled through the history to find where. Cheers, – Wdchk (talk) 00:07, 31 October 2011 (UTC)

apparent completeness of the example hash

In the section Getting the Hash, in the last paragraph, an example of a hash is given on a single line. It is useful, but long enough to require some of us to horizontally scroll. When I do, the hash goes all the way to the edge of the browser display. Because there's apparently no space or other end-of-hash indicium after it, it looks like there may be more to the hash on the right end. That makes it impossible for some of us to be sure (experts can view source code for a page but most people don't know how to do that and some public or shared terminals don't allow that). To solve this, one or two spaces after the hash should fix that, provided they stay on the same line with the hash and line-breaking is prevented there, and the way to make sure of that is to add a nonbreaking space or two. May I add    to the end of the hash? I'm asking because I don't want to cause a misleading display, in case anyone knows the security issues and thinks it might do that. Nick Levinson (talk) 19:41, 29 October 2011 (UTC) (Proposed edit to example edited by replier to same effect: 21:42, 30 October 2011 (UTC))

I see your point. Your proposed solution might well make things clearer, but then I got to thinking we could just allow the hash string to wrap within the table. I have added some code to make this happen; at least, it works in my browser. A counter-argument could be that the wrapping might itself confuse people. However, if you copy-paste the wrapped string (into a Unix terminal, for example) you should get one continuous string with no inserted end-of-line. Again, this works fine for me, but we can take another shot if my solution is flawed. – Wdchk (talk) 18:25, 30 October 2011 (UTC)

I'm not sure how to allow word wrap for a single punctuationless spaceless string without introducing a character or more, and that would confuse some users. We could say "without the ... characters", but that makes it more complicated. Editors using smaller screens (I assume one can edit from a cell phone) would need word wrap at several points, and artificially breaking the line at multiple points to accommodate almost all users makes it still more complicated for wide-screen users. Arguably, the people who would commit identities and understand the shortcomings are likely to be experts before they see Wikipedia's ID option, but assuming that is exclusionary of nonexperts who might need the ID protection more, having fewer other options. Most Wikipedia editors don't use Unix, or don't know that they are (like Macintosh users). Suggestions? Or should I try nonbreaking spaces after the end? Nick Levinson (talk) 21:42, 30 October 2011 (UTC)

In the documentation, are you still seeing an unwrapped line of text for the example hash? (If so, you could try clicking "purge" at the top right of the blue box.) I thought I had taken care of it; at least it works in my browsers (Firefox 3.6 and IE 7). Take a look at the style I applied here. The wrapping is performed by the property word-wrap:break-word. Doing it this way, the hash should behave as one contiguous string if you copy-paste it. There are no introduced spaces or end-of-lines. For me, this layout looks cleaner and avoids scrolling. I'm hoping you can see the same. – Wdchk (talk) 23:47, 30 October 2011 (UTC)

I'm not getting word wrap for the hash on either the doc page or the transcluding template page in Firefox 3.3.4 on Fedora 10 Linux and that's my only Internet-ready platform at home (my new laptop won't be ready for a while). But I'll accept your judgment, since I'm not usually involved in Wikipedia's technical issues and don't have the same level of expertise as you and others likely have. So if wrapping is the better choice then I'll leave it at that and if I need to be sure of seeing the whole without it then I can view the source. Thanks for your work on the issue. Nick Levinson (talk) 00:37, 31 October 2011 (UTC)

Conflicting advice

The template help seems to give conflicting advice. It says: "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; random bits:fFfwq0DuDmMXj8hYTM3NTKeDhk'" but then goes on to say: "It is important that this string be [..] easily remembered exactly by you" Possibly remove the "random bits"? SD5 21:56, 28 March 2012 (UTC)

Weaknesses

Is is really a good idea to list the weaknesses of hash on this page? It may aid hackers considerably. Interchangeable|talk to me 01:23, 30 December 2011 (UTC)

Obfuscating those details about the nature of hashing functions will not inconvenience the bad guys. On the contrary, instructing others helps people to avoid misusing them in a way that might give attackers an opportunity. ErikHaugen (talk | contribs) 05:08, 30 December 2011 (UTC)

"The enemy knows the system." —Claude Shannon, Kerckhoffs's principle. AllenZh (talk) 20:22, 12 May 2012 (UTC)

Change request

<div id="user-committed-identity" style="font-size:85%; display:show; background:{{{background|#E0E8FF}}}; border:1px solid {{{border|#E0E8FF}}}; margin: 0.2em 0; padding:0.1em 0.3em; word-wrap: break-word; {{{extra-style|}}}">[[Template:User committed identity|Committed identity]]: '''{{{1}}}''' is {{{article|a}}} {{#ifexist: {{{2}}}| [[{{{2}}}]]|{{{2|[[SHA-512]]}}}}} [[Commitment scheme|commitment]] to this user's real-life identity.
</div>

-->

<div id="user-committed-identity" style="font-size:85%; display:show; background:{{{background|#E0E8FF}}}; border:1px solid {{{border|#E0E8FF}}}; margin: 0.2em 0; padding:0.1em 0.3em; word-wrap: break-word; {{{extra-style|}}}">[[Template:User committed identity|Committed identity]]: '''{{{1}}}''' is {{nowrap|{{{article|a}}} {{#ifexist: {{{2}}}| [[{{{2}}}]]|{{{2|[[SHA-512]]}}}}}}} [[Commitment scheme|commitment]] to this user's real-life identity.
</div>

--Olli (talk) 07:29, 28 July 2012 (UTC)

Why don't you want this to wrap? ErikHaugen (talk | contribs) 17:31, 28 July 2012 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. Anomie⚔ 18:44, 31 July 2012 (UTC)

Changed URL

Please update teh jsSHA calculator to: http://caligatio.github.com/jsSHA/ Thank you, Stillwaterising (talk) 09:54, 29 September 2012 (UTC)

 Done: edit to the documentation page. – Wdchk (talk) 12:43, 29 September 2012 (UTC)

Just wondering: Has this ever worked?

Has this template ever served its intended purpose? That is, proving that a user's account was hijacked?--Atlantima (talk) 20:45, 1 March 2013 (UTC)

Broken link

In the syntax section, the numerical identity link doesn't actually go to any specific section of the intended page. It just goes to the top of the page. Numbermaniac - T- C 10:59, 30 March 2013 (UTC)

 Done: edit to the documentation page. No admin edit required. – Wdchk (talk) 02:28, 31 March 2013 (UTC)

If I knew that, I could have done it myself. Numbermaniac - T- C 02:34, 31 March 2013 (UTC)

Default article

Hello! Shouldn't the default value for the |article= parameter be "an" instead of "a"? As the default value for "hash function used" parameter is SHA-512, which is pronounced as es-aitch-ei, "an" is required as the pronounciation starts with a vowel. Thoughts? — Dsimic (talk | contribs) 23:33, 23 September 2014 (UTC)

I think many people pronunce it as "shaw". But it should probably be written in a way that doesn't require an article in front of a parameter. -- intgr [talk] 07:49, 24 September 2014 (UTC)

No support for Base64 output variant Suggestion

The current template supports only HEX and not Base64. Can anyone please fix it? --QEDK ♠ T ♥ C 05:55, 7 February 2015 (UTC)

Hello! Sorry, but why would you need base64 for outputs of hash algorithms, and what do you refer to with "HEX"? — Dsimic (talk | contribs) 08:15, 7 February 2015 (UTC)

Base64 and HEX are interchangeable. You can get outputs using either but it should support both, I mean why not? --QEDK ♠ T ♥ C 09:14, 5 April 2015 (UTC)

What do you refer to with "HEX"? — Dsimic (talk | contribs) 21:34, 5 April 2015 (UTC)

Presumably base-16. A more interesting question is why they think the template doesn't support base64, since it does absolutely nothing with the provided value besides output it. Maybe they don't know about either escaping '=' with {{=}} or using an explicit |1=? Anomie⚔ 19:37, 6 April 2015 (UTC)

Right, and there's pretty much no need to encode anything. — Dsimic (talk | contribs) 21:30, 6 April 2015 (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)

Hash error checking

I just tried removing the last character from my hash and the template gave no indication of a problem. Certain types of errors like that would be easy to make. I know nothing of template coding, but is it feasible for the template to check parameter 1 for these errors?

• Not contiguous characters; i.e., contains one or more imbedded blanks.
• Contains one or more non-hex characters.
• Number of characters is incorrect for the hash function specified; i.e., not 128 for SHA-512. ―Mandruss ☎ 18:07, 13 August 2015 (UTC)

Unable to get the hash on Windows 7

Following the instructions at "Getting the hash", I am unable to make it work on Windows 7 x64.

To start with, to me the instructions seemed to suggest entering PS C:\Users\JoeShmoe> Get-FileHash secret.txt -Algorithm SHA512 | Format-List in the Run dialog or the command window. That failed with the error that the command PS did not exist. I'm not familiar with PowerShell, and I'm not a Windows expert, but I'm tech-savvy and I was able to find instructions on the web for starting PowerShell. After it was started, I was able to deduce that PS C:\Users\JoeShmoe> is the command prompt, not part of what I'm supposed to type. All this is a bit much to ask of most users, wouldn't you say?

But I still couldn't make it work; here's a screenshot. The WikipediaCommittedIdentity.txt file, containing my secret text, is in the current folder shown in the command prompt. I have redacted my Windows user name. ―Mandruss ☎ 11:56, 12 August 2015 (UTC)

Hello! Please have a look at this discussion and the official documentation for Get-FileHash. It seems that the Get-FileHash cmdlet (or however it's called) is available in PowerShell 4.0 or newer. — Dsimic (talk | contribs) 12:09, 12 August 2015 (UTC)

So it looks like, to use the method shown in the template doc, I would have to download and install Windows Management Framework 4.0 just to generate one hash. No thanks. A simple Google search gave me this web page, and, unless someone can say why I shouldn't, I'll use the hash that it generated for me. That method passes the test described at the end of "Getting the hash".

Surely no one would be seriously concerned about revealing their secret string to that web site? I think that would cross the line between caution and paranoia. Even if they were collecting this data, which I seriously doubt, it would be useless to them without my Wikipedia username. And they're welcome to have my email address and telephone number if they wish to send me spam or harass me with annoying telephone calls.

If that method is considered legitimate, the template doc is seriously in need of an update. Even if I already had PS 4.0+, that web page would be far easier to use. ―Mandruss ☎ 14:42, 12 August 2015 (UTC)

Well, you're free to do anything, but making the secret string unnecessarily available to someone else pretty much defeats the whole thing. If I were you, I'd generate the hash on Windows either by using the methods in the discussion linked above, or by installing Cygwin. — Dsimic (talk | contribs) 05:29, 13 August 2015 (UTC)

As I said, the secret string would be useless to them without my Wikipedia username. And whoever controls this doc is doing a disservice to the community by withholding that option from them. As it stands today, one needs a fairly high level of tech competence to use Committed Identity, and they can't just ask another editor to do it for them without telling them their secret string and their Wikipedia username. We should at least give people both choices and let them make the decision according to (1) their evaluation of risk, (2) their level of tech competence, and (3) their willingness to install additional software to generate this hash. The first time the system failed because someone used the web site, I would gladly change my position; until then, yours is a purely theoretical argument with little real-world basis. If the effort is part of the issue, just make it possible for me to do the changes and I'd be happy to do so. I had a long career in software development and I'm pretty good at writing good doc for the average user. ―Mandruss ☎ 16:12, 13 August 2015 (UTC)

Assuming that someone somehow did find out the name of the Wikipedia account registered to Mandruss and found out the string the hash represents, I would expect some sort of additional information in the string such as email address, name, address, phone number, or something that the person would not have control of, meaning the account would remain safe. Did you make sure to include links to other services, email, or something else that only you control? Dustin (talk) 16:23, 13 August 2015 (UTC)

My string consists of my home telephone number (a land line), my Yahoo email address (keeping my primary email private, even from an investigating admin), my son's email address (identified as such without using his name), and the recommended string of garbage characters. As you astutely pointed out, someone who had captured my string from that web site, had somehow linked it to the Wikipedia username "Mandruss", had hacked my Wikipedia password, and wanted to be Mandruss on Wikipedia (why??) would have to give a previously-agreed response during a phone call to my home number from a Wikipedia admin, which would be virtually impossible. Or, they could somehow take control of my email account. There's always the risk that they would invade my home and hold everyone at gunpoint whilst they satisfied the admin and changed my Wikipedia password, then leave, laughing disdainfully at my stupidity. And who would believe my story? ―Mandruss ☎ 16:38, 13 August 2015 (UTC)

On a happier note, that is extremely extremely unlikely. Dustin (talk) 18:58, 13 August 2015 (UTC)

Ya think? ―Mandruss ☎ 19:00, 13 August 2015 (UTC)

Yeah, that makes sense, it would be rather hard to defeat all those layers of protection. However, I'm somewhat surprised that even tech-savvy people have troubles generating simple hashes. For example, you could use your favorite programming language to quickly create a Windows program that does the hashing. — Dsimic (talk | contribs) 19:02, 13 August 2015 (UTC)

I'm not sure I understand your point. I'm attempting to address the current discrimination against the non-tech-savvy users who no doubt comprise a majority of Wikipedia editors, and have no less need to protect their accounts. In any case, even if we're talking about me, my "favorite programming language" doesn't run on Windows, or even on PCs. ―Mandruss ☎ 19:26, 13 August 2015 (UTC)

Out of curiosity, which programming language is your favorite? Back to the topic; why would that be discrimination? Everyone can use Google to find a website that generates hashes, if using locally installed software isn't possible or desired. — Dsimic (talk | contribs) 19:50, 13 August 2015 (UTC)

No, you're still a tech-savvy user thinking from a tech-savvy perspective. Many, many users will not have a clue what a hash is, or what SHA-512 is, so how would they make the mental leap from the template doc to the possibility of web alternatives? They're just blindly following instructions with no understanding of what they're doing. And I'm saying that understanding should not be required to use CI successfuly. Therefore the doc discriminates against them. IBM High Level Assembler. ―Mandruss ☎ 19:59, 13 August 2015 (UTC)

Hm, maybe I'm wrong, but at least some competence is required. Also, everybody should be able to grasp the concept of hashes from our articles. Oh, and here's the http://www.z390.org/, btw. :) — Dsimic (talk | contribs) 20:09, 13 August 2015 (UTC)

Yeah, you're wrong. The only competence that should be required is that of Average Internet User. So, does anyone else watch this page, or is this going to end up a stalemate between you and me, with you holding the keys to the doc (WP:OWN)? ―Mandruss ☎ 20:16, 13 August 2015 (UTC)

The competence level of an average Internet user? Meh, no, IMHO, but let's hear opinions from other editors. Moreover, have you tried the instructions from the discussion I've linked above, which should allow hash generation on Power Shell versions lower than 4.0? — Dsimic (talk | contribs) 20:22, 13 August 2015 (UTC)

Ok, other opinions is good and I always defer to consensus, even when it's wrong. No, I haven't tried that. Why should I, when the web method provides adequate security in my opinion, and is far easier without question? I already have the hash that I want, it took me all of about a minute to get it, and this thread stopped being about me a long time ago. ―Mandruss ☎ 20:27, 13 August 2015 (UTC)

@Dsimic: I figured out how to edit the template's doc, and I feel you haven't made the case against the changes I've suggested. If no opposing consensus develops within the next week or so, I plan to boldly make the change that I have sandboxed here. If you then choose to revert with no support, we can proceed to some kind of dispute resolution. If someone else reverts, perhaps they will join this discussion. I welcome any suggestions for improvement of the change. ―Mandruss ☎ 05:53, 18 August 2015 (UTC)

It's well written, explains the associated security risks, and should be helpful to the editors. So, I support the wording in your sandbox version, although I'd suggest that the "is extremely low" part is reworded, perhaps "is rather low" should fit better. — Dsimic (talk | contribs) 06:22, 18 August 2015 (UTC)

Done, thanks. ―Mandruss ☎ 06:42, 18 August 2015 (UTC)

Just had a though about why wouldn't it be possible for those websites to use a search engine to establish a link between submitted data and the Wikipedia username, by searching for the hash string (or its parts), but the search engines don't seem to include meaningless terms in their databases. — Dsimic (talk | contribs) 08:14, 18 August 2015 (UTC)

@Dsimic: You must have done something wrong. For me, Google finds the hash on your user page as well as those of Gaijin42 and Cwobeel (two other editors who I just happen to know use CI). It doesn't currently find mine because I NOINDEX my user page; while there are mirrors that ignore NOINDEX, none of them have picked up my page since I added CI to it. So you have a point, the security risk isn't quite as low as I stated, and I have modified the language accordingly (without explaining to the bad guys how to do this). ―Mandruss ☎ 16:53, 18 August 2015 (UTC)

Hm, that's quite intriguing as I now do get the exact match on Google when searching for my committed identity hash. I did the same search a few hours ago and got back zero matches (also tried using Bing, DuckDuckGo and Yahoo, to no avail). There's hardly anything to do wrong there, it's a simple copy and paste. :) I'd also suggest that your sandbox version contains a note about revealing personal information to the website, such as phone numbers or home addresses – that's obvious, of course, but providing a refresher never hurts. — Dsimic (talk | contribs) 21:57, 18 August 2015 (UTC)

Done. ―Mandruss ☎ 22:14, 18 August 2015 (UTC)

Updated doc as described. ―Mandruss ☎ 01:08, 29 August 2015 (UTC)

The changes you've made to the template documentation look good to me, just tweaked them a bit for a slightly cleaner layout and small adjustments in wording. Hope you're Ok with those changes. :) — Dsimic (talk | contribs) 22:07, 29 August 2015 (UTC)

Obsolete algorithms

SHA-512 is the most secure algorithm and it is now readily available to all users (provided on multiple websites, in-house version coming per preceding talk section). Is there any reason to mention anything else in the doc? Is there the possibility of a situation where a user who wants to use a local method would be forced to use one of the older algorithms? The doc currently refers to at least four other algorithms in various places, and it could be simplified by removing those and assuming SHA-512. I can do the first cut at the changes if consensus is reached. ―Mandruss ☎ 10:40, 19 December 2015 (UTC)

Hm, it might be debatable whether less secure hash algorithms should be kept around. For example, even MD5, which is much less secure, is still used rather frequently for verifying the integrity of downloaded files. IMHO, it's all about providing multiple options and letting everyone use whichever seems to fit. — Dsimic (talk | contribs) 03:12, 27 December 2015 (UTC)

wmflabs committed identity generator

Hi all, I've quickly put together this on the wmflab toolserver, which asks for a secret phrase, your email address and a contact number then SHA-512s it, giving you what you entered and the hash to add to the template. Is this worth adding to the template docs? -- samtar ^whisper 22:38, 16 December 2015 (UTC)

Interesting question.
The doc already discusses easy-to-use web-based hash generators, and it provides a link to one of them. This was discussed at length at #Unable to get the hash on Windows 7, above. The question, then, is: Is this better or worse than what we already have access to? Which is more trustworthy in the long term, a tool within the WMF/Wikipedia sphere, or one outside it? I'd lean toward the latter, since those tools have no idea of the purpose of the hash you're generating. Lots of people use those tools for lots of reasons. Also, they don't know your Wikipedia username, but I suspect code running under your login could get the username if it wanted to.
I'm interested in other comments. ―Mandruss ☎ 04:54, 17 December 2015 (UTC)

Dsimic? ―Mandruss ☎ 05:01, 17 December 2015 (UTC)

I agree Mandruss, trust is a key part of any site such as these - I have no quarms giving tool access to a number of trusted devs here to review the code and lack of logging, plus I'll be popping it up on github soon for the world to see. Although I joked about it initially, in reality I do have a slight aversion to free web-based crypto services where it's unclear what they log - seeing that paid hash lookup services are a thing.. </tinfoil hat> -- samtar ^whisper 07:40, 17 December 2015 (UTC)

It's not just the current trustworthiness that we would have to consider, but also the long term. Again, it seems to me such a tool could potentially get the username, which the other web-based tools cannot do. We obviously can't prevent someone from using it if it exists, but to mention it in this doc is to imply community endorsement of its security.
We lay out the security considerations as to the web-based tools and let the reader decide; are you prepared to do the same for this tool? Are you willing to state that the tool is potentially less safe than other web-based tools, for the two reasons I've mentioned? I don't think we should include it without that caveat; with the caveat, who would use it when the other web-based tools are just as easy to use?
You won't be around forever, and I don't see how we could guarantee that there will always be someone closely monitoring any changes to the code. Things tend to fade from the community consciousness. ―Mandruss ☎ 08:13, 17 December 2015 (UTC)

I'll try to address these concerns one by one, but in essence I'm not fighting for this to be the sole way of doing this online (far from it!) - I would only like users to know it exists and use it if they feel like it. To business:

• Concern regarding Wikipedia username: The tool cannot gain your Wikipedia username any easier than any other web application. wmflabs here is being used as webspace to host two PHP files, which anyone can access regardless of if they have an account on Wikipedia or not.
• Concern regarding long-term code maintenance: Currently, only I can make changes to the code, so if I disappear tomorrow, the code will not change and the app continue working as expected. If I add further trusted developers, they could change the code, and their actions would need to be trusted. Yes these things fall into disrepair after a while, such as snottywong's tools.

Ultimately, no, I cannot guarantee anything other than this web application exists today - I'd invite Dsimic to weigh in, and should he have a labs account and be willing I'll add him to the tool -- samtar ^whisper 08:32, 17 December 2015 (UTC)

Hello, and sorry for my delayed response. I'd say that having an in-house web-based hashing service would be a good thing, as that's essentially in the spirit of the whole open-source movement, while keeping everything in-house. The source code would be publicly accessible, and only a limited number of trusted developers would be able to make changes to it. Thus, IMHO we should include it into the documentation, with an appropriate description that lists potential pitfalls; that way, everyone would be able to choose whichever option they find most suitable. — Dsimic (talk | contribs) 07:55, 18 December 2015 (UTC)

It appears I'm outnumbered. If it's adopted, I'd suggest that it accept a completely free-form secret string, rather than imposing the structure that it does now. Failing that, (1) the labeling of fields becomes problematic, as the field the tool currently calls "Secret Phrase" is only part of the secret phrase, and (2) it should display the assembled string as input to the algorithm, since that's what the user will need to save somewhere. Also the "Submit Query" button might say "Calculate hash" instead. Nothing is being queried. I also question the value of masking the secret phrase string; hopefully the user will have sufficient sense not to generate their hash while someone is watching them. They need to see what they're typing to check for typing errors. ―Mandruss ☎ 08:06, 18 December 2015 (UTC)

I wouldn't call this voting, it's much more about reaching a consensus. However, I do agree with your remarks about the web interface layout and labels. — Dsimic (talk | contribs) 08:16, 18 December 2015 (UTC)

Since this would be a special-purpose hash generator, it could generate the entire {{User committed identity}} template, thus saving some work and reducing the likelihood of a syntax error. ―Mandruss ☎ 08:25, 18 December 2015 (UTC)

That's a great idea! Totally agreed. — Dsimic (talk | contribs) 08:27, 18 December 2015 (UTC)

To work then! Do either/both of you have tool accounts? -- samtar ^whisper 08:31, 18 December 2015 (UTC)

Apparently not I, since I haven't a clue what that is. ;) ―Mandruss ☎ 08:35, 18 December 2015 (UTC)

@Mandruss: wikitech.wikimedia.org if you're at all interested :) -- samtar ^whisper 08:41, 18 December 2015 (UTC)

Yeah, thanks. I'm old and tired (burned out?) and haven't yet found the energy to learn new programming skills. I'll leave that to you guys for now. ―Mandruss ☎ 08:46, 18 December 2015 (UTC)

I don't have an account, but if I open one I'll surely get sucked into the whole thing, and I simply don't have the time for that. :) Any chances, please, for reviewing the PHP code through GitHub or in another way? — Dsimic (talk | contribs) 09:26, 18 December 2015 (UTC)

@Dsimic: Sorry for the delay, please see this repo Merry Christmas! -- samtar ^whisper 11:08, 26 December 2015 (UTC)

No worries about the delay. Just had a look at the PHP and HTML code, and it's all very simple with nothing wrong in it. In other words, it's perfectly good to go. Merry Christmas to you too, and happy new year! — Dsimic (talk | contribs) 03:06, 27 December 2015 (UTC)

@Samtar: Haven't heard from you since 2015! How's it coming? ―Mandruss ☎ 05:26, 1 February 2016 (UTC)

Memory loss

Pacerier (talk) 05:35, 9 March 2016 (UTC): ❝

And what happens when the user has a loss of memory, either by (head) injuries or illnesses / shocks?

To clarify; note that saving the text or image is not enough, because one is unable to recall where the text is stored.

References

❞

Move proposal

Hello! Shall we rename/move this template to Template:User-committed identity? That would be grammatically correct because "user-commited" is a compound adjective, and should be much less confusing to the people that see this template for the first time. Seeing it for the very first time without a hyphen was rather confusing to me. — Dsimic (talk | contribs) 20:21, 16 April 2016 (UTC)

@Dsimic: Sorry I'm late! I got stuck in traffic!
My first reaction was I have no problem with that, and the hyphen is technically correct.
My second reaction was: Look at the template's output. It says "Committed identity". Apparently someone felt those two words were enough to unambiguously describe this thing. How about Template:Committed identity? ―Mandruss ☎ 20:09, 5 May 2016 (UTC)

I now see that would be a move over redirect. That redirect was created in Sep 2007 by someone who apparently felt those two words were enough to unambiguously describe this thing. The template has never had that title. ―Mandruss ☎ 20:11, 5 May 2016 (UTC)

No worries about the delay, there's no hurry. Ending up with {{Committed identity}} sounds like a reasonable choice to me, it's a shorter name while it would remain unambiguous because we'd hardly have someone else commit one's identity than the user themselves. :) — Dsimic (talk | contribs) 23:11, 7 May 2016 (UTC)

Ok. If no objection by the end of this month, I'll submit a request for uncontroversial technical move. And I guess the same for its doc page, and any other subpages. ―Mandruss ☎ 16:56, 8 May 2016 (UTC)

Sounds like a plan, thanks. Surely, we'd need to rename all associated pages as well. — Dsimic (talk | contribs) 19:15, 11 May 2016 (UTC)

@Dsimic:  Done ―Mandruss ☎ 04:49, 2 June 2016 (UTC)

Awesome, thank you! — Dsimic (talk | contribs) 00:22, 3 June 2016 (UTC)

Link to unencryted SHA hash service?

Is the link to an online-ad supported SHA hash service (after instructing users to put a lot of personal info into their hash) really appropriate here, after Wikimedia has gone so far as to move to SSL-only? I get that a lot of users are on Windows and don't want to install a utility to do this, but at least we should find an HTTPS site. Also, if there is a way to do this with PowerShell, we should include that and then fewer users would feel the need to use a web service. BlAcKhAt9(9 (talk) 01:17, 20 November 2016 (UTC)

Possibly we could host our own javascript implementation of a SHA calculator? A special page with a use javascript link to execute perhaps? — xaosflux ^Talk 03:21, 20 November 2016 (UTC)

@Xaosflux: See Template talk:Committed identity#wmflabs committed identity generator. The job was half done, then the person doing it appeared to lose interest without explanation. ―Mandruss ☎ 18:34, 1 February 2017 (UTC)

Does 2FA make committed identity useless?

If a user has enabled two-factor authentication on their account, is there any reason for them to publish a committed identity hash? The instructions for 2FA says that the supplied list of one-time-use scratch tokens are "the only way to rescue your account" if you lose your 2FA device. If I were to enable 2FA, then lose my phone and lose my saved list of one-time-use scratch tokens, but I had set up a committed identity hash, would proving that I knew my committed identity info be of any help to me in recovering my account? — Richwales (no relation to Jimbo) 07:51, 1 February 2017 (UTC)

Your committed identity is to a degree very similar to your 2FA recovery codes. It's value has significantly diminished, but it won't hurt having both. 2FA requires you to know both the password and the 2FA code, but for committed identity, just the passphrase of your committed identity will be enough (but as a procedure, committed identity is much more involved). —TheDJ (talk • contribs) 12:47, 1 February 2017 (UTC)

I for one have no device supported by 2FA. I'm getting old and probably never will. Suggest waiting until every human has a smartphone surgically implanted at birth. ―Mandruss ☎ 18:37, 1 February 2017 (UTC)

Thanks. So, if I were to lose my phone and my 2FA scratch tokens, I could (in theory) still have some hope of convincing a wizard to get me back into my account based on my committed identity info? I wasn't sure if, perhaps, the 2FA mechanism might make it technically impossible for anyone to do this, no matter how personally satisfied they were of my identity. — Richwales (no relation to Jimbo) 20:33, 1 February 2017 (UTC)

@Richwales: Oh. I have no clue on that. Perhaps better raised at 2FA? ―Mandruss ☎ 20:35, 1 February 2017 (UTC)

Technically no, and you may possibly be able to use a committed identity to convince a developer to remove 2FA from your account. — xaosflux ^Talk 01:39, 2 February 2017 (UTC)

'code' tag

Can someone with rights to do it, please add a <code> tag around {{{1}}}?

Wondering why this hasn't been done initially. — Superuser27  ^{contributions - talk} 05:45, 15 August 2017 (UTC)

Or even better - <font style="font-family:monospace;">{{{1}}}</font> — Superuser27  ^{contributions - talk} 06:13, 15 August 2017 (UTC)

Box overflowed (overflown?) by hash value

At Template:Committed identity/doc#Example, the example hash value overflows the box (and my Firefox window, requiring horizontal scrolling). At one time that was addressed by a <div>...</div>, as seen here. That may not be the best possible solution, but I don't think the status quo is the best we can do, either. ―Mandruss ☎ 05:26, 4 February 2018 (UTC)

@Mandruss: how is it now? I was able to get it to look bad with a low resolution, it's a bit different now. Only other option would be to force some line wrapping in the output. — xaosflux ^Talk 05:31, 4 February 2018 (UTC)

@Xaosflux: Actually it's better seen on the template page at Template:Committed identity#Example. I see no difference, even after purge. ―Mandruss ☎ 05:33, 4 February 2018 (UTC)

@Mandruss: how narrow is your screen? (How many characters do you get per line?) — xaosflux ^Talk 05:38, 4 February 2018 (UTC)

I have no way of counting characters per line. I am maximized on a 1366x768 display. ―Mandruss ☎ 05:40, 4 February 2018 (UTC)

I have 110 characters of the hash inside the gray box, 18 outside. 115 of 128 visible without scrolling right. ―Mandruss ☎ 05:47, 4 February 2018 (UTC)

@Xaosflux: If you don't see the same problem, have you tried a smaller window size? ―Mandruss ☎ 05:57, 4 February 2018 (UTC)

@Mandruss: at 1920*1080 it is fine for me. Obviously resolutions change for people - what do you want to happen here? (e.g. a L/R scroll window, text wrapping, etc?) — xaosflux ^Talk 16:31, 4 February 2018 (UTC)

@Xaosflux: Have you tried reducing your window width? I think you would then see the problem.
I would prefer something like this, perhaps with a modification to change the font to Courier New (or whatever is used for <code>...</code>). I don't think it's a good idea to force a line break in the middle of what is meant to be a continuous string (<br />); things should wrap naturally according to individual display characteristics. ―Mandruss ☎ 20:40, 4 February 2018 (UTC)

@Mandruss: I don't see any problems with that, go for it. — xaosflux ^Talk 21:06, 4 February 2018 (UTC)

 Done - [1] ―Mandruss ☎ 21:24, 4 February 2018 (UTC)

Please warn about using any random online tool.

When even a Wikipedia administrator recommends using a third-party PHP tool to generate such a hash string, it's time to add a warning to the template. I do not think that anyone wants their cleartext to be potentially stored in a huge database that is later used for offering "online decryption" tools. ~ ToBeFree (talk) 16:48, 24 March 2018 (UTC)

Such caveats were part of a large removal 9 months ago that was uncontested (you may find the reading easier in the prior revision). Until relatively recently, those web tools were the only alternative to methods using software on one's computer—methods that varied between platforms, required some tech savvy, and possibly required installation of new software—and the web tools didn't look so bad under those circumstances.
Me, I'd just ask that admin to stop recommending that and point them to the updated doc and the wmflabs tool. ―Mandruss ☎ 17:06, 24 March 2018 (UTC)

Oh! I didn't expect that to have happened. Thank you very much for the link. Hmm. Of course I expressed my concerns on the talk page - that's not the main problem. I didn't mean this to be about a specific user. My surprise was that, if even administrators do this, there will probably be a larger number of users doing so without even having any idea about any potential problems with this approach. "I need a SHA-512 hash? Oh, let's just google how to do this. Oh, there is an online tool. This was easy." Having a link to a good, trustworthy tool might already be a very effective measure against this specific chain of thoughts.

For reference, here is the original text, which also explains why my concerns are not as severe as I expected:

Web-based methods require you to enter your secret string on a web page that could potentially be collecting that information. However, if your secret string includes information about things that you control, as recommended, someone who knew your secret string and your Wikipedia username would still be unable to take control of your Wikipedia account. Thus, the security risk associated with web-based methods is rather low. Also consider that any personal details in your secret string could be revealed to operators of the website. If these factors are unacceptable to you, use a local method.

(emphasis mine)

Well, I have an edit suggestion anyway. One that will probably not hurt, but might be nice to have. :) ~ ToBeFree (talk) 17:49, 24 March 2018 (UTC)

I have no objection to this edit, and thanks for helping demonstrate the problem with the enlarged edit summary field. ―Mandruss ☎ 17:54, 24 March 2018 (UTC)

(edit conflict :) ) https://en.wikipedia.org/w/index.php?title=Template:Committed_identity/doc&diff=832234234&oldid=824034201&diffmode=source (Heh, that limit was not always 1000 characters, was it? ) ~ ToBeFree (talk) 17:57, 24 March 2018 (UTC)

Oh, and for clarification: Today I learned that the template and the template documentation are two separate things that can have different levels of edit protection. I created the talk page entry because the template was locked. It was a good idea to do so, because I didn't expect that my concerns had already been addressed in a very old version of the page. Thanks again @Mandruss:! ~ ToBeFree (talk) 17:57, 24 March 2018 (UTC)

Haha, we had the same thought about the edit summary field. ~ ToBeFree (talk) 17:57, 24 March 2018 (UTC)

Complete nonsense

This template, frankly, is complete nonsense. The claim is "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 not true at all. All that can be proved is that the one who calculated the hash knew the secret string. It is not provable that this person is identical to you, or to the person specified in the contact information (which can be chosen freely), or to the person placing the template, or that any of those persons are identical to any other. Neither does it prove that the secret string was actually secret at any point in time and that nobody except the person calculating the hash knew it.

Users of this template weaken their account security. Before using the template, the only risk was the password being compromised. After using the template, in addition, you have the additional risk of the secret string being compromised.

Further, the template causes systemic risk. It introduces risks for anyone who is not using it. Given someone forgets to logout. The password is not stored in memory anymore, but the authenticated session is still open. Then an attacker can place the template and claim it to be his account.

Please get rid of this template. --rtc (talk) 08:02, 17 April 2018 (UTC)

That's just bull^$%@. No security is ever 100% to begin with, so your whole premise is flawed. This is a calculated risk/benefit scenario that has proven itself to work well enough to accomplish its intended goal (allowing account recovery in scenarios where that otherwise might not be possible). While the lingo might indeed be more accurate, this thing is intended for a non-auditer audience. Further, the whole system is embedded in social conventions, which further helps to strengthen the security. It's not a token that you enter and get access. It's a token that MIGHT give you access, if enough people believe the token to be valid and there are no suspicious circumstances. —TheDJ (talk • contribs) 09:36, 17 April 2018 (UTC)

Bullshit? I beg to differ. There's no premise about 100% security in my argument at all. I merely argued that this is one of those cases where promises are made that are not fulfilled, using cryptography to make snake-oil-like claims of benefits, while actually introducing additional risks -- not merely for users using the template, but for everyone. "It's not a token that you enter and get access." That's right, sorry if I misrepresented that. The secret protects the user's identity, not control of the account. leaking the secret, the user's identity is disclosed. That clearly is an additional risk. And the account can be compromised for those not using the template, as described. This is a completely realistic attack scenario, given that the template description itself mentions "remembering to log yourself out when using a computer to which others may have access" And BTW, the example is nonsense, too. It uses a secret string that contains about 144 bits of entropy. As the weakest link in the chain, this severely decreases the overall security, far below what the SHA512 hash itself provides. Further, SHA is known to be prone to length extension attacks. The possible implications seem not to have been considered at all. --rtc (talk) 10:49, 17 April 2018 (UTC)

If set up correctly, it's not just that an attacker has to know the hashed string, they also have to be able to impersonate the editor based on information contained in that string (for example, they would also have to take control of your email address and phone number, if you include those in the string). An administrator evaluating a request to reset a password based on a confirmed identity would likely not accept the request if the hash was recently placed or modified. --Ahecht (TALK
PAGE) 16:33, 10 May 2018 (UTC)

User:Fastily, evil genius

[2] How do we know this isn't all one giant plot by Fastily to take over the world? EEng 16:59, 4 June 2018 (UTC)

We don't, and that was kind of the gist of something I said in late 2015—before Fastily entered the picture. No traction, obviously. ―Mandruss ☎ 17:07, 4 June 2018 (UTC)

Personally I do these kinds of calculations by hand, to avoid all doubt. EEng 17:11, 4 June 2018 (UTC)

All doubt? Your fingers might be hacked by the Russians. ―Mandruss ☎ 17:12, 4 June 2018 (UTC)

That would be a digital hack, I guess. EEng 17:16, 4 June 2018 (UTC)

Oh no, you've discovered my plan! But you're all much too late. All your hashes are belong to us 😉 -FASTILY 22:25, 4 June 2018 (UTC)

Secret Key Example

So this is clearly intended to function as a salt. So while I love having the utility of an example secret key in case someone wants to generate one themselves, the temptation I think would be far too great to just use the given one, and that completely defeats the purpose of a salt to begin with.

Despite having a very old account, I am actually quite unaware of the utilities available to Wikipedia editors, so please forgive me if this is an obvious impossibility, but would it be feasible to generate this key every pageload or at worst every few hours using a bot? (This has the quite obvious drawback of making the history completely illegible, but would it be possible in that case to simply make the key portion a separate template?)

OmnipotentEntity (talk) 14:51, 1 July 2018 (UTC)

Word wrapping issues with floating objects

I think we should add overflow: auto to the CSS style of the main <div> object. This should prevent the problem on Wikipedia:Village pump (technical)#Committed identity template displaying oddly in some browsers, as the template will right now extend behind a floated userbox table, which leads to word-wrapping issues. Does anyone see any potential problems with this? Daß Wölf 23:49, 18 August 2018 (UTC)

Done. And moved to template styles at the same time. —TheDJ (talk • contribs) 09:33, 19 August 2018 (UTC)

Quotes

Just a little nitpick, but if the passphrase is not supposed to be a quote that someone might easily recognise or come up with, then correct horse battery staple is not an example of a good passphrase... --IByte (talk) 13:04, 6 October 2018 (UTC)

Well, when you put it that way, any phrase we mention immediately becomes not a good example. It's a bit of a paradox. EEng 19:00, 6 October 2018 (UTC)

Just use Swordfish.[3] Nobody will ever guess that one. --Guy Macon (talk) 19:52, 6 October 2018 (UTC)

Issue if using Fastily's browser tool

I'm a new user, and this is my first time doing anything like this, but I believe I have discovered a possible problem with Committed Identity hashes generated with Fastily's browser tool. The algorithm labelled "sha3-512 (strong)" on the website is actually using Keccak-512. Say a user wants to verify their identity and they used this website, any administrator who doesn't use the exact same tool but uses sha3-512 will get a different hash. Because of this, Wikipedia users might not be able to verify their identity.

@Fastily: I opened an issue on your GitHub repository. I am not sure how to address this for all the Wikipedia Users this may impact.

MFScalzo (talk) 04:44, 16 June 2020 (UTC)

Formatting change

I propose to change the bolded part of the template from the numbers to "committed identity" at the start. It's more important to specify what the template actually is than to highlight the string of numbers. {{u|Sdkb}} ^talk 22:32, 23 August 2020 (UTC)

So bold the link back to the template it's self over the ID number? Side note your signature is a blank.--Moxy 🍁 22:45, 23 August 2020 (UTC)

Yes. And I'm not sure what's causing that for you; if you figure it out, feel free to put in a request to fix it wherever that would be needed. {{u|Sdkb}} ^talk 23:36, 23 August 2020 (UTC)

Let's try it out see if any object.--Moxy 🍁 02:59, 24 August 2020 (UTC)

Documentation of how to use this

• Template:Committed_identity/doc#Password_reset

Anyone feel free to edit or point to prior existing documentation of this. I could not find any. Blue Rasberry (talk) 14:34, 30 October 2020 (UTC)

spell check

...which as of 2020 recommends posing the request to Wikipedia:Administrators' noticeboard. On the ... Paptilian (talk) 23:20, 10 December 2020 (UTC)

Template-protected edit request on 11 December 2020

Please replace spelling error

"...recommends posing the request to..."

with

"...recommends posting the request to...".

Thanks to User:Paptilian for catching this error. --Guy Macon (talk) 03:33, 11 December 2020 (UTC) Guy Macon (talk) 03:33, 11 December 2020 (UTC)

This text is on the unprotected page Template:Committed identity/doc and can be edited by any editor. —⁠andrybak (talk) 11:14, 11 December 2020 (UTC)

Python3 Implementation & Unicode Issues

There should be an example in order to calculate the sum in Python3. This is the easiest and least error-prone method:

import hashlib
hashlib.sha512(b'my-secret-string').hexdigest()

Note on Unicode: The suggested method of using sha512sum is a Bad Idea since it doesn't behave as a user expects if your terminal works with unicode input. Simply doing echo -n "my-secret-string" | sha512sum does not work correctly on modern linux as you'd expect and will produce a result different than the suggested website.

This is an updated suggestion from long ago by Andewz111 in the archived talk page.

Teque5 (talk) 17:26, 29 March 2021 (UTC)

How to use

In the case one's account was compromised or the user has lost access to their email and password... via what method can they use the 'committed identity' to prove their identity and account ownership?

The login page has got a 'forgot password' page, but no other mechanisms? Aethalides (talk) 15:41, 18 May 2024 (UTC)

did you read Template:Committed identity/Archive 1 § Password reset? Jeremyb (talk) 03:49, 8 June 2024 (UTC)