Wikipedia:Village pump (proposals)/Account security

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]

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. /ƒETCH COMMS / 16:47, 3 June 2011 (UTC)[reply]

Improve password strength

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 true consensus for a strong password requirement, but there is certainly consensus for adding a password strength bar.

[majestic titan] 08:19, 13 July 2011 (UTC)[reply

]

Require more complex passwords

This suggestion was made in the password study mentioned above. MediaWiki could include a feature, at registration, that requires users' password to be at least a certain complexity. There is code written for this already (rev:70520), but it is not yet enabled on WMF sites. This code seems to have some disadvantages (e.g., see rev:70520#code-comments), but if the idea is supported, then issues can probably be fixed. This could also be changed so it tells the user how strong his/her password is, but does not prevent them from signing up with a weak password.

If possible, to minimize inconvenience for most users, we could only require passwords of high complexity for admins, bureaucrats, CUs, OSes, etc., rather than for everyone.

For an example password strength checker, see this Microsoft page.

Comments

I would support this feature (after thorough testing). My advice would be to only implement it once users become auto-confirmed; they will feel it is part of their new responsibilities/privileges (especially if we limit article creation to those accounts, which could happen soon). This could actually make auto-confirmed users feel better about their position at Wikipedia. For new users we can show them how strong their password is, and suggest the use a strong password, but we shouldn't require them. Users who are so casual that they never become auto-confirmed will likely not remember a special password they made for this site. The requirement may turn them off. Also, their accounts are so new that a compromise wouldn't matter that much on the whole. It would be hardly any different than that same vandal starting a new account. ▫ JohnnyMrNinja 05:02, 3 June 2011 (UTC)[reply]
Has my general support; no detailed comments, though (for now). Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 05:37, 3 June 2011 (UTC)[reply]
The most effective way to protect security is rate limits on password attempts, and there must also be a modest (5-6) length floor. Anything else is just obnoxious and not very helpful. Sure there are common passwords all in lower case, there are also common passwords in upper case with letters. The people dumb enough to have the password "password" will just migrate to "Pa55word", and a difference that is not several orders of magnitude is pretty irrelevant. jorgenev 07:09, 3 June 2011 (UTC)[reply]
My preference would be for it to just the user how strong the password is without actually rejecting a weak one, except for admins (and possibly rollbackers, reviewers etc.) who should be required to use a strong one. ― A. di M._plé^dréachtaí 12:20, 3 June 2011 (UTC)[reply]
Requiring "hard" passwords is self-defeating if it means many more people would be writing down their passwords. Rate limiting login attempts and requiring a CAPTCHA solution at every login would be a far more effective means of preventing brute force attacks on account credentials. While it may make sense to eliminate the 100 or 1000 most common passwords, and thus avoid extremely weak passwords, most efforts to require "hard" passwords unnecessarily add complexity and make the user experience worse while doing very little for actual security. A well engineered login process should already be very resistant to a brute force attack. Dragons flight (talk) 14:43, 3 June 2011 (UTC)[reply]
There is nothing wrong with writing down your password for something like Wikipedia. Hans Adler 17:08, 3 June 2011 (UTC)[reply]
~~Does anyone know what anti-brute force measures are in place? Though we throttle attempts after n tries in x minutes at the moment? I think that that would be useful.~~ Apparently we force a captcha after 3 login attempts. Brute forcing is therefore quite hard, which reinforces my impression that we should not force users to pick difficult to guess passwords, only advise. - Jarry1250 ^{[Weasel? Discuss.]} 20:27, 3 June 2011 (UTC)[reply]
Support showing "password strength bar", like many online sites do. No strong feeling about required strength though. The means by which passwords get compromised are rarely because of their strength, except for stupid ones, like "123456", "wikipedia", "password", etc. It's always security bugs, phishing sites, keyloggers, using same one for all sites, etc. Password strength is not going to change what I suspect is the vast majority of incidents how accounts get compromised. —
TALK 16:22, 3 June 2011 (UTC)[reply
]
- Alas, lots of people do use passwords like "123456", "wikipedia", "password", &c., and weak passwords really are used as a means of gaining unauthorised access. bobrayner (talk) 00:56, 6 June 2011 (UTC)[reply]
I would support the display of a bar, and I think every admin and above should be advised to use a strong password as part of their RFA/B/etc or shortly thereafter. I know I was asked about it at my RfA. - Jarry1250 ^{[Weasel? Discuss.]} 20:26, 3 June 2011 (UTC)[reply]
I would support a password strength bar. After appropriate testing of the feature of course. —TheDJ (talk • contribs) 23:15, 3 June 2011 (UTC)[reply]
Support the notion of a bar, but not for requiring complex passwords for all editors (since we allow IPs to edit without logging in at all). — Preceding unsigned comment added by Nuujinn (talk • contribs) 16:22, 3 June 2011
Support after sufficient tests have been made to make sure the bar's not a flub. All the major internet websites are already security conscious and have implemented methods/means to keep accounts safe, Wikipedia is far behind in terms of account security awareness. —
Talk • Contribs) • 10:30pm • 12:30, 4 June 2011 (UTC)[reply
]

