Jump to content

Wikipedia:Village pump (proposals)/Account security

From Wikipedia, the free encyclopedia
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This RFC is now closed. Issues can be followed up individually elsewhere, and, in the longer term, another RFC for a general review of these issues may be appropriate one day. Rd232 talk 21:06, 22 July 2011 (UTC)[reply]

Recent discussion about desysopping administrators after being inactive for a year (or other specified time) has once again arisen after an inactive admin account was suspected to have been compromised. This discussion has larger implications about account security on Wikipedia, however. A Signpost article from last August discusses a study on password security—in which researchers gave Wikipedia a score of 4 out of 10.

While many people are inclined to use bad passwords, such as "password" or "fuckyou", this only gives "hackers" easier access to an account without detection. It is therefore proposed that our current MediaWiki installation include additional features to increase the account security and password strength of its users. This page is meant to be a place where users can propose and/or comment on various methods of doing this, and the more popular proposals can then be presented to developers for assessment and, hopefully, then implementation.

Further reading: Wikipedia:User account security, meta:Don't leave your fly open, Wikipedia:Personal security practices. Please feel free to add proposals in a new section at the bottom and comment on existing proposals. /ƒETCHCOMMS/ 16:47, 3 June 2011 (UTC)[reply]

Improve password strength[edit]

