Template talk:Committed identity

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)

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)

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)