Note that the password strength checking code was reverted and does not appear to have be re-added. I would support an advisory checker (as long as it actually works well, which the one mentioned apparently didn't). I would oppose mandatory strength requirements. That's just annoying and unless it's really well-made, doesn't improve security that much. The benefit in terms of stronger passwords is somewhat reduced by reducing the number of possible combinations, which makes a brute-force attack easier. If the passwords are too complex, people will be more likely to write them down – a lot of account "hacking" isn't from remote hackers, it's from people who share computers. Mr.Z-man 15:14, 4 June 2011 (UTC)[reply]
Would cracklib (as mentioned in the previous discussion) be adequate for the task? It is already established, and has a compatible license to MediWiki. ▫ JohnnyMrNinja 08:26, 5 June 2011 (UTC)[reply]
Support With weak/medium/high display bars. The Helpful One 22:32, 5 June 2011 (UTC)[reply]
- is that "support requiring"? This discussion has got a bit confused between requiring strong passwords and giving feedback on password strength, which is covered by the section below this one. Rd232 ^talk 22:41, 5 June 2011 (UTC)[reply]
Support a password bar for feedback but don't require anything just yet.
Qwertyus 00:46, 6 June 2011 (UTC)[reply
]

Support both - I'd like to see a password complexity requirement, but if that doesn't get enough community support, then at least a password complexity indicator should encourage many (not all) users to substantially improve their password complexity. bobrayner (talk) 00:58, 6 June 2011 (UTC)[reply]
Length only Password complexity requirements don't work. Users take very predictable, minimal steps to comply. (replacing a with @, adding a 1 or 2 at the end, etc.) The one thing that does work is a minimum length requirement. I would suggest 8 characters for users and 12 characters for those with special bits, admins etc.--agr (talk) 21:08, 7 June 2011 (UTC)[reply]
Support for length requirements only. I agree with comments above that other complexity requirements don't help that much, and in my experience they create more annoyance than security. --RL0919 (talk) 15:14, 8 June 2011 (UTC)[reply]
Conditional Support - for reasonable length requirements only. I don't know of any other websites that accept 1-character passwords, as apparently Wikipedia still does. Upping requirements should ideally be linked with some means to require or at least encourage users to provide email accounts. Rd232 ^talk 19:57, 8 June 2011 (UTC)[reply]
Oppose in general, because new accounts have such low value that they're really not working hacking into. I would accept minimal length requirements (four or five characters?), but I oppose complexity requirements for low-value accounts. They don't work, anyway: people just turn "password" into "password1". (It's almost always a 1 or 0, and it's always at the end.) I would strongly support adding password education and an easy link to "Strengthen my password right now" to the new admin school, but not to actually force people to use high-quality passwords. WhatamIdoing (talk) 00:59, 10 June 2011 (UTC)[reply]
- I already added a note to the New Admin School. Rd232 ^talk 01:07, 10 June 2011 (UTC)[reply]
Unnecessary this is simply not a site where a high value password is necessary for ordinary users. Admins and advanced permissions are3 another matter entirely. DGG ( talk ) 21:17, 14 June 2011 (UTC)[reply]
Support a strength checking bar as well as some very basic strength requirements. I would suggest a minimum of 6 characters, including one letter and one number, for all users and stronger requirements for admins, etc. 6 characters including a letter and number is a fairly common requirement on other sites from what I've seen, so it's not likely to turn off the type of casual user that JohnnyMrNinja described. Strongly oppose requiring both capital and lowercase letters and/or requiring punctuation for all users, as this would definitely turn off those casual users, but I wouldn't have a problem with such requirements for admins, etc. jcgoble3 (talk) 17:12, 15 June 2011 (UTC)[reply]
Support - It's actually negative to the perception of wikipedia that this is not currently done. Regards,
talk) 02:35, 23 June 2011 (UTC)[reply
]

