Wikipedia talk:Security

From Wikipedia, the free encyclopedia

Contents

[edit] Background

Please see this discussion for background to this proposal. --Tony Sidaway 15:25, 7 May 2007 (UTC)

[edit] Specs on "strong" passwords

I believe, if we should tell users and especially admins they should have a "strong" password, it would only be logical to lay down the rules as to what consitutes a "strong" password. Different companies have different ideas of what actually is a "strong" password, so it's only normal that we should have our own set of rules.--Ramdrake 15:32, 7 May 2007 (UTC)

No, better to keep people guessing, really. Admins should use the strongest password they can live with. If we can crack it we can go looking for another admin. --Tony Sidaway 15:38, 7 May 2007 (UTC)
Wrong-o. Security through obscurity is almost never a good idea, and is in this case actively harmful. It does a script kiddie no good to know that my password is at least ten characters long and contains at least one each lowercase, uppercase, numeric, and punctuation characters. A putative User:Example who thinks his "xmpl69" password is strong because we don't provide any guidance at all does do that script kiddie a world of good. —Cryptic 15:48, 7 May 2007 (UTC)
I'm not suggesting security through obscurity. Rather the reverse. I'm proposing to keep the owners of the password guessing about what constitutes an acceptable password. This will save a lot of wikilawyering from people who think their weak password is strong because of a loophole in a form of words. --Tony Sidaway 16:14, 7 May 2007 (UTC)
Actually, the policy as written does specify what a weak password is, albeit obliquely: a weak password is one that can be cracked with much less effort than a strong password; the test is to try and crack it. Attempting to specify the exact required characteristics of a strong or weak password is a bad idea - statements like "all strong passwords contain at least one numeral" are wrong; worse, if we require admin passwords to contain numerals (say), that policy gives an attacker information they wouldn't otherwise have. Gavia immer (talk) 16:41, 7 May 2007 (UTC)
Precisely. A policy that says "all administrator passwords must have at least one numeral", a cracker will know that the lazier, stupider administrators will choose precisely one numeral and it will probably be digit "1" in the place of a letter "l", or a digit "0" in place of an "o", in anotherwise common word or phrase. --Tony Sidaway 16:48, 7 May 2007 (UTC)
The links to password strength are good enough for me. I wasn't trying to fix lazy password choices—if nothing else, they'll eventually stick it to their monitor with a postit—but to help the less technically-savvy. —Cryptic 16:55, 7 May 2007 (UTC)
However, if we are holding people up to a standard and may strip them of privileges if their password doesn't meet that standard (being a "strong password"), then we must either specify a standard (what is a "strong password"), without necessarily saying what it must contain, or remove the consequences. We just can't hold people up to an unspecified standard. It sounds just too arbitrary to me (if your password got cracked, that's because it wasn't strong enough and it's your fault). Given enough time or enough resources, all passwords can be cracked.--Ramdrake 18:24, 7 May 2007 (UTC)
Is there some standard accepted by IT professionals? --Iamunknown 18:33, 7 May 2007 (UTC)
There aren't, really. The idea of this policy is to not let people know what is an acceptable password, so they'll think carefully about setting a good one. This is particularly important with administrators, so the fact that they could lose their much-prized buttons will give them an incentive to come up with a real doozy of a password. --Tony Sidaway 21:49, 7 May 2007 (UTC)
And as such, I repeat, with all due respect, that I think that's a bad idea. You just can't ask people to meet a standard that you're very careful not to specify. By doing this, you're just asking them to read your mind. Just hoping that gets my point across. --Ramdrake 21:54, 7 May 2007 (UTC)
Or at least, can we just link there to give user a rough idea of what we mean by a strong password?--Ramdrake 22:09, 7 May 2007 (UTC)

The DoD Green Book [1] specifies that strong passwords should be machine-generated, not human-selected. Random three-word phrases selected from a word list (see diceware) work pretty well in my experience (they are easy to remember after a few uses, and are random enough to be safe from online guessing). The wiki software should probably be modified to generate passwords for admin accounts using the Diceware word list (or just select from the words < 7 chars from /usr/dict/words), with the selections made using /dev/urandom. To avoid forgetting the passphrase, Bruce Schneier suggests writing it down on a piece of paper and putting it in your wallet (a secure container that you already have a lifetime of experience in using).[2] 71.141.91.251 05:40, 9 May 2007 (UTC)

[edit] Does this need to be a separate policy?

As it stands, it appears that any sections on blocking/protection seem to be (and only ever will be) duplication of what is/should be in the Blocking Policy/Protection policy. The bit on passwords can stay on Wikipedia:Administrators. Petros471 15:46, 7 May 2007 (UTC)

Wikipedia:Administrators is basically a help document or FAQ about administrators. This is a proposed policy. The information about protection and blocking are background, setting the relevant policies in their place in the wider field of security. --Tony Sidaway 16:13, 7 May 2007 (UTC)

[edit] Passphrase

Suggest removing "reasonably" from the sentence "Please use a reasonably strong password"! There may also be a case for recommending people to use a passphrase (though I don't know if there's an upper limit on password length?). "The QuicK Br0wn F0x!" doesn't take much longer to type than "password4" but is much stronger... BastunBaStun not BaTsun 15:54, 7 May 2007 (UTC)

No upper limit that I've hit and I'm using something 40+ chars. —— Eagle 101 17:56, 7 May 2007 (UTC)
I wonder if the developers could be prevailed upon to permit spaces in passwords. --Tony Sidaway 21:47, 7 May 2007 (UTC)
Hyphens are perfectly good for separating words in passphrases. Really though, this "QuiCK Br0wn F0x" stuff is inadvisable. It's better to pick a few words at random from a dictionary. 71.141.91.251 05:46, 9 May 2007 (UTC)

[edit] Too many bad password tries

Suggest blocking accounts if there are too many failed log-in attempts (exact number need not be published). Also suggest a procedure for restoring locked accounts (based on some other set of information entered by the user at account creation) and for monitoring recently-restored accounts. Restoring an administrator account might require a more informative procedure to verify identity (more information to verify, or perhaps contacting another admin who can vouch that the user is legit). The stronger the password required, the higher the percentage of legitimate users who will (honestly) forget it. Best, --Shirahadasha 18:42, 7 May 2007 (UTC)

Good idea. If there is a genuine problem with admin accounts being hacked then we need to move away from the idea that all Wikipedia knows about an admin is their username, password, IP and edit history. Say 500 admins had very unsecure passwords (however you define that!) and were either all hacked or all desyssoped by someone in a fit of paranoia. That woudln't be very helpful for the project, if there were no way for those 500 people to re-verfy their identities... The Land 21:07, 7 May 2007 (UTC)
This makes a massive denial of service attack possible (someone launches a bot that gets all the admin accounts blocked through making failed login attempts...). Alex Bakharev suggested instead blocking only the IP address that made the failed attempts, though there are ways of gaming that. I think the devs should begin keeping overall statistics of failed and successful login attempts per day if they're not already doing this, so they can investigate if the numbers suddenly change.
Discussing detailed issues of approaches to restoring forgotten passwords gets well into WP:BEANS territory. But one thing we should discuss is whether there should be a more secure (but more cumbersome) procedure for admins than regular users. 71.141.91.251 08:42, 9 May 2007 (UTC)

[edit] Pointless considering our login is unencrypted

See here.

No need to brute force a password if you can read it in plain text.

— Armed Blowfish (mail) 19:00, 7 May 2007 (UTC)

Man-in-the-middle attacks are possible, but it's probably premature at this stage to try to make policy about this. I suggest that this section be replaced by something like:
Even the securest password will not necessarily stop your account being compromised. This policy doesn't address matters pertaining to your personal security measures, such as not writing your password down, avoiding shared computers and avoiding logging in in public places where you can be shoulder-surfed or keylogged. Remember that you can usually edit any article without logging in.

--Tony Sidaway 19:13, 7 May 2007 (UTC)

A man-in-the-middle attack is when a third party pretends to be a Wikimedia server. This is completely unnecessary, since the connection between our computers and Wikimedia servers in unencrypted, i.e. plain text. There are a number of routers and servers involved in transporting data between you and the Wikimedia servers. If there is an eavesdropper anywhere on this connection, all they need to do is read the packets. This is Wikimedia's problem, not ours.
A keylogger is a similar situations, except the eavesdropper either has software on your computer paying attention to every keystroke the operating system receives, or the eavesdropper is a piece of hardware between the keyboard an computer. This isn't Wikimedia's problem, but it would be nice if they allowed spaces in passwords, which have been known to confuse keyloggers.
— Armed Blowfish (mail) 19:24, 7 May 2007 (UTC)

I've decided to replace that section, which is a sort of tutorial, with this:

Other security
This policy isn't a tutorial on all the possible ways in which a Wikipedia account could be compromised, but keeping a secure account is the editor's responsibility. Editors are required to take security seriously; the penalty is a compromised account, blocking, and the prospect of having to start all over again to regain the community's trust.


This seems more on topic, and in keeping with this document's intended role as policy. --Tony Sidaway 19:57, 7 May 2007 (UTC)

That misses the point of the section I added. It is possible for it to be completely the Wikimedia Foundation's fault. Short of never ever logging in, there is no way to prevent your password from being stolen by an eavesdropper if the Wikimedia Foundation won't do their part and encrypt the login. — Armed Blowfish (mail) 20:34, 7 May 2007 (UTC)


Seems like a bit of a paranoid overreaction to me. Some admin accounts have been hacked resulting in the main page being absent for a period of entire minutes! ZOMG OH NOE!!!! Whatever happened to the idea of soft security? The Land 20:47, 7 May 2007 (UTC)
I've unforked the fork. The two sections can cohabit because they're not mutually exclusive. I think Armedblowfish's version is not appropriate to a policy document, however. It isn't the place of policy to educate editors on technology. The wording should be kept simple and the concepts introduced should be no more complex than necessary to explain the policy. --Tony Sidaway 21:44, 7 May 2007 (UTC)
Agreed - Armedblofish's material doesn't need to be in this particular document. Even if the general ideas stay, it needs to be rewritten quite badly. That can easily be done but I don't think it should even stay. --ElKevbo 21:58, 7 May 2007 (UTC)
No one is preventing you (or anyone else) from using the https server(s). Further, placing blame doesn't do anyone any good. We can't eliminate the risks; we're just here to figure out how best to minimize them. And holding editors responsible when they fail to practice even minimal precautions is reasonable.
Using this as a platform to demand change on the part of the developers isn't quite the purpose of this discussion or this proposed policy. I'm not saying or even intimating that such demands can or should not be made. This simply isn't the place for it. --ElKevbo 22:01, 7 May 2007 (UTC)

[edit] What about SSL?

I'm sort of puzzled why there's no mention of ssl/https in the security draft. If we required use of secure logins (thus preventing passwords being revealed over insecure http sessions) at least for admins, that would eliminate a whole class of problems, especially with people editing/administering from publicly-accessible networks. --MCB 20:44, 7 May 2007 (UTC)

I added something about this to the wireless section. 71.141.91.251 05:55, 9 May 2007 (UTC)
Strongly agree. Anything the Wikimedia foundation can do is going to have a much bigger and more immediate impact than is realistically possible from efforts to educate millions of users about our idea of good practices. Warnings to the general user community may possibly help in assigning legal responsibility (addressing liability, insurance, and other CYA issues after the server barn door has been opened and the server horses already gone), but they can't be realistically expected to achieve much in the way of actual results in terms of keeping the server farm safe to begin with. Best, --Shirahadasha 21:16, 7 May 2007 (UTC)
Comment Agree focusing on admins is likely to have a greater impact. My remarks about realistic expectations are limited to requirements for general editors. Best, --Shirahadasha 14:01, 8 May 2007 (UTC)
There is an ssl address. This should be given in the policy. I don't know what it is because I seldom feel the need to use it. --Tony Sidaway 21:39, 7 May 2007 (UTC)
Why not make it the default? --Shirahadasha 21:40, 7 May 2007 (UTC)
That would be a matter for the developers. We don't tell them how to run the servers they don't tell us how to write an encyclopedia. --Tony Sidaway 21:46, 7 May 2007 (UTC)
First, no one is telling anyone how to do things. Second, when issues on one side of this perceived fence greatly affect issues on the other side, then sure communication and cooperation are warranted. --ElKevbo 21:55, 7 May 2007 (UTC)
The developers are pretty much on top of this situation now. They have been running a cracking script on all administrator passwords and taking appropriate action to deal with the (numerous) accounts they have found to have weak ones. Obviously we'd like them to fix the account registration system so that it stops people using stupid passwords. --Tony Sidaway 22:09, 7 May 2007 (UTC)
I'm no security expert but perhaps a link to [3] this, the SSL-enabled Wikipedia? x42bn6 Talk 22:31, 7 May 2007 (UTC)
(by the time the autoblock finally goes away... edit conflict) https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page However, I read somewhere that it uses null encryption, so it is just meant for editors who have a hardblocked proxy configured over http but not https, or in case the Chinese Firewall decides to block en.wikipedia.org but not secure.wikimedia.org. It used to be an open anonymising proxy itself, and was even softblocked once, but now it's a transparent proxy. — Armed Blowfish (mail) 22:44, 7 May 2007 (UTC)
It uses real encryption. 71.141.91.251 15:14, 9 May 2007 (UTC)
I strongly disagree that "that would be a matter for the developers". It's a policy issue, not a technical one. There should be a properly-certificated https server with strong encryption, and it should be the default, and it should be required (or at least strongly encouraged) to be used by admins. That's pretty much an industry "best practice" for web services that require identity credentials. I'm flabbergasted that there would be any opposition to this. --MCB 06:36, 8 May 2007 (UTC)
If SSL was always enabled everywhere, the servers could never handle the load. Just having the login page be encrypted would be a more reasonable solution, but that would probably take quite some work to integrate into MediaWiki given the current architecture. Again, it's up to the devs to decide if this additional security is worth their (very) limited time and resources. Redquark 13:44, 8 May 2007 (UTC)
If my (cursory) reading of Mediawiki source is correct, encrypting just the login would only prevent an attacker from changing an account's password. —Cryptic 18:00, 8 May 2007 (UTC)
At the very minimum, the password should be encrypted at login time. The server load would not be too bad. However, the login cookie should also be served securely, or at least have some cryptographic authentication and contain the user's IP address and have a timeout. If the cookie is served by SSL, that does increase the server load a bit more, but it's still not as bad as many people seem to think (that was true 10 years ago but servers are much faster now). 71.141.91.251 05:54, 9 May 2007 (UTC)
See the discussion at Bugzilla entry 225 and this posting by Brion:
Experimental HTTPS interface to the wikis (Wikitech-l Mon Dec 26 11:33:02 UTC 2005)
In short, the HTTPS connection is encrypted, and it was created exactly as a remedy for the kind of problem discussed here:
This should allow privileged accounts to log in and do their business on an open wireless network without entrusting their password, session keys, etc to everybody on the WLAN.
Back then Brion asked not to spread the URL too wide, as the HTTPS connection was still experimental. However, as for the load issue, it is running on a separate server, so if too many people use HTTPS, other users using unencrypted connections and the site in general would still be unaffected. Actually, the HTTPS connection always seemed considerably slower to me, so I assume that most people would prefer the unencrypted connection most of the time.
Regards, High on a tree 13:15, 12 May 2007 (UTC)
Actually I would much prefer an SSL connection for login purposes. The remainder of the time I can live with standard http. — RJH (talk) 21:36, 18 May 2007 (UTC)

[edit] Dual password?

How about giving admin accounts two passwords, one to login (standard user mode) and the other to 'arm' their admin powers? Preferably with the second password using a secure login. Perhaps disabling the admin powers if the 'outer' password is incorrect three times in a row, until re-activation by e-mail. Would this be possible? Bfp (talk) 23:07, 7 May 2007 (UTC)

In my opinion, that just makes administrator accounts more complicated. One strong password is enough. Also, if you're going to secure the admin login, why not secure the normal login instead? Acalamari 01:46, 8 May 2007 (UTC)
There's insecure passwords, and there's also insecure computers. The double password would let admins login at public computers using the same account they use for admin'ing, without exposing a sysop password to the public computer. I'm not that delighted with the advice to admins to use what amounts to sock accounts for non-admin stuff. 71.141.91.251 06:04, 9 May 2007 (UTC)
I like the idea of an admin password but I think it's something for wikitech-l or mediawiki-l. --Tony Sidaway 06:42, 10 May 2007 (UTC)

[edit] Wireless Home Networks

I believe a section should be included regarding using wireless home networks and how they must be password protected and encrypted... far too many people just "Plug and Play" without realizing that everyone within shouting distance can use your internet connection. Cascadia 23:35, 7 May 2007 (UTC)

Honestly I want to avoid this policy becoming a security HOWTO. Telling people they're responsible for keeping their password secret is explaining Wikipedia policy. Telling them their wireless connection is a liability, while informative, doesn't really help to explain any part of our policy. --Tony Sidaway 23:38, 7 May 2007 (UTC)

[edit] Outside the box solutions

No matter how secure your password, given time, it can be brute force hacked. For any developers reading this, are there any server-based solutions under consideration?

For example, there is a popular Virginia Tech subscription-based site that limits you to being logged in on two computers. It gives you two cookies and you need to have both the cookie with your GUID and your username/password. Limiting you to two cookies on Wikipedia would be painful - some people have home/work/laptop/work laptop/etc. But email verification could be required for admins to login for the first time on a particular computer and get a new cookie. --BigDT 01:15, 8 May 2007 (UTC)

This is not feasible: there's no way to tell if someone has switched to a new computer. People's IP addresses change all the time (dynamic addresses from ISP's, proxies that cycle through addresses from one edit to the next, etc). Part of our culture has always been that admin actions are reversable and as such, bad stuff done by errant admins or by compromised accounts can be reverted without too much lasting damage. If that's no longer true, we have bigger problems than can be solved with cookie-rationing schemes. We have to rethink the concept of giving out sysop bits to basically anyone who edits for a while and then asks for them. 71.141.91.251 16:05, 9 May 2007 (UTC)

[edit] one-way encryption

Are MediaWiki passwords one-way encrypted? If not, users' accounts could be easily compromised in the event that the database is accidentally leaked. --Ixfd64 01:44, 8 May 2007 (UTC)

I'm told that it's a MD5 hash with salt. Having worked with mediawiki, I can confirm that the passwords themselves are not stored. --Tony Sidaway 02:04, 8 May 2007 (UTC)
You are correct it's MD5 with salt (the userid). Here's the function if that helps:
function wfEncryptPassword( $userid, $password ) {
        global $wgPasswordSalt;
        $p = md5( $password);

        if($wgPasswordSalt)
                return md5( "{$userid}-{$p}" );
        else
                return $p;
}

Gutworth 02:30, 12 May 2007 (UTC)

[edit] Notice and restoration of privileges

I entered this change: "Before the removal of these privileges, editors with weak passwords will be contacted and given a chance to change to a strong password. If privileges are removed because of a weak password, said privileges will be automatically returned once the password is strenthened."

We need to have something in here on giving people notice that we're going to take away their privileges. Likewise, the privileges must be given back when the editors conform to the policy. The reason for this is that password standards change over time--what is a strong password today is likely to be weaker tomorrow. An admin may have thought his or her password was strong but be unaware of technical changes which have weakened it. Therefore notice and a restoration info should be in this policy.

As long as this change is made, I support this policy/guidelines. Comments from others?--Alabamaboy 01:58, 8 May 2007 (UTC)

No, that's poor security. If an account has a weak password, we should assume that it has already been compromised unless there is good strong evidence to the contrary.
Administrator passwords should be unequivocally strong. So strong that they're highly unlikely to be hacked by the kind of trawl the developers did today. --Tony Sidaway 02:02, 8 May 2007 (UTC)
I'm not saying the passwords shouldn't be strong. But before we yank privileges from a ton of users, we should give notice and a way to rememdy the situation. That said, I could live with at least the remedy. B/c of the risk, yank the privileges but give them back once the password is strengthened. --Alabamaboy 02:09, 8 May 2007 (UTC)
The effect of giving warnings would be that lazy administrators would have no incentive to set a strong password in the first place. They'd just be able to sit around waiting for a developer to crack it and give them a warning, then and only then would they be faced with the need to do what they should have been doing all along. Telling administrators that their account could be locked out or desysopped without warning is factual (this is what happened yesterday) and it also tells the administrator how seriously we take personal responsibilty for site security.
I find it absolutely unbelievable that the community would consider routinely resysopping an editor who compromised site security in this way, but there doesn't seem to consensus on my view. I can live with the idea that a few known security risks are resysopped. --Tony Sidaway 12:05, 8 May 2007 (UTC)

[edit] Prompting about strong passwords?

I just noticed, on my Watchlist page, it's prompting me to make sure I have a secure password. I do (I use secure passwords everywhere) but I don't have any special privileges on wikipedia... Is this just a generic reminder to everyone, or are we all supposed to change/check our passwords every so often [like some systems require]? HeathersAngel 04:31, 8 May 2007 (UTC)

I have the message, so we're all being advised. I personally think that non-administrators should strengthen their passwords, and if they're nominated for adminship, they should strengthen them again, regardless of the RfA's success. Acalamari 17:27, 8 May 2007 (UTC)
It's always a good idea to have strong passwords; imagine if someone hack your account and ruined you reputation. However, it's especially important for admins because more damage could be done. Gutworth 02:34, 12 May 2007 (UTC)

[edit] Different passwords for every system

I don't think it's realistic to expect us "to use different passwords for every system on which you have an account". It's quite easy to notch up half a dozen accounts. I can't remember half a dozen different passwords in addition to the passwords that I already have, without writing them down. To make matters worse, I use some of my accounts rather infrequently; passwords which I only need once a month are nigh impossible to remember. -- Jitse Niesen (talk) 11:46, 8 May 2007 (UTC)

It's good advice. While not everyone will follow it, I don't think it's appropriate to remove a useful tip. --Tony Sidaway 17:27, 8 May 2007 (UTC)
I think it impairs Wikipedia's user-friendliness and I'd avoid scaring non-admin users with this type of advice. On the other hand, writing down passwords is perfectly fine, if you protect the written list even slightly. Nobody is going to remotely crack their way into reading a piece of paper that you carry in your wallet. 71.141.91.251 08:10, 9 May 2007 (UTC)
I have issues with Bruce Schneier's wallet theory but this is not the place to discuss it. I broadly agree with the principle that a record can be useful. For instance if you live alone and Wikipedia is your secret vice, you could tattoo your password on your forehead without incurring any significant security risk to Wikimedia. The devil is in the details. Such advice is not universally applicable. --Tony Sidaway 06:50, 10 May 2007 (UTC)

[edit] Contradiction.

In the subsection "Password security tips", tip 6 and 7 seem to contradict each other:

6. Do not log on using public computers.

7. If you decide to log on using a public computer, remember to log out when done.

Wouldn't it be worth merging them to something like this:

6. Avoid using public computers to edit, but if you do decide to use one, always remember to log out when you are done.

Does that seem less contradicting? Acalamari 16:28, 8 May 2007 (UTC)

Yes. Change made. --ElKevbo 16:35, 8 May 2007 (UTC)
Thanks. That reads better now. Acalamari 16:37, 8 May 2007 (UTC)
How about adding: After using a public computer, change your password the next time you are back on your private computer. NoSeptember 17:33, 8 May 2007 (UTC)
I have done this, but I've worded it a bit differently. Acalamari 18:00, 8 May 2007 (UTC)

[edit] Policy

There seems to be broad consensus on this, though with the usual discussion on detail. I'm testing consensus now by replacing "proposed" with "policy". Please remove and discuss if you disagree. --Tony Sidaway 16:52, 8 May 2007 (UTC)

I have no objection. That was a good idea. Acalamari 16:58, 8 May 2007 (UTC)
First, I think we should wait for more input and refinement before certifying this as policy. It hasn't been advertised widely enough and for long enough. It seems too early to declare a policy of having people reapply for privileges, since (unless things reversed while I was asleep) one of the cracked admins has been resysopped and another was being considered for reinstatement. I have some textual criticisms below.--ragesoss 17:46, 8 May 2007 (UTC)
Oh it's been advertised in the right places: Village pump, admin noticeboard. Add more if you like. More discussion is good, so no problem. --Tony Sidaway 23:19, 8 May 2007 (UTC)
What about places like the Bureaucrats' noticeboard and Wikipedia Talk: Administrators? Is it worth having it posted in those places? After all, those pages seem to be watched a lot. Just a thought. Acalamari 23:26, 8 May 2007 (UTC)
Seems reasonable. This policy proposal has already been mentioned twice in passing on Wikipedia Talk: Administrators, but it can't hurt to create a new section about it. Incidentally in addition to WP:AN, WP:ANI, and WP:VPP I've also advertised this on:
--Tony Sidaway 23:39, 8 May 2007 (UTC)
Excellent. That should attract more discussion easily. The pages you've listed this seem to be heavily watched. Acalamari 23:46, 8 May 2007 (UTC)
  • Not that I mind per se, but this looks more like a list of suggestions to make your account less vulnerable, than an actual enforceable policy. Radiant! 15:14, 9 May 2007 (UTC)
    I agree. Perhaps it would be a good idea to merge much of this with another recent creation: Wikipedia:Personal security practices. What remains, if anything, should tell us things like what is going to happen if our account is compromised. I'm going to slice out everything that looks like advice, and put a "See also" for that proposed guideline. --Tony Sidaway 15:32, 9 May 2007 (UTC)

[edit] Clarity

This page doesn't make clear exactly what rules/policies it is proposing. The crux of the issue is that having a weak password will have consequences, but there is ambiguity about what those consequences are. In particular, the main section says "Administrators, bureaucrats, checkusers, stewards and oversighters discovered to have weak passwords will have their privileges removed on grounds of site security", implying that having your password cracked by internal measures will result in losing whatever bits you have. The "Other security" section, which is titled and positioned like an afterthought, contains I take to be the real intention (though I'm not sure), which is that internally-cracked passwords will result in being locked out of your account and forced to use a better password, and externally-cracked accounts will lose their bits.--ragesoss 17:46, 8 May 2007 (UTC)

To give you an idea of what I originally intended, here is the first revision. I would reverse the order of the sections, putting passwords first, but otherwise I think it says all that needs to be said in a policy document. But that's just my personal preference. I think I'll abandon this now and leave it to find its own way to whatever it's going to be: guideline, policy, or whatever. I've said all I felt needed to be said. --Tony Sidaway 23:17, 8 May 2007 (UTC)

[edit] security tips

I hope you guys liked the security tips that I added. The majority of those tips were based on advice given to RuneScape players. (RuneScape is an online game where account theft is common.) Although Jagex (the company that develops RuneScape) takes account safety very seriously and has added many security features to their game, many players still get "hacked" due to carelessness. But then again, Wikipedians tend to be smarter than RuneScape players, and that there isn't much to gain from stealing a Wikipedia account. --Ixfd64 23:23, 8 May 2007 (UTC)

The sudden activity on this page is because of a recent spree of admin passwords getting hijacked. 71.141.91.251 06:59, 9 May 2007 (UTC)

[edit] Strong password proposal

I propose defining "strong password" as follows: a strong password is a a password or passphrase generated at random by the Wikipedia server and presented to the user by the server. (Of course the software would have to be extended to implement this feature). The exact technical characteristics would be up to the developers. By this definition, any password chosen directly by the user would be considered weak, as per the US Department of Defense password management guideline.

You'd get a strong password by clicking "give me a strong password" in the normal password-changing dialog. You'd be instructed to make sure you were using a trusted computer with nobody looking over your shoulder, etc. The server would generate and display a password for you, and you'd write it down and click "accept this password". You'd have the option of rejecting the password and having the server generate another one, but the idea would be to not do this too many times.

In the implementation, I suggest that a strong password would be a three-word phrase separated by hyphens, generated at random from a wordlist by the server. Some examples (via diceware):

jude-cream-sold
13th-tracy-brady
gc-budd-camp
sibley-ian-curve
gk-plead-trim
lobo-ol-vicky

Passwords like this are fairly easy to type and remember after a few uses. They'd be available to all users. Admins would be urged (but perhaps not required) to use them. The server could remember who was using them and who was not. Maybe really dangerous accounts (bureaucrat, checkuser, etc.) should be required to use them, or even one-time passwords. 71.141.91.251 06:29, 9 May 2007 (UTC)

[edit] crackers

This proposal presently excludes any password that can be cracked by one of the many quite sophisticated open source password crackers available on the internet. There is no statement about a time limit or an expected time to crack. Does "quite sophisticated" rule out a simple brute force checker? I expect I can find a simple cracker that chooses a restricted alphabet (or not) and password length, and works through every combination - say 8 characters from [a-zA-Z0-9!@#$%^&*();:,.<>/?\|-_=+[]]. It might take 6 months with a hundred office PCs, but the current wording actually doesn't even require the password to be cracked by this hypothetical program, only to be able to be cracked in an unbounded timeframe. I don't believe any static password is capable of passing this test. --ScottDavis 15:38, 9 May 2007 (UTC)

You're right on fact, but let's look at this in the context of Wikipedia. The developers don't try to crack passwords for fun, because there are a lot more interesting things to be done on the mediawiki project. But if the developers happen to run a sweep of password hashes and happen to find one that's easy to crack, they'll lock it out for the integrity of the wiki. This should be all that any sensible person needs to know. Choose a decent password. There is advice on this, and other related matters, on Wikipedia:Personal security practices. --Tony Sidaway 16:17, 9 May 2007 (UTC)
Thankyou for trimming out the hyperbole. It looks much better this morning. --Scott Davis Talk 23:05, 9 May 2007 (UTC)

[edit] Public computers

Does anyone else think that the public computer language should be stronger? I really think that admins should be expressly forbidden from editing with their admin accounts from truly public computers (public libraries, school computer labs). Unless you have some knowledge of the setup, that's just asking for trouble. If the machines are networked together, a malicious user could pull up your computer in the network neighborhood and copy your cookies. Heck, as far as that goes, you could have a power failure and not have the opportunity to log out.

I would strongly suggest that administrators be expressly forbidden from connecting using public computers. Any thoughts? --BigDT 15:40, 9 May 2007 (UTC)

Unenforcible and there may be some users who do most of their editing at public locations. x42bn6 Talk Mess 16:23, 9 May 2007 (UTC)
This is a policy document, and policy documents describe policy, not what a few of us here might want to happen. We can add your proposal to the policy if you can get a strong consensus for it. Adding it to the document now, without a strong consensus, would lessen its strength as policy. --Tony Sidaway 16:19, 9 May 2007 (UTC)
Well, I think that as a policy, we should recognize that editing from a public computer with an admin account is inherently a security risk. It may not be as big of a risk as a bad password, but it is still a real issue. --BigDT 16:23, 9 May 2007 (UTC)
If anything, the current version is too strong against public computers. Editing Wikipedia is not really that different to lots of other internet activity, which people can manage their own behaviour about. It is unreasonable to expect someone to develop a reputation as an editor, be invited to submit an RFA, then be told to create a sock account and do their editing from that and not use their admin account. If we really want to keep admin and editing accounts separate, grant each admin a new sock named sys_<their normal username> and give the new account the admin privilege. But do we really want to stop admins from being able to easily click rollback when they spot vandalism? The threat/risk from a local user stealing a password is quite different from the threat of a well-known admin having his/her account cracked over the network. If we allow not-logged in edits, we should encourage logged-in edits from regular editors, regardless of where they edit. --Scott Davis Talk 23:19, 9 May 2007 (UTC)

[edit] Back to basics

I've radically edited this page. A lot of the recently added material on this proposed policy is redundant with, or belongs on Wikipedia:Personal security practices. I'm trying to aim this page towards policy status. A policy, on Wikipedia, tends to be a statement along the lines of "fire hurt". It tells you what will happen in certain circumstances. I've tried to give an account of policy as it has developed over the past few days, to wit:

  • it has always been the case that an editor with poor personal security can get his account cracked and end up blocked for bad edits he didn't do;
  • when this happens to an administrator his account is almost invariably desysopped, at least for the time being
  • restoring adminship after such revocation is at the discretion of the bureaucrats
  • we don't have a standard definition for a "strong password", but that doesn't excuse anyone having a weak password.

Please add advice on choosing a good password, etc, to Wikipedia:Personal security practices. We don't make policy about which methods editors will use to choose a password, because that would be silly. --Tony Sidaway 15:55, 9 May 2007 (UTC)

If the warnings you have just stated are not already somewhere then IMO it is fine to add them. Here, or somewhere else more appropriate.
Note that Wikipedia:Personal security practices was moved into the project's namespace only hours before this page was created, so a merge may be appropriate, with neither having any kind of priority over the other for being the merge target.
As to policy itself, I can hardly see what good will come from having admins, etc., lose their previleges for having a "weak password". Mostly because "weak password" is left undefined. Isn't it too open to create misundertandings?
IMO the most important thing would be to increase site security from the inside, not placing the burden mainly on admins. That is, is there... A failed login limit, with increasing waiting times between failures? Some kind of admin certification so that one may assert its identity and regain its status? Some password strenght algorithm to check current and future admins passwords, and reject changes to weak ones? And more or better measures could be taken certainly, I'm no security expert...
Are any of this implemented? If not were they suggested?
Anyway, I appreciate your effort in trying to improve security, that's for sure. - Nabla 16:18, 9 May 2007 (UTC)
It says that users with weak passwords may lose their privileges because that is what happened the other day. Some of the admins may have lost their privileges permanently. Just about all the things you suggest (admin identity, improvements in site security) are being done but are outside the scope of this document which is about community policy rather than technical fixes. --Tony Sidaway 16:35, 9 May 2007 (UTC)
Right, I've just checked the technical ideas at Village Pump. And made a failed loging, and found out a captcha. Fine.
Back to policy, I guess users/admins did not lose their previleges directly because they had a weak password. They lost them because their account was abused (which happened because of a weak password). That's quite different. If you want preventive action, I fail to see how it could be made by the community. How will the community check if my password is weak? I can't reveal it... Nabla 16:53, 9 May 2007 (UTC)
No. Although Brion (our lead developer) has not yet reported on this officially, the other day he scanned the admin passwords and disabled the accounts that had easily crackable passwords. The Signpost reports:
Lead developer Brion VIBBER has run a password cracker on all administrator accounts and invalidated the weak passwords of several additional admin accounts. These admins will have to reset their passwords by e-mail before logging in again. Wikipedia:Administrators has been amended to note the importance of strong passwords for administrators, bureaucrats, checkusers, stewards and oversighters. HighInBC has sent a mass e-mail to all administrators informing them of the situation and advising them to select strong passwords if they have not already done so.
It's highly probable that owners of relatively inactive admin accounts who had weak passwords and no authorized email address have no way of establishing that they are the account owners and have thus permanently lost their administrator privileges. --Tony Sidaway 17:38, 9 May 2007 (UTC)
That's a developer's action, not a comunity action. I still can't see what the comunity may do about this. - Nabla 11:22, 15 May 2007 (UTC)
Thanks for the word-up, Tony. Re: merging Wikipedia:Personal security practices and Wikipedia:Security, I wouldn't be opposed, but I think the respective content areas of both pages probably need more working out at this time... Probably, they could eventually be merged under the "Security" or "Personal Security" placename, if the content/ideas on this page do not have to be overly specialized, they would fit in the current organizational structure of WP:PSPS, but as the content on this page seems to be evolving at a rapid pace it might be better to let that process happen "here" for now.—ACADEMY LEADER FOCUS! 03:20, 10 May 2007 (UTC)

[edit] Password tips

My feeling is that stuff like tips on password use and so on do not belong here, they should be somewhere like Wikipedia:Personal security practices. What's the general thought on this? I've asked Ramdrake to come to this page and discuss this. --Tony Sidaway 17:41, 9 May 2007 (UTC)

While I would generally agree with you, I believe this is a case of using a term ("strong" password) without defining its use in the same article. I believe this presumes users know in advance what a "strong" password is (evidence on this talk page points to the fact that not all users do). Therefore, we should give some amount of advice on this page (or embedded links links, as opposed to the "See also" section) to ensure users really know what we mean. This, IMO, takes precedence on other considerations. My understanding of the WP project is that its goal is (at least in part) educational. If we set up rules for our users without educating them as to what those rules mean, then I'm afraid we're bitterly failing our goals.--Ramdrake 18:11, 9 May 2007 (UTC)
Do you think that replacing the tips section with "for tips on password security, see Wikipedia:Personal security practices" would be enough? --Tony Sidaway 18:16, 9 May 2007 (UTC)
If you can also add something along the lines of "for tips on what is or isn't a "strong" password see so-and-so", then I would withdraw my objection. Can we agree on this?--Ramdrake 18:20, 9 May 2007 (UTC)
There are (or were) links in the page to password strength, which explains the concept in a bit more detail and gives several practical examples of how to create a strong password. If they've been removed, or are not prominent enough, then they should be restored or made more prominent. --Tony Sidaway 18:36, 9 May 2007 (UTC)

[edit] In a nutshell

I had put this further explanation in the nutshell section:

Failing to use a sensible password can lead to your account being hacked and used to inflict damage on the Wikipedia project. This in turn can lead to temporary loss of editing access or even to permanent loss of privileged access.

Tony Sidaway reverted it to:

Failing to use a sensible password can lead to temporary loss of editing access and may lead to permanent loss of privileged access.

I'd like to get a feel for the consensus of the community as to which is more appropriate. Primary concerns, IMHO, should be completeness and accuracy.--Ramdrake 18:20, 9 May 2007 (UTC)

The wording I have used is factually correct. Some admins have been locked out of their accounts by Brion Vibber as a result of his scan for weak passwords. If they have no authorized Wikipedia email address and cannot identify themselves, they have effectively been permanently desysopped. --Tony Sidaway 18:33, 9 May 2007 (UTC)
While it may be factually correct, it leaves out why this was done, which is simply because of the potential consequences of having a weak or trivial password. The "bad" deed isn't in having a weak password (it doesn't do any direct damage), the bad deed is if someone uses the weakness of this password to compromise WP (which is a direct damage).--Ramdrake 18:39, 9 May 2007 (UTC)
It's a nutshell, a brief statement saying "if you do this, this happens." The why of it is for the body of the policy document. It doesn't matter to the locked out admin whether he's been locked out by Brion on one of his sweeps or by stewards and admins as a result of a compromised account. The important point is that setting a bad password can get you locked out. --Tony Sidaway 18:44, 9 May 2007 (UTC)

[edit] Are we there yet?

I popped a "policy" tag onto it. Please revert and discuss if it still doesn't look like Wikipedia policy to you. --Tony Sidaway 20:08, 9 May 2007 (UTC)

Two things bother me. First, I think saying that it's up to a bureaucrat's discretion to re-sysop is kind of a reach at this point. Are we going to require a brand-new RFA? How about re-sysoping being automatic? I don't know if this has been properly thought out.
The other thing is saying that developers will check accounts and disable any account that they can crack. I'm not sure that's really got consensus at this point. I don't want to hold out on a snowball's chance in hell, but I think we need to figure out for sure what we want developers to do about weak admin passwords. (We might want the developers to have some sort of say in that as well.) Matt Yeager ♫ (Talk?) 23:05, 9 May 2007 (UTC)
I'm describing what happens. See the discussions on Bureaucrats' noticeboard for why I say it's a matter of bureaucrat discretion (which I opposed, but was obviously very much in a minority). Also the developers have checked administrator accounts and disabled them. The developers do this by changing the password and emailing the owner. This is necessary to stop a third party cracking the account in the meantime. There isn't a feasible alternative to this. Of course if the admin locked out doesn't have a validated email address then, unless there's some other way of validating the identity of the account owner the admin has effectively been desysopped by being permanently locked out of his admin account. --Tony Sidaway 05:56, 10 May 2007 (UTC)


It is a useless page as it stands. Also, the requirement that non-admins use strong passwords is unreasonable. Has there been any history of anyone cracking non-admin accounts? It's pretty common for internet users to choose carefully guarded passwords when compromise has potentially serious consequences (e.g. the password for one's online banking account), and take lesser precautions for passwords to general-information and recreational sites such as discussion forums, blog comment areas, and (like it or not) Wikipedia. This proposed policy says that users should treat Wikipedia passwords like they treat their online banking passwords. It's ok to expect that level of responsibility from administrators but I don't think adequate justification is presented (or exists) for normal users. It's in serious tension with all the stuff about how easy and unimposing it is for editors to register and use accounts instead of editing from IP addresses. If there's actual policy about password choices ("policy"=failing to adhere to it can get your account shut off), it should apply only to admins. For regular users the page should be considered advisory at most. 71.141.91.251 03:05, 10 May 2007 (UTC)
All this proposed policy says about non-admin accounts is Editors must use a strong password to avoid being blocked for bad edits by someone who guesses or "cracks" other editors' passwords. That's just a fact of life. An editor who chooses a weak password may end up being cracked by a malicious person and blocked because of that person's bad edits.
How about changing it to the following (should rather than must):
Editors should use a strong password to avoid being blocked for bad edits by someone who guesses or "cracks" other editors' passwords.
Could you elaborate on your first comment: It is a useless page as it stands? --Tony Sidaway 06:04, 10 May 2007 (UTC)
I think there was an incident of someone collecting ordinary accounts with weak passwords to get a large sockpuppet army that could edit semiprotected pages, so ordinary editors should also have good passwords to avoid this. Kusma (talk) 12:21, 10 May 2007 (UTC)
Well "useless" was maybe a bit harsh, but I think the current page just says commonsense things and the helpful info it contained before has been moved to another page. Wikipedia already has too much policy and bureaucracy and I don't think enshrining the current document as policy is going to help with much. Policy normally reflects decisions reached after hashing through difficult issues that make it worth writing down, and this stuff isn't difficult. The one new concept emerging from the recent incident is "strong passwords for admins are mandatory", and that sentence should just be added to some existing document (like the RFA candidates' guidelines) rather than made into a separate document of its own. Re sockpuppet armies: I thought that was usually done by enrolling sleeper accounts and letting them age. 75.62.6.237 (new address) 04:41, 11 May 2007 (UTC)

[edit] Guideline, not "policy"

A page like this is basically intending to give clues to the clueless. This is, of course, almost impossible. It can't be more than a guideline. That said, it should be possible to write a useful page of this sort - David Gerard 13:12, 10 May 2007 (UTC)

I think of it as a policy akin to the Three revert rule. We say "look, if you have a stupid password, this will happen" and when their account is compromised, blocked and/or desysopped we can say "look, we told you that this would happen if you insisted on having a stupid password." The clued up who might have been in doubt about how seriously to take password security will have their doubts dispelled and resist the temptation to set their password to "jimborules". That's why I've made a point of spelling out what has actually happened in this event.
If you doubt this is needed, you haven't had the arguments I've had with people who insist that Wikipedia administrators could not be expected to realise that there was anything wrong with setting your password to "password", as at least one of the compromised admins had. Yes, that's how dense the arguments got. --Tony Sidaway 13:20, 10 May 2007 (UTC)
Well, David has a point that making a policy called "Don't be stupid" will not magically cause people to not be stupid :) Anyway, did e.g. Brion actually state that "the developers will occasionally try to crack their passwords"? Radiant! 14:23, 10 May 2007 (UTC)
He's done so once and I'm sure he could do so again if it was necessary. Does he plan to? Don't think so.
This isn't just "don't be stupid", it's "if you're stupid this will happen." Pretty much like our blocking policy, our protection policy, and so on. --Tony Sidaway 23:41, 10 May 2007 (UTC)
Yes but will it actually happen? If a developer cracks someone's password using a dictionary or a brute force attack, and we now have catchpas to prevent such attacks, then surely it isn't necessary to de-admin? All that needs be done is an email should be sent telling them to strengthen their password. Only passwords that can easily be guessed need action taken, and weven then I'm not convinced.What actual security risk are we talking about here? Is it actually possible for an admin to really damage Wikipedia? I don't think so. Theresa Knott | Taste the Korn 07:32, 11 May 2007 (UTC)
Yes, it would be a trivial matter for someone with unexceptional, pedestrian programming skills, to take a hijacked admin account and cause sufficient damage to require a lot of painstaking unpicking. A skilled programmer, planning the attack carefully, could cause extensive outages and possibly cause enough havoc to require the site to be restarted from a database dump.
Captcha doesn't apply to accounts that have already been cracked. Sending a warning in such cases may simply tip off the cracker (if the cracker has changed the email address, the account owner will not receive the warning and will remain unaware that his account has been cracked). Temporarily locking out the account is the only safe thing to do. --Tony Sidaway 12:16, 11 May 2007 (UTC)
I think that the difference is that if a user is disruptive, a well-meaning admin will likely block him to improve the wiki - whereas if a user has a stupid password, a bad-faith hacker might in some cases steal has account to wreck the wiki. Not quite the same thing. Radiant! 08:56, 11 May 2007 (UTC)
An admin account with a stupid password like "password" exposes the wiki to the risk of serious damage. You have to secure the wiki and that may involve locking the legitimate user out. --Tony Sidaway 02:33, 12 May 2007 (UTC)
I'm having trouble with this concept. Wikipedia has a longstanding tradition of giving adminship to just about anyone who wants it, rooted in the premise that admins can't do all that much non-easily-reversable damage. So if that premise is incorrect, either the software should be fixed (say to limit the number of admin actions per hour an individual admin account can perform), or alternately, adminship should become much harder to obtain (require real-world ID sent to the Foundation, etc). I think currently we have a quite small number of high-privileged accounts that are issued rather carefully carefully and who (at least for stewards and checkusers, not sure about bureaucrats) are not anonymous; plus we rely on a much larger number of anonymous admins with relatively limited privileges, who are mostly basically casual volunteers. If we want to stay with that overall organizational scheme, then the attacks you're describing should be considered software security bugs, so you should discuss them with the developers and help them work out fixes. 75.62.6.237 03:07, 12 May 2007 (UTC)

