Template talk:Committed identity

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? 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.

Not necessarily. Some of us don't leave our computers running 24/7; we also take them places with us. I'd be willing to bet, for instance, that lots of folks who are in the Navy take their computers with them. I'd also bet they can't have those computers connected to the net all the time while at sea or in a foreign port. Similar thing for people working overseas (contractors, military, commercial travellers, etc.)    ¥    Jacky Tar  21:28, 17 October 2007 (UTC)

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)

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)