Limited support providing a "feedback bar" on how good the password is; mandatory strong passwords should be limited to sysops etc. Even then it runs the risk that people will write down their password (which is completely self-defeating). Oppose any password age rules (forced change every X days); all that does is makes people put an incrementing number at the end. Stifle (talk) 14:32, 1 July 2011 (UTC)[reply]
Support for admin accounts I strongly support this in regards to admin and higher privileged accounts, but I don't think it is necessary for the rest. An established editors account is a low value target in that the only advantage an intruder has over just registering a new account is reduced attention from anti-vandal programs, but hacking an account just so you can go a little longer before a vandalism spree is detected seems unlikely to result in much hacking. Still, education is good, so I would support a feedback bar to advise users on the strength of their password, and some advice encouraging but not requiring strong passwords. Monty ₈₄₅ 16:02, 5 July 2011 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Add a notice to the signup page about password strength

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

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

Comments

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". —
TALK 16:24, 3 June 2011 (UTC)[reply
]
Th@t s0unds g00d (That sounds good) ~~EBE123~~ ^talk_Contribs 22:10, 3 June 2011 (UTC)[reply]
How about an article in The Signpost? ~~EBE123~~ ^talk_Contribs 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 (talk • contribs) 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

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,
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.--SPhilbrick T 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

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

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.

Comments

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

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. /ƒETCH COMMS / 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. /ƒETCH COMMS / 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. —
Talk • Contribs) • 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.
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. ╟─Treasury Tag►Counsellor 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. elektrik SHOOS 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 [email protected] 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
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? –
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,
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. Monty ₈₄₅ 16:09, 5 July 2011 (UTC)[reply]

...for autoconfirmed users

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. elektrik SHOOS 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.
  talk 22:09, 3 July 2011 (UTC)[reply
  ]

...for admin etc accounts

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. elektrik SHOOS 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,
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. Monty ₈₄₅ 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

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]

Comments

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,

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

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

Comments

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. Ϣere SpielChequers 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

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.

Clear consensus for an email notification with IP address, albeit only after two to three attempts. I'll leave it to the participants to carry out the results of this discussion.

[majestic titan] 08:15, 13 July 2011 (UTC)[reply

]

Notify users via email when someone tries to log into their account with the wrong password

Currently, MediaWiki forces users to fill in a captcha after they try to log in with the wrong password three times in a row. The software could also notify an account by email when this happens, telling them that someone tried to log into their account unsuccessfully several times and then explaining how to reset their password if they genuinely forgot.

This could be paired up with an IP-detection system that tells the user where the failed logins came from—like the current password reset system—or a delay system (like on iPhones/iPads), where after a certain number of failed logins, one has to wait a few minutes before being able to try logging in again.

Addendum: this proposal is covered by the existing T11838, which has been open since 2007. Community support for it, both here and by voting on Bugzilla, may draw developer attention.

Comments

Absolutely. Should be done. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 05:40, 3 June 2011 (UTC)[reply]
Agree. I'd allow users to disable it or to decide in their preferences how many failed attempts to wait before sending the e-mai, with 1 as the default. ― A. di M._plé^dréachtaí 12:27, 3 June 2011 (UTC)[reply]
I assumed this was already in place, like most sites. So support. —
TALK 16:34, 3 June 2011 (UTC)[reply
]

Good idea in general, but I am slightly worried about the bonus idea of telling the targets about the IP address.
I won't go too much into the details, but an attacker could trick a user into trying to log in to the wrong account set up for the purpose, and then learn the target's IP address. Hans Adler 17:14, 3 June 2011 (UTC)[reply
]