Add a notice to the signup page about password strength[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
No consensus for both sections. -- DQ (t) (e) 18:49, 17 July 2011 (UTC)[reply]

We could easily add a notice summarizing how to pick a stronger password. It would not be as long as this article, but could present similar information.

  • Special:UserLogin already says, “If your password only contains letters or only numbers, please read our article on password strength and consider changing it (in Special:Preferences after you log in).” A. di M.plédréachtaí 12:23, 3 June 2011 (UTC)[reply]
  • Support including more hints, examples, notice. For many users clue has to be administered much more aggressively. Also support "password strength bar". —  HELLKNOWZ  ▎TALK 16:24, 3 June 2011 (UTC)[reply]
    Th@t s0unds g00d (That sounds good) ~~EBE123~~ talkContribs 22:10, 3 June 2011 (UTC)[reply]
  • How about an article in The Signpost? ~~EBE123~~ talkContribs 22:10, 3 June 2011 (UTC)[reply]
  • There already is a note on the signup page, and in general, more text == less reading by noob users. —TheDJ (talkcontribs) 23:14, 3 June 2011 (UTC)[reply]
  • Yet another thing for new users to ignore? Doesn't sound like a good idea to me. --Carnildo (talk) 23:40, 3 June 2011 (UTC)[reply]
  • If we have a bar showing password strength (the section above this one), it wouldn't make sense without a message explaining what it is. ▫ JohnnyMrNinja 14:52, 4 June 2011 (UTC)[reply]
  • Support The Helpful One 22:32, 5 June 2011 (UTC)[reply]
  • Not sure. At signup, password strength isn't a big deal (new accounts are low value), and bothering users with password strength may put some off. I'd prefer to auto-check password strength when users reach a certain threshold (say, 100 edits), and then notify them if the strength is not high enough, with a suggestion to improve it by checking against an indicator. (It could be done by the Special/login page, when they login next time after their 100th edit.) That said, a simple password strength bar, with a link to an explanatory page, wouldn't be too offputting, hopefully. Rd232 talk 22:50, 5 June 2011 (UTC)[reply]
  • I'm okay with this, but I really don't think that it's such a big deal. Most accounts are throwaway accounts: the user will make a few edits, and then go away. I don't object to giving them more information (an unobtrusive indicator), but I wouldn't make any new account use any password more complicated than "password" itself. Brand new accounts have almost zero value. WhatamIdoing (talk) 00:56, 10 June 2011 (UTC)[reply]
  • It should be pointed out that the note about password strength that links to our article on the subject is only linked from the login page, not the signup page. I would Support adding a note about it to the signup page as well. If the password strength bar is approved, the note should be next to that, otherwise it probably should be placed next to the password input fields. jcgoble3 (talk) 17:24, 15 June 2011 (UTC)[reply]

Test password strength for established accounts[edit]

We're worried about bothering newcomers with password issues - and new accounts' value is very low anyway. So why not wait til accounts reach, say 100, 500, or 1000 edits and then automatically test the password strength, and then notify them if it's not acceptable. It could be done by the Special/login page, when they login next time after their 100th edit, simply showing the password strength indicator analysis of their current password, with a brief note. This ought to gain most of the security benefits, without the downside. Alternatively, don't bother testing, just automatically send an email after the 100th edit saying "well done for contributing 100 edits, would you like to check your password strength against the indicator _here_"? Rd232 talk 17:28, 5 June 2011 (UTC)[reply]

  • Support - increases awareness and a gradual rate. Regards, SunCreator (talk) 02:38, 23 June 2011 (UTC)[reply]
  • Support There's enough things to worry about when starting, dealing with a strong password isn't one of them. Waiting until 100 or even 500 edits isn't going to be a problem.--SPhilbrickT 00:15, 26 June 2011 (UTC)[reply]
  • Support It sounds like this would help security and I don't see the downside. AndrewRT(Talk) 21:28, 3 July 2011 (UTC)[reply]
  • Oppose, give the feel that anybody at WMF/WP could read the PWs and send mails. I'm not really sure if this is technical possible since Mediawiki using/should use salt. So there have to be saved somewhere HOW secure the pw is. Also I don't think it is good to motivate the users even more how much (useless?) posts they have done (WP:EDITCOUNT). mabdul 22:23, 3 July 2011 (UTC)[reply]
  • Oppose, per Mabdul. --Nuujinn (talk) 22:27, 3 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Required verified email accounts[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
T32018 Option to make access to specific user rights or user groups dependent on having a verified email address. Rd232 talk 20:59, 22 July 2011 (UTC)[reply]

...for all registered users[edit]

Although Wikipedia currently allows email validation, but this is not not required in any capacity. Many websites require this before setting up an account, or before making changes to the account. This does not mean that users would need to be contacted by other editors, but rather by the MediaWiki software itself. Currently any automated messages or warnings like those mentioned above would only reach editors who both submitted an email address and still retain access to that account. This could be implemented as a strong suggestion for all users, as a requirement for user privileges, or even for starting an account.


Although I would personally support this, it will in part implede the WP's "anyone can edit" statement. So this should definitely not be required to create an account. Considering how many notices and warning we already have, I'm sceptical of requiring e-mail address just so more notices can be sent (as per proposals above). If anything, I would be discouraged to submit my e-mail. I a user just doesn't get a clue or care, no amount of e-mails will fix that. —  HELLKNOWZ  ▎TALK 16:39, 3 June 2011 (UTC)[reply]

  • Given that most websites ask for it already, I think that we should require that a user submit an email address upon registering. However, we should create a new option like "Allow others to send me email" or "Allow Wikipedia to send me system messages" or whatnot, so people who forget their passwords can still get a new one via email, but if they don't want to get email from other users, they don't have to. /ƒETCHCOMMS/ 16:59, 3 June 2011 (UTC)[reply]
    • Nobody say that you aren't able to edit as IP (so not logged-in), thus this argument isn't valid! mabdul 17:08, 3 June 2011 (UTC)[reply]
      • By no means should this be a requirement to edit, but it seems reasonable for account creation, and certainly for user rights. Unless it is possible that anyone who is using the internet enough to register an account would not have an email account. This would ensure that we can actually deliver warning messages. There is already a preferences setting to allow other users to email you. ▫ JohnnyMrNinja 17:26, 3 June 2011 (UTC)[reply]
        • I recently heard from a user, that he doesn't have an e-mail account. Armbrust Talk to me Contribs 00:42, 4 June 2011 (UTC)[reply]
          • I know some users don't have emails, but the number of those without them are very small now, I'm guessing (anyone got data on this?), and as IPs can edit, the inconvenience would likely be minor. What would be ideal is an in-MediaWiki private messaging system, but that's for another discussion. /ƒETCHCOMMS/ 01:43, 4 June 2011 (UTC)[reply]
  • Support, but let's start with accounts with extended user right and admins and see how it goes. --Nuujinn (talk) 23:54, 3 June 2011 (UTC)[reply]
  • Support, Nuujinn proposal is good!. mabdul 08:31, 4 June 2011 (UTC)[reply]
  • Support A means of verification would be a welcome change. —James (TalkContribs)10:24pm 12:24, 4 June 2011 (UTC)[reply]
  • Support (to be clear I added this heading to the RfC) - I just realized our sign-in says "You do not have to provide an e-mail address, but if you forget your password, you will not be able to regain access to your account without one." This is likely the reason that we have so many abandoned accounts. How many are just duplicates the owners lost the keys to? This will also likely decrease the number of vandalism-only accounts. I think it should be required for all new users and any accounts with rights, and heavily suggested for regular editors. This is not only an issue for WP security (as most accounts aren't very valuable to us), but also to help protect the individual accounts (which could very-well be valuable to someone). ▫ JohnnyMrNinja 15:43, 4 June 2011 (UTC)[reply]
    • Does this mean we then get into the business of blocking every temporary email account service out there? While it seems like a pretty painless good idea for reducing account abandonment slightly, I'm not sure this would have much of an impact on vandalism. Nevard (talk) 02:40, 5 June 2011 (UTC)[reply]
      • You may be right and it may have very little impact on vandalism, and I certainly don't think we should disallow any email service for any reason. I simply meant that it creates another hoop for a vandal wishing to remain anonymous, as they would have to create a fake email and then create a fake editor and then create the page "Steve Eats Poo". That is a very specific type of vandalism and likely not a major type, and that is not why I support this idea but rather a possible small benefit of it. Also I don't suggest using the email in any punitive fashion (though I assume CUs can see what accounts have the same address), just that vandals are less likely to commit vandalism knowing that they gave their real email address. ▫ JohnnyMrNinja 04:11, 5 June 2011 (UTC)[reply]
        • Ah, I was referring more to Disposable e-mail address services than webmail accounts. Nevard (talk) 06:09, 5 June 2011 (UTC)[reply]
        • AFAIK, CUs don't have the ability to see users' email address. Even if they did, we don't usually do CU on routine vandals unless there's an obvious pattern. Mr.Z-man 17:47, 5 June 2011 (UTC)[reply]
  • Weak oppose - Sometimes when a website asks for my email, I immediately abort creating an account. We need to encourage as many ip users as possible to create accounts. We don't even require sysops to configure an email account. Marcus Qwertyus 00:59, 6 June 2011 (UTC)[reply]
  • Oppose per Marcus Qwertyus. For a different wiki with a different culture (e.g., one that requires registration to edit), this could be a good idea, but here I think it will be counterproductive. --RL0919 (talk) 15:42, 8 June 2011 (UTC)[reply]
  • Oppose for registered users. An extra hurdle which isn't necessary at that point. Suggestion: One thought occurs - what about using a carrot instead of a stick? Could we give brand new users some slight advantage if they provide a verified email address? Perhaps reduce the auto-confirmed threshold from 4 days to 3? (Or perhaps better, up the standard to 5, and lower it to 4 for those who provide them.) Rd232 talk 19:32, 8 June 2011 (UTC)[reply]
  • Support new accounts having to register a verified email address. Nearly everyone who connects to the Internet has an email address. There are plenty of security benefits (and potential communication benefits) to this being registered with Wikipedia. Simple. ╟─TreasuryTagCounsellor of State─╢ 09:12, 9 June 2011 (UTC)[reply]
  • Oppose. Wikipedia already has a very clannish editor community. Impeding the ability of new users to register by requiring a verified email address would further exacerbate that problem. We need to make it easier to allow new editors to become established, not harder. elektrikSHOOS 20:53, 9 June 2011 (UTC)[reply]
  • Oppose Off-putting to new editors and irritating to people worried about spam. Fear of spam is a huge deterrent to many people. Besides, we'll just end up with hundreds of accounts whose verified e-mail address is spam@mailinator.com WhatamIdoing (talk) 01:06, 10 June 2011 (UTC)[reply]
  • Oppose I consider myself an established user yet until now I'm still not confirming my e-mail. There should be no need for this. And being able to be communicated with through e-mail should be the editor's choice. Moray An Par (talk) 12:18, 11 June 2011 (UTC)[reply]
    • There is a setting to turn off email communication with other editors, allowing you to provide an email address purely for purposes like password resetting. Rd232 talk 13:56, 11 June 2011 (UTC)[reply]
  • Comment - I don't care so much about existing accounts, but not requiring an email account could be one of the reasons we have almost 2x the number of unused account as used. Almost 10 million accounts have been registered but never made a single edit (even deleted). Granted, a large chunk of that is probably from WP:SUL, but still. Make an account at Wikipedia, forget your password, and it's gone forever. ▫ JohnnyMrNinja 04:13, 13 June 2011 (UTC)[reply]
it could be, but I think the absence of any strong desire to actually contribute is the more likely reason. DGG ( talk ) 21:20, 14 June 2011 (UTC)[reply]
  • Strong Support It's common bleeping sense. Practically every site out there now requires an email address; why not Wikimedia sites? As JohnnyMrNinja pointed out, it would help reduce the number of accounts that are created and abandoned because the password is forgotten. I would also support a modification to the blocking mechanism so that autoblocks would affect the user's email address in the same way they would affect the IP, except that an autoblock affecting an email would last until the main block expires or is lifted rather than just 24 hours. This, I'm guessing, would help cut down on socking. jcgoble3 (talk) 17:37, 15 June 2011 (UTC)[reply]
  • NO. Simply put, I don't think I would have created an account if an email was required. I'm cautious about giving my email to websites, and when I signed up I was just going to make a few edits (it obviously turned out to be a lot more than a few, but I may not have made any of them if an email was required). Further, just asking for an email is one thing, but if you then did the whole "send-email-with-code-you-need-to-enter-code-before-starting-to-edit" thing, it would be a major hassle. Why make it noticably easier to edit as an anonymous user? Don't we want people to create accounts? –Drilnoth (T • C • L) 15:57, 17 June 2011 (UTC)[reply]
    I totally agree with your position. Requiring e-mail addresses will just be an extra hassle and may discourage new editors. Moray An Par (talk) 12:55, 19 June 2011 (UTC)[reply]
  • Oppose - Unnessesary, no benefits. Add to email spam etc. Regards, SunCreator (talk) 02:39, 23 June 2011 (UTC)[reply]
  • Not helpful I think. Stifle (talk)
  • Oppose Unnecessary hassle, will not provide more then a minimal amount of extra security, at the expense of annoying new users. Monty845 16:09, 5 July 2011 (UTC)[reply]

...for autoconfirmed users[edit]

  • Comment: how about limiting autoconfirmed privileges to those who have provided a verified email address? That ought to be relatively easy, and avoids the obvious complaint about putting people off editing. There is a "Enable e-mail from other users" option, so doing this wouldn't force anyone to accept email from other users, only from the software under limited conditions (eg password reset). Perhaps would need combining with some kind of automatic notice when the other conditions are met but no email address has been given: "if you now provide an email address, you'll be able to move pages and gain some other privileges" sort of thing. Rd232 talk 17:05, 5 June 2011 (UTC)[reply]
    • That could cause a serious problem though, as autoconfirmed is automatic. They would either have to stop editing or we would have to change what an autoconfirmed user is. ▫ JohnnyMrNinja 17:21, 5 June 2011 (UTC)[reply]
      • I'm assuming the software would be changed so it would still be automatic, but dependent on the existence of a verified email address. And failure wouldn't mean they couldn't edit, it would mean not getting the autoconfirmed privileges. Rd232 talk 18:00, 5 June 2011 (UTC)[reply]
        • If it's technically achievable within mediawiki, I think this is a good approach. bobrayner (talk) 00:46, 6 June 2011 (UTC)[reply]
  • Oppose We don't need to have an e-mail address for a person to let them move pages, send articles to AFD, or do any of the many autoconfirmed-only activities. WhatamIdoing (talk) 01:06, 10 June 2011 (UTC)[reply]
    • We don't need to have an autoconfirmed threshold for moving pages etc either; but for various reasons it's a good idea. Similarly, there are various security and communication benefits for users providing an email address. Forcing them immediately (as per section above) would be bad, but requiring an address for those higher privileges is a pretty minimal requirement, and anyone that doesn't want can edit without. Alternatively, we could remove the "stick" element entirely and change it to carrot: eg, "give us a verified email address, and you can be autoconfirmed more quickly" (which would work best with raising the current threshold, since it's there for a reason). So maybe autoconfirmed no email address: 5 days, 15 edits; with email address, as status quo. Rd232 talk 14:02, 11 June 2011 (UTC)[reply]
  • Oppose per my comments both in the above section, and per WhatamIdoing's comment. elektrikSHOOS 20:37, 19 June 2011 (UTC)[reply]
  • Oppose This would represent a shift away from the concept of pseudonymous editing which the internet was largely based on a few years more closely towards the facebook-style real name editing. I know this is the way the internet is moving, but I worry that we may lose something in this change, particularly when people are editing on contentious areas they might not want their employers, for instance, to know about. AndrewRT(Talk) 21:32, 3 July 2011 (UTC)[reply]
    • What? This has no effect on pseudonymous editing whatsoever. A user with a verified email account doesn't need to make that public in any way, or even enable receiving emails from other editors. It's purely behind-the-scenes for notifications and password resets, and not even (AFAIK) accessible by checkusers etc. Rd232 public talk 22:09, 3 July 2011 (UTC)[reply]

...for admin etc accounts[edit]

As above, but applied to admin, bureaucrat, etc accounts. (Not mutually exclusive with the above, you can support both.)

  • Support. This is required for various of the other security measures about email notification to be really effective. Rd232 talk 19:24, 8 June 2011 (UTC)[reply]
  • Oppose. Given the stringent requirements already imposed by the community to achieve these positions, I don't see how requiring a verified email address would help anything at all. Why would this even be necessary? What is this preventing? This is a solution in search of a problem. elektrikSHOOS 20:35, 19 June 2011 (UTC)[reply]
  • Support, aids ability to communicate, it situation that it looks like account comprimised for one. Part of being a responsible admin. Regards, SunCreator (talk) 02:43, 23 June 2011 (UTC)[reply]
  • Support I have long supported this. It's pretty basic, for anyone who is in a position of authority. Anonymity is one thing, but people whom we are not even minimally sure have some real existence is another. Its a very weak standard, of course, but it's a first step towards proper responsibility. DGG ( talk ) 20:28, 28 June 2011 (UTC)[reply]
  • Well, support, but not for any security purposes, more because sysops should be accessible. Stifle (talk) 14:36, 1 July 2011 (UTC)[reply]
  • Support In contrast to my comments in the section above, I think trusted users like admins should be accessible and their identities known and verifiable (not to the wide world but to some). AndrewRT(Talk) 21:34, 3 July 2011 (UTC)[reply]
  • Comment While I think admins should have an working email that they check associated with their account, it is trivial to register a free email account that does nothing to identify the user unless they happen to use an email address with personally identifiable information in a context that indicates it is not another alias. Monty845 16:07, 5 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Annually reverify email accounts[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The proposal has not achieved consensus support. MER-C 03:48, 15 July 2011 (UTC)[reply]

Email accounts often become stale or go dead, but Wikipedia's email verification takes no account of this. So, on annual basis, some mechanism should ensure reverification of the email address. The email message asking for this will also be a reminder for those who have lost touch that they once edited and still have an account. Ideally, an email message would be preceded by some attempt to re-verify via an onwiki message ("is this email address still correct?"), and success would obviate the need for an email. But that would probably be considerably more complex to implement. An annual email message is pretty straightforward; and supplementing by an automatic user talk posting if there's no response within a set time ought to be straightforward too. Well, there are various ways of doing it, let's not get hung up on the how just yet. PS Benefits of this right now are limited to ensuring users don't lose the ability to reset their password, and that user-to-user emails to them don't go into a black hole; but various security measures proposed do depend on current email addresses. Rd232 talk 20:05, 8 June 2011 (UTC)[reply]


Comment - Technically how would you do this? You'd send a reconfirmation email. What if they didn't get it? Nothing, becuase many would get it and not act. So would you close accounts on those that didn't renew? I doubt that would be sensible. So I think this idea would become unworkable. Regards, SunCreator (talk) 02:46, 23 June 2011 (UTC)[reply]

    • The reconfirmation email would have a clickable link, same as the current email sent to verify an email address. If the user doesn't click the link within a certain time frame, the "verified" status of the email address is removed. That's the basic idea; what exactly you make dependent on having a verified email address is a separate issue. I'd suggest admin and higher rights should be suspended if there isn't one; maybe lower rights too (rollback etc, but not autoconfirmed or even editing). Currently, I think it's just email access (send/receive) which depends on having a verified address. PS stating the obvious, but if an address is "unverified", there won't be any more reconfirmation attempts in future, so that people who don't want to bother don't have to. Rd232 public talk 20:14, 1 July 2011 (UTC)[reply]
  • Not support. Most email providers which are used: GMail, Yahoo!, MSN, aol, live.com ... and was it nearly. see stats at the account creator tool. I doubt that any of them will be closed. So this would care only a really small minority. mabdul 18:28, 1 July 2011 (UTC)[reply]
    • It may be that many of these accounts don't die, but people do stop using them (for one thing, people die), and therefore future emails to them are lost in the ether; unverifying email addresses would prevent people sending emails to people who probably won't get them. More importantly, some of the security measures proposed in this RFC depend on people (at least admins) having currently being read email addresses listed. In addition, an annual reminder might bring a few editors back. Rd232 public talk 20:14, 1 July 2011 (UTC)[reply]
      • That doesn't make sense! If a user lost his password he will can check his ORPHANED mail account (because he uses always the same password) and get access to his wikipedia account. The easiest way posting the template "you've got a mail" template and then the mailed user checks either the mail address(in the prefs) or his mail account to get the mail. Also: what has this to do with increasing security? With/out/removed a verified mail address there is no win of security. mabdul 22:00, 5 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Dealing with dormant registered accounts[edit]

Given that the English Wikipedia currently has 47,551,072 registered users, most of whom are inactive, how will we—or will we at all—deal with the security of these dormant accounts?

  • It would be really nice if there were data on these users; as in how often do editors actually return after years away? If the answer is that 90% of autoconfirmed editors who have not logged in for 3 years or longer don't return, we could remove the auto-confirmed status. But how much damage can a regular editor cause? If an account made 300 edits and left 4 years ago, and that account is compromised, what's the big deal? Either the new editor is a vandal or not, but it is similar to a new account. ▫ JohnnyMrNinja 12:41, 3 June 2011 (UTC)[reply]
  • Accounts are free. Why do we care about ordinary accounts? They really can't do anything beyond what you get from registering a new account and passing the very minimal autoconfirmed barriers, so there is no incentive to attack these accounts. Obviously accounts with elevated user rights are a different case, but such accounts are much rarer and don't require thinking about the horde. Dragons flight (talk) 14:50, 3 June 2011 (UTC)[reply]
  • Oppose, with the caveat that if we do not do some kind of confirmation on renewed activity we may wish to revisit this issue. Johnny's point is well taken, esp. given that we allow IPs to edit freely in most areas. --Nuujinn (talk) 12:35, 4 June 2011 (UTC)[reply]
  • There's no benefit to the hacker to hack an inactive account with no rights. Even if the account is autoconfirmed, the effort required to find an inactive autoconfirmed user with a weak password or do a brute force attack on one is likely far more than the effort to just create an account and get it autoconfirmed. Mr.Z-man 15:29, 4 June 2011 (UTC)[reply]
    • That's not entirely true. Hacking an old account with a long history of good edits does have a benefit compared to starting a new account. On that basis, we could consider treating inactive accounts with say 1000+ edits differently. Unfortunately, I'm not sure what could practically be done. Rd232 talk 17:10, 5 June 2011 (UTC)[reply]
      • The benefit would still be only slight. If someone is applying to RFA, they'll still be expected to have several months of recent activity. They might be able to use it to vote in ArbCom or board elections I suppose, but those are also highly scrutinized. Mr.Z-man 21:49, 5 June 2011 (UTC)[reply]
        • Well, yes, those are some risks which are low. But (WP:BEANS alert...) what I had in mind was that control of an account with 1000+ edits would make a much better start for a determined socker than a new account. We might well argue that's less of a security issue than gaining control of an admin account, which is true; but we can hardly say it's non-issue, given the amount of time and effort that goes into combatting socking. However, unless anyone has any plausible countermeasures specific to such accounts (the general security-raising efforts will help), this is moot. Rd232 talk 22:38, 5 June 2011 (UTC)[reply]
    • The notification of resumed activity proposal above would help. It might also make sense to flag newly revived account in watch lists and recent changes, perhaps with a different color or the word "revived," for some number of edits.--agr (talk) 20:46, 7 June 2011 (UTC)[reply]
      • A simpler one to implement (though less effective in terms of getting attention of other users) would be a bot going around leaving "you've been away for a year: welcome back!" notices on returning users' talk pages. Rd232 talk 11:57, 9 June 2011 (UTC)[reply]
  • Comment - While it isn't related to security, I was thinking that if "last login" info were enabled, we would be able to see how many of the accounts that have never made a single edit also haven't logged in recently. If there is a significant number of accounts that have not logged in in 2 years, and have never made an edit, they could be deleted. I don't know if that is necessarily desirable, but it would free up usernames and make SUL easier, and give people a more realistic idea of our user-base. If there are only like 500 it wouldn't be worth it, but with the lack of email verification I'm willing to be it is far more. However, this isn't even possible with our current software, just something to think about. I brought up the feasibility of access to login information here at VPT, in relation to the "inactive admin" discussion. ▫ JohnnyMrNinja 17:00, 10 June 2011 (UTC)[reply]
  • Because of SUL we need to change our definition of dormant to being across the whole of Wikimedia. If someone is highly active on Commons and Bangla wiki their dormant presence on a couple of hundred other projects is a completely different issue than if they were dormant across the whole of Wikimedia. Also we need too do some research on these dormant accounts, what proportion do come back after long and very long gaps? How many are people who have registered to support and are waiting to be given something to do? How many support us with cash not edits? We need to understand how large these groups are before we consider discarding them. ϢereSpielChequers 07:02, 13 June 2011 (UTC)[reply]
Subject to further research on these accounts, it strikes me that the prudent thing to do would be to reset all user rights (autoconfirmed, voting rights etc) to zero-edits after, say, 2 years. AndrewRT(Talk) 21:23, 3 July 2011 (UTC)[reply]
I would support this except the autoconfirmed status: why forbidding moving pages and creating new ones? The "right" is gained after 10edits/4days. How regaining this after "reactivating" the account? mabdul 21:42, 17 July 2011 (UTC)[reply]
  • REQUEST: Are there any statistics or surveys how many accounts will be reactivate? (and after which time) mabdul 21:42, 17 July 2011 (UTC)[reply]

Email notifications[edit]

Notify users after renewed activity[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Entered into Bugzilla for developer consideration, see bug 29857. MER-C 03:56, 13 July 2011 (UTC)[reply]

First proposed here, an email could be sent to a user if his/her account began editing after a certain period of inactivity (several months, a year, etc.). This would welcome back users, but also let them know if someone else is accessing their account.

  • Goes hand in hand with the proposal just above. This is a good idea, and should definitely be enabled. It should be a simple "Welcome back to Wikipedia!" note, and not a "You were sure gone a while... so you're probably a hacker." Also, the amount of good this will do will be limited to the number of editors that attach email accounts. ▫ JohnnyMrNinja 12:32, 3 June 2011 (UTC)[reply]
    • I don't think this should be something that can be opted out of or set to a user-defined length. This is people planning for the times that they will not be here, which doesn't make sense. I can't imagine a scenario where user-defined settings for this would be desirable. There is no way that having it on would genuinely upset any editor, as the email would be so infrequent, and it would welcome them, which is a good thing. "Every time I take a break from Wikipedia for three months or more they send me an email saying 'Welcome back!" upon my return and it is driving me crazy!!!!!" If they could change the length manually, what would they set it for and why? If you take month-long vacations, would you set it for 1 month, or 2, or three weeks? It'd be arbitrary. I know wiki editors like control, but user-control is not desirable for this feature and should not be implemented. ▫ JohnnyMrNinja 17:35, 5 June 2011 (UTC)[reply]
  • Support, very good idea, but I would suggest only doing this for editors with 1000+ edits and admins initially. Since IPs can edit freely, seems of limited value to accounts that are seldom used. --Nuujinn (talk) 23:39, 3 June 2011 (UTC)[reply]
  • Support, 1000+ as Nuujinn described. mabdul 15:20, 4 June 2011 (UTC)[reply]
  • Support for 1000+ edits. The "Welcome" email could contain suggested links to review policy and editing, too. Mamyles (talk) 23:02, 4 June 2011 (UTC)[reply]
  • Support - was my idea :). 1000+ seems a fair threshold. Note that my proposal originally included the point that the facility and the time period would be adjustable in the user's preferences; I guess this is taken as read. Also it should be on by default. Rd232 talk 17:17, 5 June 2011 (UTC)[reply]
    • Though JohnnyMrNinja makes a fair point that adjustability isn't strictly necessary - at least if the time period is long enough (3 months+ perhaps). The reason I was suggesting adjustability is that I was thinking some users might set it considerably lower - like a week. Since the security benefits are particularly from a small number of highly active users, adjustability helps maximise those benefits. Rd232 talk 18:47, 5 June 2011 (UTC)[reply]
  • Support - 1000+ edits, admins, but not users that aren't auto-confirmed - waste of resources. The Helpful One 22:35, 5 June 2011 (UTC)[reply]
  • Support; I can't think of a reasonable downside. 1000 edits seems slightly high to me - I'd prefer 100 or so - but I could live with it. bobrayner (talk) 00:41, 6 June 2011 (UTC)[reply]
    • Well, someone actually implementing this would probably conclude that the edit threshold is best left up to the user, along with the time threshold. Default values could actually probably be lower than the 1000 we've been talking about; most users don't get up to 1000 very quickly, if at all. So default could be perhaps 100 edits and 3 months. Rd232 talk 19:48, 8 June 2011 (UTC)[reply]
  • Support 1000+ prior edits and a long break (or even sending it on the second renewed edit) might be a reasonable starting point, but if this gets people to come back more often, I'd be happy to have those thresholds decline to whatever point is likely to win us more editors. Happy, welcoming messages only, and I'd be happy to see the message suggest either articles that they might be interested in, or simple edits that they might like to help out with (perhaps rotating through things like stub sorting, common spelling errors, orphaned articles, or things like that). Prefs could have an opt-out box. WhatamIdoing (talk) 01:14, 10 June 2011 (UTC)[reply]
  • Support. עוד מישהו Od Mishehu 08:18, 20 June 2011 (UTC)[reply]
  • Support. I can see no risks with this. The email should basically just welcome users back, but should end with instructions what to do if one did not actually log into the account. Hans Adler 09:43, 21 June 2011 (UTC)[reply]
  • Support This looks like a very good idea, but I agree with others that this should probably only be implemented for users with quite a few edits. Captain panda 15:57, 28 June 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Notify of removal of verified email address[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Entered into Bugzilla for developer consideration, see bug 29856. MER-C 03:38, 13 July 2011 (UTC)[reply]

Currently, an email is only set to an email address when it is added to preferences - in order to verify access to that account. This means that a hijacker can remove or replace a verified email address without the owner being aware of it. So when an email address is removed or replaced, an email should be sent to the old address (if it was verified) simply notifying the owner [the verification code email would be sent to the new email address, if one has been provided - after all it's the new address being verified]. This shouldn't happen so often as to be an annoyance issue, and it's a significant security benefit. (Of course, that doesn't apply if the address is dead or unused, but you can't have everything. And the "desysopping if inactive" proposal at VPR covers a lot of the most important part of that ground.) Rd232 talk 17:56, 5 June 2011 (UTC)[reply]

  • Comment: Only a information or plus a new "verification" code? I'm not a fan of sending new verification codes (to old mail-addresses) since I was multiple times in the situation that my free mail vendor(s) shut down. mabdul 18:35, 5 June 2011 (UTC)[reply]
    • Only notification. I don't see the point of sending a verification link to the old address in addition to the new one. The only value I could see might be in sending a link in the notification which would allow a reinstatement of the old address, overriding the removal even after verification of the new address. The link would be active for a limited time (1 week?) and would allow a hijacked user to regain access by reinstating the old email address and then asking for a password reset. Rd232 talk 18:40, 5 June 2011 (UTC)[reply]
  • Support. Reasonable measure to detect some (not all) forms of account compromise, at minimal cost. Forget about using it for verification - the average person on the internet has a certain amount of inertia over email accounts, and changes tend to be a "distress purchase" - because the user can't remember their Hotmail password or they just lost their job, so expecting verification via the old account simply won't work. bobrayner (talk) 00:50, 6 June 2011 (UTC)[reply]
  • This is a good idea; no verification codes, though (the main reason I foresee someone changing their email is because they lost access to the old one!). /ƒETCHCOMMS/ 16:09, 6 June 2011 (UTC)[reply]
  • Support, very good idea. I wonder if a confirmation email for any change in prefs might be worthwhile. I use a couple of web sites that do this. --Nuujinn (talk) 22:50, 6 June 2011 (UTC)[reply]
    • What other preferences would be worth the bother on Wikipedia? I can see it being an issue on Facebook say, where somebody could change privacy settings. Rd232 talk 23:00, 6 June 2011 (UTC)[reply]
      • I'm thinking of it as a string on a tin can--if someone does gain access to my account, let's say, and changes any pref, I'd know someone was mucking about (since I only rarely change prefs). --Nuujinn (talk) 22:11, 7 June 2011 (UTC)[reply]
        • Well, OK, I see. The only thing is that the proposal as stands (notifying on email change) doesn't require any per-user configuration; this won't happen often enough to need turning off. Your version would need a preference option to turn it off, besides needing to monitor all preference options and provide an additional sensible message. I wouldn't oppose it, but given the severe limitations on developer time, I wouldn't prioritise it very highly. Rd232 talk 15:39, 8 June 2011 (UTC)[reply]
  • Support for notification (but not verification). A reasonable way to alert users if something fishy has happened with their account, and totally harmless if the change was intentional. --RL0919 (talk) 15:33, 8 June 2011 (UTC)[reply]
  • Support users are unlikely to change their email addresses frequently so this should not annoy users. If their is an option to turn this off the user should also be notified of this change. MorganKevinJ(talk) 18:22, 8 June 2011 (UTC)[reply]
  • Support per above. Simple and reasonable way for users to be told when something has happened that they should be aware of. jcgoble3 (talk) 17:46, 15 June 2011 (UTC)[reply]
  • Support as notification only, or even as notification+an opertunity for cancelation; it should not be used for verification, as such a change may e the result of an already discontinued e-mail address. עוד מישהו Od Mishehu 08:20, 20 June 2011 (UTC)[reply]
  • Support. Of course the old address cannot be used for verification as it will often be no longer under control of the user. I am also not sure that it should have any code that permits getting control of the account, as the email address may well be under control of someone else. (E.g. email provider shuts down, domain gets sold, and new domain owner sells all such notifications to spammers.) Hans Adler 09:51, 21 June 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Suspicious account activity monitor[edit]

Drawing on the behaviour Gmail has [1], we could have a suspicious account activity monitor, warning users when there is something that looks suspicious, based on IP login history. This is probably not easy to do, and may require considerable resources (in which case limiting to admin accounts would be an option), but it would certainly help - especially against the threat of silent abuse (a hijacker making no edits). Silent abuse might be considered harmless - but it isn't, because for admin accounts it allows undetected access to deleted material, which per WP:Viewdelete is a Bad Thing. It might also help detect cases where a hijacker doesn't edit immediately, because they're waiting to use the account for a particular purpose, or just waiting for a good time; but they would surely be logging in at least once, to confirm they have access. Rd232 talk 21:00, 5 June 2011 (UTC)[reply]

  • If possible, MediaWiki should display on the right-after-log-in-screen a little box that shows the IP address from where the account last logged in, within a certain time limit (a month?) /ƒETCHCOMMS/ 02:50, 6 June 2011 (UTC)[reply]
    • That would probably not be much use except to techies with a fixed IP that they know. Even if you display both last IP and current IP, interpreting the significance of the difference is non-trivial for the average user. There's a reason Gmail does it the way it does. Rd232 talk 03:03, 6 June 2011 (UTC)[reply]
      • That's true, specifying the location rather than the actual IP (I think that's what Gmail does, from the picture in the linked article) would be more helpful to the average user. If it's possible to implement, though, I think this is a good idea. /ƒETCHCOMMS/ 16:08, 6 June 2011 (UTC)[reply]
        • How about adding Geolocation support that? (With a notice maybe for Opera Mini and similar proxies) mabdul 20:32, 8 June 2011 (UTC)[reply]
  • This is one of those ideas that I consider a positive security measure, but low priority. I'd much rather developers focus on some of the other suggestions. But if someone has a particular hankering to create this feature and does, it would be a reasonable thing to implement. --RL0919 (talk) 15:38, 8 June 2011 (UTC)[reply]
  • Support. It is low priority though and this seems only for check-users. ~~EBE123~~ talkContribs 20:04, 27 June 2011 (UTC)[reply]

Limit viewdeleted rights for admin accounts[edit]

One of the biggest concerns that's cropped up, and hardest to combat, is a compromised admin account being used to view deleted materials (cf Wikipedia:Viewing deleted articles), without doing any damage that would give away the security breach. The VPR proposal on suspending admin rights (Wikipedia:Village_pump_(proposals)#Suspend_sysop_rights_after_1_year_of_inactivity) helps, but maybe more can be done.

Proposal 1: make viewdeleted rights (including or perhaps separately RevisionDelete) an admin-specific preference setting, and generate an email when the setting is activated. Per "email notification" proposals in this RFC, this would be an email to the legitimate account owner (if the hijacker changes the email address, the old email address would get notification of that change). Leave the setting off by default (to cover inactive accounts not around to deactivate it when the software change is made, plus maybe some admins don't use the rights anyway).

Proposal 1a: when an admin hasn't logged in for a while (1 month?), switch the preference setting to "off" the next time they log in, with a message to that effect. A hijacker can turn it on, but per Proposal 1 that will generate an email.

Rd232 talk 11:50, 9 June 2011 (UTC)[reply]

  • I think this is a little overkill. The only way I can think it working efficiently would be a Proposal 1a-type setup, but it's sort of an inconvenience either way. Viewdeleted is a pretty frequently-used ability for most, if not all admins (well, at least it is to me :P). As an active admin account with that userright enabled could still be hacked, I don't think trying to control viewdeleted will have a big impact. /ƒETCHCOMMS/ 23:24, 10 June 2011 (UTC)[reply]

Technical issues[edit]

Have MediaWiki encrypt password transmission by default[edit]

This was also proposed in the password study. Currently, MediaWiki does not encrypt the password when logging in on the non-secure server. There is code for this but is not currently enabled on WMF sites.

  • Not sure if this does anything. As far as I know, these kinds of features only submit the password securely once (upon login), but then continue w/o encryption. Choyoołʼįįhí:Seb az86556 > haneʼ 05:39, 3 June 2011 (UTC)[reply]
    As I understand it, logging on to a secure server means that passwords aren't transmitted as plaintext, which means they can't be easily read with packet sniffers. I for one think this change is long overdue: does anyone know if there is there a technical reason why it hasn't been implemented?  -- Lear's Fool 06:56, 3 June 2011 (UTC)[reply]
    True, but this wasn't the proposal of the section: this section proposes that passwords will encrypted upon login over the non-secure server. And that wouldn't help much, unless the system stays on the secure server for the duration of the entire session. No? (or maybe I completely misunderstand what this idea is about...) Choyoołʼįįhí:Seb az86556 > haneʼ 07:40, 3 June 2011 (UTC)[reply]
That's not correct: After login, the password isn't transmitted again and therefore (as Preibusch, the University of Cambridge security researcher, points out in the Signpost article) encrypting the password on login would make a big difference.
On login, a cookie is set and transferred instead of the password on later connections. This is still vulnerable to the type of attacks recently highlighted by Firesheep, but at least their effect is restricted to the duration of one browser session, and the attacker doesn't learn the actual password (which he could try to use on other sites - think of a victim who has also OTRS access), and can't change it directly.
It should be noted that the code submitted in rev:75585 would at the moment still need more work to be integrated on Wikimedia sites, because it assumes that the secure (HTTPS) and insecure (HTTP) servers are on the same domain, whereas currently the secure server is on secure.wikimedia.org instead of en.wikipedia.org. But this problem should become obsolete very soon with the major overhaul of HTTPS access that Ryan Lane and other Foundation staff are currently working on (earlier announcement), - after this, https://en.wikipedia.org/ will be available.
Regards, HaeB (talk) 09:01, 3 June 2011 (UTC)[reply]
Oh, ok. Well, if that is so, then it's a good idea. Should be done. Choyoołʼįįhí:Seb az86556 > haneʼ 13:09, 3 June 2011 (UTC)[reply]
  • What would the downside of this be? ▫ JohnnyMrNinja 12:28, 3 June 2011 (UTC)[reply]
    • Session cookies would leak, and accounts could still be compromised just as easily as if login was done over HTTP. [stwalkerster|talk] 16:43, 3 June 2011 (UTC)[reply]
      • That's not actually a downside though is it. It's not a problem to block one hole in a leaking bucket because there is other holes in it! Regards, SunCreator (talk) 02:48, 23 June 2011 (UTC)[reply]
  • The idea is not bad. But requiring secure login would create a lot of compatibility issues and break most API users (read: bots). Changing API login to require token broke all bots, and even though it was an easy fix, some bots still don't work. Implementing secure connection would be much less than trivial. So doing this "by default" wouldn't be a great idea. But not doing this by default is how it works now -- HTTPS is optional. I would want to see more details on how this would be implemented and what this would mean. —  HELLKNOWZ  ▎TALK 16:33, 3 June 2011 (UTC)[reply]
    • HTTPS for the API is a good idea anyway. Most languages probably have an SSL thing to handle the HTTPS bit anyway, so the change should be near trivial, much like the token. If bots still aren't fixed from the token login change, then IMHO they probably ought not to still be running anyway, cos they're obviously unmaintained. [stwalkerster|talk] 16:43, 3 June 2011 (UTC)[reply]
  • Go with it! Passwords should be encrypted at all times. That is what I think. ~~EBE123~~ talkContribs 22:06, 3 June 2011 (UTC)[reply]
  • I believe this is already in the planning. Reworking much of the current secure setup was planned for 'somewhere after the new datacenter opens', but I believe now that there has been a little delay on that, that some of the sysadmins are already working on preparing the infrastructure for this change (as well as IPv6 support). —TheDJ (talkcontribs) 23:17, 3 June 2011 (UTC)[reply]
    • That is good to know, and the sysadmins would have to be our guide on this issue as SSL is something expensive computationally, and the systems would have to be able to handle increased load. --Nuujinn (talk) 12:38, 4 June 2011 (UTC)[reply]
  • Why not? Support! The Helpful One 22:33, 5 June 2011 (UTC)[reply]
  • Support; definite security benefits from this proposal. bobrayner (talk) 00:38, 6 June 2011 (UTC)[reply]
  • Yes, can't be bad. --m:dferg 19:20, 07 June 2011 (UTC)[reply]
  • Strong support Making an effort to get users to pick stronger passwords makes little sense until this is in place.--agr (talk) 20:48, 7 June 2011 (UTC)[reply]
  • Seems like a reasonable thing to do when the infrastructure is in place. --RL0919 (talk) 15:18, 8 June 2011 (UTC)[reply]
  • Support. What's not to like? However I get the impression that this is kind of in (slow) progress already, so there's not much point in discussing it. Rd232 talk 19:43, 8 June 2011 (UTC)[reply]
  • Support. —James (TalkContribs)5:34pm 07:34, 10 June 2011 (UTC)[reply]
  • Support for obvious reasons. elektrikSHOOS 20:40, 19 June 2011 (UTC)[reply]
  • Support, The downside of this could be that it makes people feel the account is secure when it is not. But I feel it's good to block one hole in a leaking bucket . Regards, SunCreator (talk) 02:03, 23 June 2011 (UTC)[reply]
  • Support, a step in the right direction (I'm pretty sure Wikipedia is the only top-10 website which does not support HTTPS). Also, the login page itself should be in HTTPS to avoid man-in-the-middle attacks (and that would require secure access to the geoip server, or no geoip on that page). --Tgr (talk) 18:28, 28 June 2011 (UTC)[reply]
  • Support, although I'm using normally the secure variant ;) mabdul 22:28, 17 July 2011 (UTC)[reply]

Minimum standards for password storage[edit]

in light of the Sony fiasco, I'd like to know if passwords are handled properly by our software. They should never be saved as plaintext. Any variable used for temporary storage of plain text passwords should be zeroed out when no longer needed, not just released to the memory pool. Passwords should be hashed with a standard hash function (e.g. SHA1 or SHA 512) and at least 32 bit of salt should be appended. There should be a version number with each hash value so improved algorithms can be introduced. i'd like to see key stretching employed, at least for privileged users. Can anyone familiar with the code comment or point us to the source code?--agr (talk) 21:19, 7 June 2011 (UTC)[reply]

mw:Manual:User table documents the current MD5/hash approach. T30419 aims to replace MD5 with WHIRLPOOL. This is for the main MediaWiki code; there is also mw:Extension:SecurePasswords which I think is "ready to go" if we want it installed (going by T18435 "New extension to enforce minimum password strength" and the final comment at T27925, "increase $wgMinimalPasswordLength"). Rd232 talk 15:55, 8 June 2011 (UTC)[reply]

Some other bugs:

  • T22185 - "Changing your email address should require entering your password" (to prevent session hijacking permitting an email change)
  • T28227 - "Notify user by email when password changed"
  • T11838 - "Send notification to account owner on multiple unsuccessful login attempts"
  • T22187 - "Encrypted login with JavaScript to reduce password-sniffing risk for HTTP sites"
  • T17876 - "Special:ChangePass: move password change form from Preferences, and add reset/usurp features"
  • T11816 - tracking bug (discussion about improving login security)
    • I gather from this that MediaWiki does not currently employ any throttling on login attempts [beyond requiring captcha after 3 goes, which isn't mentioned there]. Anyone know better?

Rd232 talk 16:14, 8 June 2011 (UTC)[reply]

That's very helpful. It looks like they are thinking about serious improvements to the hashing scheme. It apparently already has versioning and uses 31-bit salt, which is fine. I do think they should implement iterated hash and include the iteration count in the password record, in the same way they include the salt. This would allow for future improvements and higher security for privileged accounts. This might also provide a context for suspending inactive accounts. Accounts can be updated to a new stronger hash only when a user logs in. Once a stronger hash is introduced, and a reasonable time has passed, privileged accounts could be suspended if they have not been upgraded. One other thing, it might be useful to keep a count of failed login attempts, with some combination of globally, per user and geographic source.--agr (talk) 23:48, 10 June 2011 (UTC)[reply]
  • Support/Comment, imagine a situation of everyones WikiPedia account being comprimised. Regards, SunCreator (talk) 02:51, 23 June 2011 (UTC)[reply]

Remind admin/crat/CU/OS accounts to change their passwords regularly[edit]

The following discussion has been closed. Please do not modify it.

A system could be implemented in which accounts with elevated privileges (admin, crat, CU, OS, etc.) would either be reminded or required to change their passwords regularly (every few months?). This would minimize inconvenience for "regular" users but add an extra level of security for the accounts privy to the most sensitive information or most "powerful" abilities.

  • Skeptical. Some universities and other places require this, and it's a headache; I never understood what this would do. If my password is strong already and has never been cracked, why should I mess around making up a new one every so often, and thereby elevate my chances of forgetting it or having to write it down somewhere? Choyoołʼįįhí:Seb az86556 > haneʼ 05:43, 3 June 2011 (UTC)[reply]
  • Agree with the above user. My university requires this, and it is a complete pain to have to come up with and remember variations of my already strong passwords every few months. The keys are the strength of the password and the security with which it is transmitted to the server, not how often you change it.--Danaman5 (talk) 13:06, 3 June 2011 (UTC)[reply]
  • Required password changes aren't very good for the reasons listed above: my university also had such a system and it was completely ineffective. If your password was simply password, the three month thing would come around, and you'd change it to password1 and then back to password. Then they made it so that you couldn't have it as any of your last five passwords, so you'd change it five times, then back to the original and so on. This is silly. It also punishes those who actually have set a strong password: if I have a 25+ character password with numbers and characters and everything, why should I have to change that every so often to satisfy some stupid server requirement, while some dolt is keeping his as password1 or whatever. —Tom Morris (talk) 16:27, 3 June 2011 (UTC)[reply]
  • Very bad idea. This is some of the worst advice on passwords among all that is out there. It only makes sense for things that are so important that you can afford sending people to a 1-week course on password strategies and allocate substantial time for password maintenance. If you don't believe me, read this for some explanations. Hans Adler 17:20, 3 June 2011 (UTC)[reply]
  • This does not increase security, it reduces it by discouraging strong passwords. --Carnildo (talk) 23:37, 3 June 2011 (UTC)[reply]
  • Oppose, it is better by far to require a strong complex password these days and never change it, per reasoning above and recent research. The more often we require a change, the less secure the average password will be. --Nuujinn (talk) 11:39, 4 June 2011 (UTC)[reply]
  • Oppose per all above. Only thought coming out of this proposal is possibly having a regular (annual?) check of such accounts' password strength, and emailing them if the strength is not up to snuff. Except that's probably not worth the bother, assuming other ideas relating to password strength (in this RFC) are done. Rd232 talk 17:12, 5 June 2011 (UTC)[reply]
  • Oppose; requiring frequent changes of password tends to degrade password strength. If we're going to ask our users to put more effort into passwords it should be about increased complexity rather than regular changes, because the former offers much more protection against attack than the latter. bobrayner (talk) 00:44, 6 June 2011 (UTC)[reply]
  • Oppose A vandal will use a compromised password on an inactive account as soon as they get it. Requiring periodic changes locks the barn long after the horse has gone.--agr (talk) 20:40, 7 June 2011 (UTC)[reply]
  • Oppose because this doesn't really increase security, for the reasons articulated by others above. --RL0919 (talk) 15:26, 8 June 2011 (UTC)[reply]

Meet me halfway-type proposal[edit]

Overkill in the detail, and mixing different proposals isn't really helpful
The following discussion has been closed. Please do not modify it.

Wikipedia's account security is deplorable in comparison to the other major websites. This is an amalgamation of some of the above proposals to allow for less clutter and centralised discussion.

  1. On the signup page there should be:
    A password strength bar
    A tick next to the confirm password field to see if both passwords match
  2. Upon registration an email should be sent requiring verification
  3. After verification, the account can be used, if not verified after a week the account is deleted to free up space
  4. Upon 2 failed login attempts an email will be sent to the email of the account's owner (the user can still have the email user function turned off, but the software will still be able to email the user)
  5. After the third failed attempt CAPTCHA will be enabled for all subsequent attempts
  6. Upon 5 failed attempts the account will be locked for 24 hours and an email will be sent to the account's owner
  7. In that 24 hour period the software should fail to recognise all login attempts regardless of whether or not they are successful
    There will be a notice with the text, "Your account has been locked for <TIME> to prevent account theft" so that users who haven't checked their emails.
  8. Three subsequent failed login attempts (directly after the prior lock has expired) will result in a 48-hour locking period, which will be the default amount given thereafter.

Thoughts? —James (TalkContribs)2:09pm 04:09, 5 June 2011 (UTC)[reply]


Wikipedia's account security is low compared to other sites because for 99.9% of accounts, there is nothing of value that could be obtained by hacking them. If you hack an account of someone without any advanced rights, you're not going to get access to any personal communications, financial details, personal information other than email address, or access to any part of the site that you couldn't get just by creating an account. And unless you hack an account with CU/OS, you can't cause any lasting damage. With a regular admin account, anything obvious is going to get you blocked/desysopped in minutes. The most you could do would be to be like Archtransit and just barely break the rules once in a while, until you slip up, get caught, and everything you did is undone. I think 6–8 are overkill for Wikipedia and are also potentially exploitable. Someone with no real intention of hacking an account could use it to lock someone out of their account practically indefinitely. Mr.Z-man 16:00, 5 June 2011 (UTC)[reply]

  • Similar to Mr. Z-man: 6-8 are overkill and 4 also: what happens if the user edited already? got the account also deleted? mabdul 16:43, 5 June 2011 (UTC)[reply]

Enable openID?[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
No consensus, especially for such a change. The bugs for this proposal are bug 9604 and bug 13631. MER-C 04:03, 15 July 2011 (UTC)[reply]

The proliferation of passwords is already a fairly enormous problem. What are the technical barriers to enabling openID on the Wiki, so that people don't need to log in? Stackexchange and Mathoverflow use such a login mechanism, and it's both easy and makes security somebody else's problem (in this case, the openID provider's). RayTalk 10:41, 22 June 2011 (UTC)[reply]

That was suggested by the people who did the password study, I think, but I'm not familiar with how that would be implemented (would they still have to create a separate WP account, which would be logged?), and heaven knows how weak some people's MySpace passwords are. /ƒETCHCOMMS/ 04:55, 24 June 2011 (UTC)[reply]
Comment. Yes, do it do it do it. OpenID is awesome. —Tom Morris (talk) 09:10, 27 June 2011 (UTC)[reply]

MW:Extension:OpenID - The software exists for it, though it would still probably take some finagling to work/merge with our current WP:SUL. ▫ JohnnyMrNinja 11:16, 27 June 2011 (UTC)[reply]

  • I think this would be a really positive step towards integrating the Wikimedia usebase with other free content communities out there and, of course, making things easier for our editors. However, I haven't a clue how hard it would be to do in practice. AndrewRT(Talk) 21:27, 3 July 2011 (UTC)[reply]
  • Making security someone else's problem doesn't necessarily improve security. One could argue that adding more places to log in to could only decrease security, by adding attack vectors. Mr.Z-man 22:26, 5 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Toolserve secure links[edit]

  • This applies mainly for the high value user accounts/admins etc who make use of the toolserve utilities.

The utilities over there all currently create insecure links. For example all the links on this page, link back to the unsecure wikipedia site. So anyone using such links from the tools loss the security of using the secure site, which in turn means it can't securely used over an unsecured wifi. I propose that all such tools as least have the option of generating secure links on output. Regards, SunCreator (talk) 01:57, 23 June 2011 (UTC)[reply]

When you go from secure to unsecure and vice versa, your login does not transfer. Reaper Eternal (talk) 20:00, 23 June 2011 (UTC)[reply]
It's not the going between. When your are in unsecure mode your unsecure, period. Regards, SunCreator (talk) 21:39, 23 June 2011 (UTC)[reply]
Only if you log in whilst on the non-https site without transferring back. - Jarry1250 [Weasel? Discuss.] 21:43, 23 June 2011 (UTC)[reply]
  • Comment, I strongly like such a feature. For example: the account creator tool has a preference to use the secure variant. Why not saving somewhere the data which one is preferred? mabdul 22:33, 17 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.