[edit] Legality?

I'm not too up to date on my international law, but my instinct about American law tells me that intentionally telling someone that they will crack into their account is highly illegal and can be punished by jail time. Now, I'm not sure if the statement in this policy is just a hoax to scare people, or if developers are actually trying to hack accounts. On the off chance that this is illegal (which I'm almost sure this would be), I would suggest you abandon this language. JP06035 21:01, 10 May 2007 (UTC)

Why would it be illegal if site administrators (developers) were doing it. We don't have a terms of use / contract that says otherwise... --Iamunknown 21:15, 10 May 2007 (UTC)
Yeah, but would it be legal for a Google employee to break into your Gmail account because it has a "faulty password?" Certainly not. On any website that is password-protected, why should one live in constant fear that someone it trying to break into their account. Granted, it happens every day, but a written statement saying that it will happen is asking for trouble. JP06035 21:22, 10 May 2007 (UTC)
Poor analogy. It's more like the IT department at your employer stating that they are going to attempt to brute force all of the employees' passwords to make sure that they are secure. TomTheHand 21:49, 10 May 2007 (UTC)
I signed a contract with my employer giving them certain rights to do things like that. I recall no such contract with Wikipedia. I think Jared's probably right here. But IANAL... =/ Matt Yeager ♫ (Talk?) 23:14, 10 May 2007 (UTC)
I... am pretty sure your employer didn't need to enter into a contract with you to get the right to do what they want with their servers and data. You may have mistaken being made aware that company servers belong to the company with giving permission. TomTheHand 00:07, 11 May 2007 (UTC)
It's Wikimedia's site. The developers have absolute and complete access to everything, including (in certain operational configurations) clear text logs of all incoming data--usernames, passwords, everything. A password system is imposed to safeguard the accountability of contributions, not to protect data from Wikimedia staff (staff here interpreted in a broad sense to include certain volunteer developers). Wikimedia staff are authorized to carry out all functions needed to maintain the integrity of the site--that means being sure nobody has set a dumb password on an admin account. That isn't illegal. --Tony Sidaway 23:46, 10 May 2007 (UTC)
"Break into account" would most likely mean use the entry to impersonate the user, or access the user's confidential data. Disabling the account for policy/security reasons is completely different from that. 75.62.6.237 04:06, 11 May 2007 (UTC)
intentionally telling someone that they will crack into their account is highly illegal is exactly backwards. The relevant US laws (and Florida's) explicitly state that they refer to actions without authorization. Clearly the owner of a computer system has authorization. You will also see the phrase in various places as may be necessarily incident to the rendition of the service or to the protection of the rights or property of the provider of that service. Here, the provider of the service is Wikimedia, and they are entitled to take all necessary measures to protect their own service from unauthorized intrusion. --Dhartung | Talk 06:25, 11 May 2007 (UTC)
"Clearly the owner of a computer system has authorization." How is this clear? My bank has no authorization to log on to my accounts as me. Of course, if it is correct that the devs have access to the passwords then there is no need. Since you can test the password directly, not touching the account at all. Taemyr 10:06, 11 May 2007 (UTC)
Indeed, devs have direct access to the password hashes and have no need to attempt to log in to your account to crack them. At any rate, I wouldn't be surprised if banks could legally log in as you as well, since it's their computer system. If they can't, it would be because of specific banking regulations and your analogy is invalid anyway. Redquark 14:04, 11 May 2007 (UTC)
Of course they can log in. It's their computer. --Tony Sidaway 02:38, 12 May 2007 (UTC)
I'm not certain that people making this objection really understand how databases work. The developers have access to the database and all data in it regardless of whether they are "logged in". Your password is stored in a database table, to which the developers have complete access, as well as to any encryption algorithm.--Dhartung | Talk 08:29, 12 May 2007 (UTC)

You're extending the term "developer" to mean more than it should; what Wikipedia users often confuse are "developers", who write the MediaWiki software, and "system administrators", who manage network and server operations. While there are some notable cross-overs (Brion Vibber, Tim Starling), these can, for the most part, be divided into distinct groups. "Developers" do not have access to passwords.

System administrators, overall, will have at least read, and more commonly, write access to the database clusters they operate, and yes, they can see your password hashes. In general, these hashes cannot be reversed. It is computationally expensive to attempt to crack a password, since it requires dual hashing, and would have to be done once per user, as the salt varies with the user record in question. The issue, however, is not one of complexity, but of need.

A system administrator does not need to crack anyone's password; they do not need to impersonate users. If a system administrator feels he or she requires, for example, CheckUser permissions, they can easily grant themselves that permission, and remove it when it is no longer needed.

In the recent case, the system administration team responded to genuine concerns over password security, and ran a limited password strength checker over user records on certain databases. Specifics on this process will not necessarily be released. Details on the the results of these tests will not be released. Users who were deemed to have weak passwords will have been advised of the situation and will need to reset their passwords via email.

There is no provision in law to prevent the operator of a system from performing checks on his system to ensure it remains secure; your password is a piece of information you are considered to have submitted to our system for the purposes of authentication. It will not be released because it is theoretically very difficult to obtain the password of a user in plain text, given their password hash. The objective here is to ensure that anyone with a weak password knows about it, and can change it; the objective is not to impersonate anyone, in fact, we're hoping to avoid that happening. —The preceding unsigned comment was added by 164.11.204.56 (talk • contribs) 21:17, May 12, 2007 (UTC)

[edit] Concequence

If someone fails to do so, instead of blocking their account, only block it if it gets hacked. But the block should be unreversable for admins with a easy password.

Flubeca 20:25, 12 May 2007 (UTC)

If they have an easily cracked password, we don't know that they are the original account holder. --Tony Sidaway 14:12, 14 May 2007 (UTC)
Someone could have stolen my laptop and be posting as me right now regardless of how secure my password is. Or I could have been kidnapped and forced at gunpoint to enter my password. But we really have to assume by default that an account isn't compromised unless it is demonstrated to be. --BigDT 14:22, 14 May 2007 (UTC)

[edit] I disagree

we have been getting along fine with out this, it is unessary. It's just praying into peoples passwords, forcing them to make it long and wordy passwords, thus hard to remember Thedudewithglasses 09:29, 13 May 2007 (UTC)

We can't possibly force everyone to use strong passwords, and the proposed policy doesn't actually attempt to do that. What it is attempting to do is to make it clear that weak passwords have (possibly catastrophic) consequences, and that we as a project have the right to protect ourself against security threats caused by the willful use of weak passwords when it is inappropriate to do so. If someone reads the propsed policy, understands it, and nonetheless chooses to ignore it, the most important information for them is that we won't necessarily help them escape the consequences of their bad choice if helping them would put the project at risk. That's really the most important part of the proposal as it stands. Gavia immer (talk) 17:40, 13 May 2007 (UTC)
I just don't see how it's so horrible for the project if a (non-admin) user password gets cracked, given there's zero authentication at account enrollment, and we allow most editing from users who aren't logged in at all. If an account gets taken over by a vandal, it becomes a vandal account just like the hundreds of other vandal accounts that we deal with every day. We can require admins to use strong passwords but I don't think we need a policy page for that purpose. 75.62.6.237 05:19, 14 May 2007 (UTC)
It's bad for the community because then we have reason to distrust someone who might formerly have been a very valuable editor. He may be driven away by the traumatic experience of having his account blocked (this does happen). It's always good to warn people about possible consequences of unreasonable and ill-judged actions. --Tony Sidaway 14:12, 14 May 2007 (UTC)
I don't see why we need more policy pages for that. Just mention it in the registration dialog or in WP:WHY. If there's been actual cases of password cracking against non-admins, mention that too. Another idea: if a user has a registered email address, send them a gently worded email after around their 500th edit, thanking them for staying involved with the project and suggesting they make sure they have a good password now that they're an established user. They may take the matter more seriously after they've been around for a while. For users who are brand new, registration is a much more casual thing, like registering to post comments on a blog, and stuff like passwords are treated as an annoying obstacle so they tend to choose lame ones. 75.62.6.237 16:32, 14 May 2007 (UTC)
This is the best suggestion I've noticed in the entire discussion. Cracking new accounts is useless, cracking admins is a project integrity problem, cracking established users is a trust problem. The email can be along the lines of "congratulations on your 500th (or 1000th) edit..." --Scott Davis Talk 04:09, 15 May 2007 (UTC)
We just need to be careful in defining the "password strength" thing: my password is a neologism in a dead language, and I can't imagine that anyone would be able to guess it without spying on me in a way that would be able to get around any password, such as watching me type it in. I don't think we need to require a certain set of characters! Nyttend 21:19, 16 May 2007 (UTC)

[edit] Machine generated passwords again

I'm thinking of entering a MediaWiki RFE requesting adding a "suggest password" feature to the software. It would be part of the regular password changing dialog. If the feature is implemented and you click a button, the server will suggest a password for you, generated by machine. It will probably look like two or three random words strung together. You'd be free to use the suggested password, request another one, or dismiss the suggestion and choose your own password as usual. The exact criterion of "strong password" could remain undefined but any passwords generated through the suggestion feature would be considered strong, and admins would be urged to use those passwords. The exact characteristics of the generated passwords would be chosen by the developers to be able to defeat any password-guessing attacks likely to be feasible, based on being able to exactly compute the information entropy in the generated passwords. That should allow cleaning up a bunch of the unscientific and inconvenient seat-of-pants password-selection advice in several pages related to this one, and get admins out of the trap of "you must use a strong password or face blocking, and by the way we're not going to tell you what a strong password is". Opinions? Would folks here use this feature? 75.62.6.237 05:19, 14 May 2007 (UTC)

[edit] Ordinary mortals

It seems to me that we should stick with advisory language for ordinary editors. Mangoe 13:55, 14 May 2007 (UTC)

FYI, Kaori, a regular user account, was breached on May 16. I'm not disagreeing with you, just providing a datapoint. -- nae'blis 14:47, 17 May 2007 (UTC)
I had no doubt that it happens. But it's not something to get that worked up over, any more than other routine vandalism is. Mangoe 15:18, 17 May 2007 (UTC)

[edit] Why do we need this to be proposed?

If the developers decide that they must periodically run a password cracker to ensure security, then community consensus for it doesn't matter. If they decide that they don't want to do that, then community consensus can't force them to do so. And I'm not seeing much else actionable on the page. -Amarkov moo! 00:28, 15 May 2007 (UTC)

I think it's more about (a) telling people this will happen and (b) giving them some advice and pointers. --ElKevbo 01:39, 15 May 2007 (UTC)
That's reasonable, but if those are indeed the only reasons, then subjecting it to community consensus is pointless. If something will happen no matter what, why bother building consensus for it? -Amarkov moo! 02:14, 15 May 2007 (UTC)

[edit] Wireless

I like it, should we add something about how using a network that has an open wireless connection allows people to see your password? HighInBC(Need help? Ask me) 15:23, 7 May 2007 (UTC)

We've been through this before, it was in and got removed. See the article on personal security practices for some tips. 75.62.6.237 03:26, 15 May 2007 (UTC)

[edit] User box equals "KICK ME" sign

If people start putting "strong password" userboxes on their (or someone else's) user page, they are simply inviting people to crack them. Mangoe 17:42, 18 May 2007 (UTC)

That's what I was thinking: that userbox is not a good idea. Acalamari 17:49, 18 May 2007 (UTC)

[edit] "...the developers will..."

Although the definition of "strong password" is deliberately left unspecified, privileged editors are required to use strong passwords and are informed that the developers will occasionally try to crack their passwords and disable those that can be cracked.

This paragraph needs to be changed. Developers are not the same as system administrators, and do not have the ability to perform such actions. The use of the word "crack" generates an inappropriate negative connotation. I suggest something like:

Although the definition of a strong password is, at the moment, left unspecified, privileged editors should be aware that system administrators will perform periodic checks for accounts with vulnerable passwords, and disable or remove permissions as appropriate to protect the site.

—The preceding unsigned comment was added by 86.140.128.210 (talk • contribs) 22:23, 18 May 2007.

I don't have a strong opinion on the use of the word "crack", but I'm positive that it is in fact developers and not administrators who will be carrying out this check. ElinorD (talk) 22:33, 18 May 2007 (UTC)

This is more an issue of Wikipedia-specific terminology than anything else - you and I know that "administrator" and "developer" are used here to mean specific roles and specific permission bits, and hopefully anyone who wants increased priveleges understands what's meant here, but a random new visitor probably doesn't know. More importantly, they shouldn't have to think about the semantics here; all that's really necessary is to make it clear that these actions come from the top, from people authorized to manage the integrity of the website. I'm going to see about rewriting this so it's clear for both groups; for now, I just linked "developers" to meta:Developers. Gavia immer (talk) 15:18, 19 May 2007 (UTC)Addendum: I've decided that my first instinct (to just use a wikilink) was the correct one. Anyone else see a problem with the phrasing there? Gavia immer (talk) 17:20, 20 May 2007 (UTC)

[edit] Blocked Otherwise?

The proposal says something like users who use weak passwords can be blocked. Would this block be indefinite or for a set amount of time??? Deletion Quality 15:26, 20 May 2007 (UTC)

It would likely be an indefinite block (meaning no set expiry date, not permanent and irrevocable). If an account is blocked as a security risk, allowing the block to lapse without human intervention is the wrong thing to do. However, the proposal as currently written does allow for unblocking; it also allows for permanent blocking. In practice, that detail is going to be related to the circumstances of a particular blocking, and prescribing one sort of behavior here is also the wrong thing to do. Gavia immer (talk) 17:24, 20 May 2007 (UTC)
Perhaps the wording is not as clear as I thought when I wrote the original. Obviously if you have a weak password and it's cracked by a malicious person your account may be blocked because of the actions of the malicious person. --Tony Sidaway 18:27, 20 May 2007 (UTC)

[edit] Strongly oppose

I strongly oppose this proposal. First of all, the most common level of privilege is "established user," not administrator as the proposal suggests. I see the need for strong password strength on Wikipedia, but anyone's arbitrary criterion of strength is always going to be weaker than someone else's. I may say that a password consisting of more than eight characters and featuring a mix of upper and lowercase is secure, while someone else may extend that to ten characters and require the inclusion of numbers and symbols. An even more paranoid individual might forbid dictionary words (yes, I have seen this on systems that offer free public registration.) Any such measures restrict the freedom of password choice of the user, and make memorizing passwords more difficult. If compromised accounts are quickly shut down, then the owner of the account has paid the price for his or her own lack of foresight and caution, the changes can easily be undone, and the offending user will likely never see the return of his or her privileges. - Chardish 02:11, 23 May 2007 (UTC)

The definition of "strong" used here is "can be broken by a password cracker". If your password can be broken by a password cracker, it is not strong by any reasonable definition of the term. I'm not sure what your point is. -Amarkov moo! 04:32, 23 May 2007 (UTC)

[edit] My promotion of this page to policy

I saw no edits from May 19, and therefore it has been a week since the last edit. I thought that this has become stable enough to become policy. Please revert if there is any more controversy. Jesse Viviano 15:49, 26 May 2007 (UTC)

I still have my issue that there is no point, since the developers will do this whether or not we like it. But there's no reason that its being policy is bad, I guess. -Amarkov moo! 16:09, 26 May 2007 (UTC)
No problem with the text, but if we're going to officially promote it as policy, I'd like to see it moved to a more descriptive title, since it's not a general security policy. Perhaps Wikipedia:Administrator password security? Gavia immer (talk) 14:32, 29 May 2007 (UTC)
I don't think that's a very good title. You don't have to be an administrator to have a strong password. Acalamari 16:48, 29 May 2007 (UTC)
True, but I got the impression that the point of this page was saying that it is especially important that admins have strong passwords. -Amarkov moo! 23:14, 29 May 2007 (UTC)
I agree entirely, and so should bureaucrats and all the other user access levels (especially the priveleged levels), I just don't think that "Administrator password security" is a very descriptive title because it excludes all the other access levels. Indeed, administrators should have strong passwords, but so should everyone else. Acalamari 23:21, 29 May 2007 (UTC)
The page as it stands only requires strong passwords for users with elevated priveleges, though. In any case, I'm not married to my proposed title; I just think the present one isn't descriptive enough. If anyone has a better suggestion, I'll support it. Gavia immer (talk) 14:11, 30 May 2007 (UTC)
Wikipedia:Password security seems to be more accurate. But I don't see why this is policy, and not an essay. Our standards for desysopping insecure accounts and restoring access to breached accounts should be consolidated elsewhere. -- nae'blis 15:19, 30 May 2007 (UTC)
"Password security" is a a much better title than "security", and as Amarkov has pointed out, since the developers are going to this no matter what, making this policy does seem unnecessary. An essay makes more sense. Acalamari 16:16, 30 May 2007 (UTC)

(restore indent) Not that I'm trying to piggyback Wikipedia:Personal security practices to policy, but now might it be a good idea to consider "merging" or consorting concepts of the two pages? Problem is, it was never an intention of mine to make WP:PSPS policy, which is not to say it couldn't be, but there are a lot of good reasons why it shouldn't be, and I was initially interested in "guideline" status mainly to justify including links to the page on welcome messages to newbies.

Now that information on securing passwords appears on my log-in page every time I log in, which I assume happens for everyone, I think achieving "guideline" status for WP:PSPS is unnecessary if we could also get a similar practical admonition or "fair warning" note re: posting personally identifiable information on everyone's WP log-in page. I am more interested in basic awareness of personal security issues getting out to the general editing public than in arguing over policy vs. guideline vs. essay status of either of these pages. I've posted this suggestion to Jimbo's talk page but no one seems to have acted on it, and I am not sure how to move forward with this at this time.—AL FOCUS! 02:56, 31 May 2007 (UTC)

[edit] hack attempts/paranoia

I've recently started to receive emails containing "temporary passwords" to my WP login account. I beleive that these are what one gets if one checks the "I forgot my passord" box on the WP login page. As it happens, I haven't forgotten it, and someone else is making these requests. Being slightly paranoid, I am concerned that someone is hoping to catch one of these emails in-flight (they're mailed out in cleartext, so the temporary password is clearly visible), and is thus hoping to hack my account. Any recommendations on how I should deal with this?

The most recent request comes from 81.16.239.172 and dig-x shows 172.239.16.81.in-addr.arpa. 86400 IN PTR inet-81-16-239-172.lenet.lt. As it happens, "Linas" is a popular name in Lithuania (.lt) so it might be that some other Linas is hoping to capture my account. I'm not thrilled be the prospect of waking up one day to find my WP acount has been taken over. linas 00:01, 28 June 2007 (UTC)

Yeah, I've been getting the same thing on a monthly basis. I've thought about reporting it, but figuring that I have no credit card number to lose or social security number to be stolen, there is no reason for me to panic. The fact, though, that this is happening just bothers me. Is it even remotely possible that the password can be "stolen" as the e-mail is being sent out? If so, this would be bad. But again, the only thing that could happen is that some ridiculous edits could be made, your watchlist cleared, or your preferences toyed around with. Not too big a deal, but something to watch out for. └Jared┘┌t┐  00:08, 28 June 2007 (UTC)
There are about 8 or 9 SMTP forwarders between mchenry.wikimedia.org (where the email originates) and my mail server. If any one of these are compromised, the email could be read. Given the kinds of headlines on sees these days on security, it is prudent to assume that at least one of these probably is compromised. What is not likely, is that anyone is out to get me personally. Anyway, I've been told that the WP:AN/I is a good place to report this. linas 16:03, 28 June 2007 (UTC)

[edit] i forgot my password

Hello i supposed to be Mattress318 but i forgot the password and i want to know how to reset the password im sad send email to [redacted] how to reset password —Preceding unsigned comment added by 125.25.254.219 (talk) 08:30, 17 March 2008 (UTC)

Instructions on fixing this are at Wikipedia:Contact us/login problems - in short, the login page has a link to get a temporary password mailed to you. This requires that you confirmed an email for that account already; if not, you're out of luck. Note that I have removed your email address - posting it here is not a good idea. — Gavia immer (talk) 15:58, 17 March 2008 (UTC)