Support, Agree good suggestion. We could make a MediaWiki: page to notify. Maybe "MediaWiki:Passwordfail". ~~EBE123~~ ^talk_Contribs 22:03, 3 June 2011 (UTC)[reply]
Support, but only on the second failure. I've mistyped my passwd incorrectly myself rather often. :D Not sure if the IP idea is good thing. Will need careful consideration. —TheDJ (talk • contribs) 23:20, 3 June 2011 (UTC)[reply]
Oppose. It might be useful for admin users, but probably not. The question is, what would be the result of such notifications? Such information might be useful to someone in a position to try to block the attempt, but what's the point of telling me that someone tried to use my account and failed if there's nothing I can do in response? This won't affect a successful attack, and as an editor I can't do anything about the person trying the unsuccessful attack. The use of Captcha already introduces a delay in any case, and longer delays can result in effective DOS attacks against accounts. Blocking the IP address would be more effective, but would result in ranges of editors being blocked since NAT systems with ranges of private addresses present as a single pubic IP address. Steep downside, not much upside.--Nuujinn (talk) 23:34, 3 June 2011 (UTC)[reply]
- I would certainly want to know if someone was attempting to access my account. Especially as I and many other users use the same handle on multiple sites, this could be an alert to a bigger problem, and at least just a minor annoying email. It could also prompt me to change my password had I been using a weaker one (but I'm not, fortunately!). /ƒETCH COMMS / 01:40, 4 June 2011 (UTC)[reply]
  - I get that. But whenever I fire up Wireshark, check my SSH or HTTP logs, or look at Snort, I see dozens of light brute force attacks against services, and these are generated by scripts, generally run from compromised account. These days, it's not a question of whether someone is trying to access your account, but rather how are they doing it and how hard they are trying. From a systems admin point of view, noting this automatic attacks and blocking them is a good thing. But as a user on WP, I can't do anything about such attacks against my account. Most people (based on my work experience) will want to do something, and will have to ask someone else to explain or do something about it. Now, if we know what the answer they should get, or have an easy way for them to do something about it, this might be helpful, but I am afraid it will increase fear among users and frustration among admins. --Nuujinn (talk) 10:25, 4 June 2011 (UTC)[reply]
Why only per mail? What about also adding a note after successful login? mabdul 09:52, 4 June 2011 (UTC)[reply]
Support TheDJ raises a good point about users mistyping their own passwords, maybe there should be 2 specialised emails, 1 for the first attempt and one for those thereafter and I think that a change should be implemented to the software that if after 5 attempts the account gets locked, similar to the system currently in place on
Talk • Contribs) • 10:27pm • 12:27, 4 June 2011 (UTC)[reply
]
- I agree with LadyofShalott below that an email for the first time is going to be simply annoying, especially as most of the time it is someone mistyping their own password. As we have a captcha after three failed attempts, perhaps a temporary lockout after five tries plus an email would make sense? /ƒETCH COMMS / 16:23, 4 June 2011 (UTC)[reply]
  - Hmm I'll make an alternate proposal. —
    Talk • Contribs) • 1:50pm • 03:50, 5 June 2011 (UTC)[reply
    ]

I would oppose an email after just one - for the simple reason that it would be very annoying to get an email everytime I make a typo in my password or absentmindedly try to login with the password for one of my other sites. Beyond that, I would have no opposition to it. LadyofShalott 13:49, 4 June 2011 (UTC)[reply]
Support, but as a recommended opt-in feature (perhaps prompt at signup). This could easily be abused by disgruntled users, so it must at least be able to be opted out of. The opt-in could have an option to contact on one, three, or five tries. Mamyles (talk) 22:59, 4 June 2011 (UTC)[reply]
Support as optout feature on the basis proposed, namely an email after 3 failed login attempts. Useful reminder for people who may have forgotten their password, plus the email should contain a reminder to check password strength ("if the failed logins are not from you"). Rd232 ^talk 17:20, 5 June 2011 (UTC)[reply]
Support provided that the user is able to adjust the password attempt threshold in their preferences. MorganKevinJ^(talk) 17:47, 5 June 2011 (UTC)[reply]
- What's the advantage of that, compared to a simple optout (for cases of deliberate abuse by a third party)? Rd232 ^talk 18:49, 5 June 2011 (UTC)[reply]
  - If a user often mistypes their password they may want it to be less sensitive but not completely turned off. If the pasword is more complex than Password it usually will take at least 50 attempts to brute force. MorganKevinJ^(talk) 01:52, 6 June 2011 (UTC)[reply]
    - I don't buy that. It's not like the user's locked out after 3 attempts - they're just getting an email. I can't see users getting their password wrong 3 times frequently enough to be bothered by an email when it happens; so it's not worth the bother of an option to configure it, when they have the option to turn it off. Rd232 ^talk 02:28, 6 June 2011 (UTC)[reply]
Support --Guerillero | My Talk 18:20, 5 June 2011 (UTC)[reply]
Support - Give the IP too if possible of each failed attempt. But also agree with mabdul, just like freenode gives "x inncorrect attempts from <IP>" after you identify successfully, after successful login, we should get a message too. The Helpful One 22:35, 5 June 2011 (UTC)[reply]
Support, sounds very useful. --
dferg 22:41, 05 June 2011 (UTC) 22:41, 5 June 2011 (UTC)[reply
]

I can't say that I support or oppose this one. Like Nuujinn, I'm not sure that this gives much benefit, but I can't see any significant harm in it as long as the notifications are limited as discussed in the comments above. However, if this isn't an existing feature, I wouldn't want developers to spend time on this rather than some of the other items suggested on this page. --RL0919 (talk) 15:25, 8 June 2011 (UTC)[reply]
Weak support. The benefits are low, because the only thing a user can do is change their password to something more secure. By the time they've got the email and done that, the attacker's probably either succeeded or given up anyway. But in a world where developer time wasn't at such a premium - sure, worth having. Rd232 ^talk 19:52, 8 June 2011 (UTC)[reply]
If we are going to encourage strong passwords that people don't use elsewhere then this will become more common, so it must not be after just one or two mistakes. Otherwise yes this is sensible. Ϣere SpielChequers 06:54, 13 June 2011 (UTC)[reply]
Oppose, unless it's set up as being an opt-in only feature, preferably with a threshhold setting (only once there have been x tries, each user choosing his/her own x) and a maximum number of emails/period. We neither want a user to keep getting emails about his/her own mistyping the password, nor allow disruptive users to get revenge at the blocking admin by flooding him/her with these emails. עוד מישהו Od Mishehu 08:15, 20 June 2011 (UTC)[reply]
Support but only on an opt-in basis. Stifle (talk) 14:37, 1 July 2011 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Notify users after renewed activity

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.

Comments

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

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!). /ƒETCH COMMS / 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

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?) /ƒETCH COMMS / 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. /ƒETCH COMMS / 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~~ ^talk_Contribs 20:04, 27 June 2011 (UTC)[reply]

Limit viewdeleted rights for admin accounts

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]

Comments

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. /ƒETCH COMMS / 23:24, 10 June 2011 (UTC)[reply]

Technical issues

Have MediaWiki encrypt password transmission by default

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.

Comments

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

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,
    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. —
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~~ ^talk_Contribs 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 (talk • contribs) 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. --
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. —
Talk • Contribs) • 5:34pm • 07:34, 10 June 2011 (UTC)[reply
]

Support for obvious reasons. elektrik SHOOS 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,
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

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]

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,
talk) 02:51, 23 June 2011 (UTC)[reply
]

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

WP:SNOW

-closed.

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.

Comments

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

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.

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
Upon registration an email should be sent requiring verification
After verification, the account can be used, if not verified after a week the account is deleted to free up space
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)
After the third failed attempt CAPTCHA will be enabled for all subsequent attempts
Upon 5 failed attempts the account will be locked for 24 hours and an email will be sent to the account's owner
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.
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? —

Talk • Contribs) • 2:09pm • 04:09, 5 June 2011 (UTC)[reply

]

Comments

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?

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). Ray^Talk 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. /ƒETCH COMMS / 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]

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

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,

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,

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.