I have seen there is a lot of wikis where people are concerned about inactive sysops. They managed to set up a strange rule where sysop rights are removed from inactive users to improve the security. However the sysops are allowed to request the flag to be restored anytime. This doesn't improve security even a bit as long as hacker who would get to some of inactive accounts could just post a request and get the sysop rights just as if they hacked to active user.
For this reason I think we should create a new extension auto sysop removal, which would remove the flag from all users who didn't login to system for some time, and if they logged back, the confirmation code would be sent to email, so that they could reactivate the sysop account. This would be much simpler and it would actually make hacking to sysop accounts much harder. I also believe it would be nice if system sent an email to holder of account when someone do more than 5 bad login attemps, in order to be warned that someone is likely trying to compromise their account.
More:
IP addresses which do N bad login attemps should be blocked from accessing login page for Z minutes (You have done too many bad login attempts, please wait 5 minutes before trying again) This would help to avoid bots who try to compromise account by trying random passwords
The target user should be notified according to their personal config (They could specify if they want to be warned if someone is about to compromise their account or not)
On Wed, Apr 4, 2012 at 9:43 AM, Petr Bena benapetr@gmail.com wrote:
I have seen there is a lot of wikis where people are concerned about inactive sysops. They managed to set up a strange rule where sysop rights are removed from inactive users to improve the security. However the sysops are allowed to request the flag to be restored anytime. This doesn't improve security even a bit as long as hacker who would get to some of inactive accounts could just post a request and get the sysop rights just as if they hacked to active user.
For this reason I think we should create a new extension auto sysop removal, which would remove the flag from all users who didn't login to system for some time, and if they logged back, the confirmation code would be sent to email, so that they could reactivate the sysop account. This would be much simpler and it would actually make hacking to sysop accounts much harder. I also believe it would be nice if system sent an email to holder of account when someone do more than 5 bad login attemps, in order to be warned that someone is likely trying to compromise their account.
Something on password rate limits has been on my mind ever since watching one of the Security Now episodes. Rather than cut-off rate limits isn't it a better experience to use something with a slow exponential/compound increase
Think about the case where the user has forgotten their password, they remember its probably one of 6 passwords and they don't want to bother resetting the password. They start trying out their passwords, but once they it that last password and are thinking (right, this HAS to be the one I used) they get hit with an error saying that all of a sudden they have to wait 5 whole minutes.
Something instead based on increasing wait time a bit each time seams like if tuned right could be a better experience.
- By the time the user hits their 5th password the wait time may have reached 1min. - That last password is only a tiny bit more than the wait they just had. - It's still secure, brute forcing takes a lot of tries. So even though we don't punish bots much for their first few tries, as they continue it just gets worse and worse for them. By the time they hit a mere 100 they could be waiting a half-hour before they can continue instead of simply 5min. - Wait times below a certain threshold (one that the first 5 or so tries would be below) could be either ignored or handled with sleep() so that instead of forcing a discouraging error message on a user and making the user do time tracking (something that is trivial for bots, so this is an unhelpful negative to user experience) the login page only feels like it's a little sluggish.
On Wed, Apr 4, 2012 at 7:53 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
Rather than cut-off rate limits isn't it a better experience to use something with a slow exponential/compound increase
It's worth noting that there's already a softer cut-off: ConfirmEdit's "badlogin" trigger. Still, I like your idea.
On Wed, Apr 4, 2012 at 5:43 PM, Petr Bena benapetr@gmail.com wrote:
I have seen there is a lot of wikis where people are concerned about inactive sysops. They managed to set up a strange rule where sysop rights are removed from inactive users to improve the security. However the sysops are allowed to request the flag to be restored anytime. This doesn't improve security even a bit as long as hacker who would get to some of inactive accounts could just post a request and get the sysop rights just as if they hacked to active user.
For this reason I think we should create a new extension auto sysop removal, which would remove the flag from all users who didn't login to system for some time, and if they logged back, the confirmation code would be sent to email, so that they could reactivate the sysop account. This would be much simpler and it would actually make hacking to sysop accounts much harder. I also believe it would be nice if system sent an email to holder of account when someone do more than 5 bad login attemps, in order to be warned that someone is likely trying to compromise their account.
What happens if the ex-sysop has lost access to their original email address .. ?
On Wed, Apr 4, 2012 at 10:15 AM, John Vandenberg jayvdb@gmail.com wrote:
What happens if the ex-sysop has lost access to their original email address .. ?
If the sysop lost their email, they are in same troubles as if any other user lost their email and forgot password. It simply shouldn't happen.
On Wed, Apr 4, 2012 at 10:16 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
2012/4/4 Petr Bena benapetr@gmail.com:
I have seen there is a lot of wikis where people are concerned about inactive sysops. They managed to set up a strange rule where sysop rights are removed from inactive users to improve the security. However the sysops are allowed to request the flag to be restored anytime. This doesn't improve security even a bit as long as hacker who would get to some of inactive accounts could just post a request and get the sysop rights just as if they hacked to active user.
There's no point in making technical solutions for problems which are imaginary in the first place, just as you say. The English Wikipedia community rejects the notion that sysop inactivity is a problem quite firmly, and it does just fine. Meta, Commons, my home Hebrew Wikipedia and some other projects do have such rules, and they are completely pointless.
An account with sysop rights cannot do that much damage anyway. Deleting a page does no more damage than deleting a paragraph in an existent page, and the latter can be done by anybody; in fact, deleting a page makes a lot more noise. The same goes for protection, blocking and editing in the MediaWiki space - everything is easily traceable and reversible, and in a functioning wiki community the damage will be minimal.
That isn't excuse to leave project open to damage. Security of mediawiki users and their accounts should be important for us anyway.
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benapetr@gmail.com wrote:
On Wed, Apr 4, 2012 at 10:15 AM, John Vandenberg jayvdb@gmail.com wrote:
What happens if the ex-sysop has lost access to their original email address .. ?
If the sysop lost their email, they are in same troubles as if any other user lost their email and forgot password. It simply shouldn't happen.
It does happen.
It's a significant problem if it is an ordinary user, but they can always create a new account and assert that they are the old user and nobody really cares.
It's a major issue if it is a sysop, because it can be very hard to verify the identity of someone claiming to be a sysop, so 'crats and arbcom and the community try and find a web of trust that extends back in time. Not fun.
Also, you might want to query the databases to see how many admins don't have an email address set. I wouldn't be surprised if there are a few. IMO any that dont have an email set should have their sysop bit removed.
2012/4/4 John Vandenberg jayvdb@gmail.com
Also, you might want to query the databases to see how many admins don't have an email address set. I wouldn't be surprised if there are a few. IMO any that dont have an email set should have their sysop bit removed.
Would it be a crazy idea to modify the software so that new admins, 'crats etc. can be inaugurated only if they have a confirmed e-mail? While the "unit-radius" useres can happily edit without it, this would not be a great expectation towards "clerks".
Actually sysops could be just required to have the email set in the project guidelines. If they don't do that and their account expire, they lost the sysop. I don't see it as a big deal. I hope that sysops are clever enough to at least be able to follow their own rules.
On Wed, Apr 4, 2012 at 11:09 AM, Bináris wikiposta@gmail.com wrote:
2012/4/4 John Vandenberg jayvdb@gmail.com
Also, you might want to query the databases to see how many admins don't have an email address set. I wouldn't be surprised if there are a few. IMO any that dont have an email set should have their sysop bit removed.
Would it be a crazy idea to modify the software so that new admins, 'crats etc. can be inaugurated only if they have a confirmed e-mail? While the "unit-radius" useres can happily edit without it, this would not be a great expectation towards "clerks".
-- Bináris _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Apr 4, 2012 at 7:12 PM, Petr Bena benapetr@gmail.com wrote:
Actually sysops could be just required to have the email set in the project guidelines. If they don't do that and their account expire, they lost the sysop. I don't see it as a big deal. I hope that sysops are clever enough to at least be able to follow their own rules.
Rules? which rules. There are seven projects which have multiple languages, and over 282 languages. Good luck updating all their policies, and talking to all the sysops who arnt complying with the policy, etc.
-- John Vandenberg
I don't say this would be enabled for all projects, it could be a replacement of that weird policy for removal of inactive sysops they created on few wikis, including english wikipedia. It would be just a slightly better solution for same problem as they have right now. If they don't want to update any policies they don't need to have it installed, of course.
On Wed, Apr 4, 2012 at 11:16 AM, John Vandenberg jayvdb@gmail.com wrote:
On Wed, Apr 4, 2012 at 7:12 PM, Petr Bena benapetr@gmail.com wrote:
Actually sysops could be just required to have the email set in the project guidelines. If they don't do that and their account expire, they lost the sysop. I don't see it as a big deal. I hope that sysops are clever enough to at least be able to follow their own rules.
Rules? which rules. There are seven projects which have multiple languages, and over 282 languages. Good luck updating all their policies, and talking to all the sysops who arnt complying with the policy, etc.
-- John Vandenberg
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 4 April 2012 10:21, Petr Bena benapetr@gmail.com wrote:
I don't say this would be enabled for all projects, it could be a replacement of that weird policy for removal of inactive sysops they created on few wikis, including english wikipedia. It would be just a slightly better solution for same problem as they have right now. If they don't want to update any policies they don't need to have it installed, of course.
Way to get the projects on side... calling the policy weird ;)
Tom
Indeed :-)
But if I didn't think it's weird, I wouldn't start this. I am always trying to find a solution from programmer point of view for a problems which community sometimes try to solve "by hand".
On Wed, Apr 4, 2012 at 11:23 AM, Thomas Morton morton.thomas@googlemail.com wrote:
On 4 April 2012 10:21, Petr Bena benapetr@gmail.com wrote:
I don't say this would be enabled for all projects, it could be a replacement of that weird policy for removal of inactive sysops they created on few wikis, including english wikipedia. It would be just a slightly better solution for same problem as they have right now. If they don't want to update any policies they don't need to have it installed, of course.
Way to get the projects on side... calling the policy weird ;)
Tom _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 4 April 2012 10:28, Petr Bena benapetr@gmail.com wrote:
Indeed :-)
But if I didn't think it's weird, I wouldn't start this. I am always trying to find a solution from programmer point of view for a problems which community sometimes try to solve "by hand".
From a security perspective (my speciality) there really isn't a lot of a
difference between the two proposals in terms of the problems they face.
Except that the current process requires a certain "human" involvement, and scrutiny. Which is usually the best security mechanism.
A determined attacker is going to be able to break through either process; but in the current setup their subsequent actions are likely to be noticed.
Tom
I see a lot of differences:
The current process needs to be done by hand, which isn't just annoying, but also not fail safe, some accounts might be overlooked, etc. Bureaucrats can mislick or forget. The email account is likely much more safe than wikimedia account, the google for example offers a lot of security measures we don't, because they don't follow "hacking user wouldn't do much damage" philosophy. And I guess many other providers do the same. Hacking to two accounts would be much harder than hacking one, given to that once the first account is hacked, the user would be immediately notified in email (hacker would have very limited time to hack to email box as well).
I don't say it's necessary, I definitely understand that getting a sysop can't cause big problems and it's unlike it would happen frequently. But I think this automated system is a better solution than what the wikis started with.
On Wed, Apr 4, 2012 at 11:31 AM, Thomas Morton morton.thomas@googlemail.com wrote:
On 4 April 2012 10:28, Petr Bena benapetr@gmail.com wrote:
Indeed :-)
But if I didn't think it's weird, I wouldn't start this. I am always trying to find a solution from programmer point of view for a problems which community sometimes try to solve "by hand".
From a security perspective (my speciality) there really isn't a lot of a difference between the two proposals in terms of the problems they face.
Except that the current process requires a certain "human" involvement, and scrutiny. Which is usually the best security mechanism.
A determined attacker is going to be able to break through either process; but in the current setup their subsequent actions are likely to be noticed.
Tom _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The current process needs to be done by hand, which isn't just
annoying, but also not fail safe, some accounts might be overlooked,
etc. Bureaucrats can mislick or forget.
Certainly automatic de-sysoping after a certain inactivity would be useful; an extension that does the notifications and ultimately the de-sysoping would be useful to automate the community approved process, don't get me wrong on that front, I like the idea!
The email account is likely much more safe than wikimedia account,
Not a good premise to take; email accounts are high value targets (as opposed to a Wikipedia account, which has relatively low general value). So although they are harder to crack (to a point) they are also more worthwhile targets.
So an email account is a significant risk.
And an account without an email address added could be argued to be *more*secure.
the google for example offers a
lot of security measures we don't, because they don't follow "hacking user wouldn't do much damage" philosophy.
It's largely security theatre; except the two factor authentication (which is actually useful). Our accounts simple aren't that valuable, which is why actual security of that form isn't really a good option. What you proposed is only really a stopgap.
And I guess many other providers do the same. Hacking to two accounts would be much harder than hacking one, given to that once the first account is hacked, the user would be immediately notified in email (hacker would have very limited time to hack to email box as well).
Realistically, and in my experience, this is not the case. You're relying on the user to respond, or being in a position to respond - which is the critical failing of the proposal.
When we do pen tests often we will make notifications of some sort appear in front of users to see how they respond to them - and often the response is confusion, not concern. Remember; the large part of the WM community is * not* technical.
Tom
Ok, your reply makes a lot of sense. However problem is that how users get more "hats" they are usually more afraid of loosing them :-) and would probably like to have an option to protect from attackers (I don't really know but I hope that people with some extra flags are trying to have a secure password at least). The account is getting more valuable and for example account of some stewards might be a good target for hackers. The question is how these people can defend themselves when the philosophy is "we don't need strong security because user accounts aren't valuable / can't do much damange to site" - when their account is compromised, they will surely have the flags revoked permanently, that's likely not what they want. So at some point, having more security measures which could be opt-in for people who do care about their account, in opposite of people whom account isn't interesting for hackers would make some point too. Given that there are thousands of sysops on big projects, I guess they would welcome to have this feature. (Not that I care, personally, I was just interested in implementing that to mediawiki)
On Wed, Apr 4, 2012 at 11:48 AM, Thomas Morton morton.thomas@googlemail.com wrote:
The current process needs to be done by hand, which isn't just
annoying, but also not fail safe, some accounts might be overlooked,
etc. Bureaucrats can mislick or forget.
Certainly automatic de-sysoping after a certain inactivity would be useful; an extension that does the notifications and ultimately the de-sysoping would be useful to automate the community approved process, don't get me wrong on that front, I like the idea!
The email account is likely much more safe than wikimedia account,
Not a good premise to take; email accounts are high value targets (as opposed to a Wikipedia account, which has relatively low general value). So although they are harder to crack (to a point) they are also more worthwhile targets.
So an email account is a significant risk.
And an account without an email address added could be argued to be *more*secure.
the google for example offers a
lot of security measures we don't, because they don't follow "hacking user wouldn't do much damage" philosophy.
It's largely security theatre; except the two factor authentication (which is actually useful). Our accounts simple aren't that valuable, which is why actual security of that form isn't really a good option. What you proposed is only really a stopgap.
And I guess many other providers do the same. Hacking to two accounts would be much harder than hacking one, given to that once the first account is hacked, the user would be immediately notified in email (hacker would have very limited time to hack to email box as well).
Realistically, and in my experience, this is not the case. You're relying on the user to respond, or being in a position to respond - which is the critical failing of the proposal.
When we do pen tests often we will make notifications of some sort appear in front of users to see how they respond to them - and often the response is confusion, not concern. Remember; the large part of the WM community is * not* technical.
Tom _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ok, your reply makes a lot of sense. However problem is that how users get more "hats" they are usually more afraid of loosing them :-) and would probably like to have an option to protect from attackers (I don't really know but I hope that people with some extra flags are trying to have a secure password at least).
Not a bad aim - I didn't intend to be outright discouraging :)
The account is getting more valuable and for example account of some stewards might be a good target for hackers.
Yes; Steward accounts are a whole different matter - I'd say they have a much higher level of risk if compromised.
The question is how these people can defend themselves when the philosophy is "we don't need strong security because user accounts aren't valuable / can't do much damange to site"
- when their account is compromised, they will surely have the flags
revoked permanently, that's likely not what they want. So at some point, having more security measures which could be opt-in for people who do care about their account, in opposite of people whom account isn't interesting for hackers would make some point too. Given that there are thousands of sysops on big projects, I guess they would welcome to have this feature. (Not that I care, personally, I was just interested in implementing that to mediawiki)
As above; not a bad aim.
One good idea would be to enforce some sort of minimum password standard - that can help with brute force attack vectors.
Tom
Sooo... we're on the way to HTTPS... what's next? YubiKey/Google Authenticator/etc... 2-factor auth? Or signed client side user certificates (<keygen>, etc...)?
On Wed, Apr 4, 2012 at 7:28 PM, Petr Bena benapetr@gmail.com wrote:
Indeed :-)
But if I didn't think it's weird, I wouldn't start this. I am always trying to find a solution from programmer point of view for a problems which community sometimes try to solve "by hand".
But the community isn't complaining about this being time consuming. Where they desysop inactive sysops, it is a social community exercise and your technical solution is probably not going to have the same effect. On English Wikisource we have annual reconfirmations and we use our brains to gauge whether a sysop is likely to return soon. The security aspect is only a small part of it.
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benapetr@gmail.com wrote:
An account with sysop rights cannot do that much damage anyway. Deleting a page does no more damage than deleting a paragraph in an existent page, and the latter can be done by anybody; in fact, deleting a page makes a lot more noise. The same goes for protection, blocking and editing in the MediaWiki space - everything is easily traceable and reversible, and in a functioning wiki community the damage will be minimal.
That isn't excuse to leave project open to damage. Security of mediawiki users and their accounts should be important for us anyway.
Actually, this is the most important thing to think about.
There is no such thing as perfect security. You just need to make it more costly to breach security than the benefit that a hacker would get for it. Conversely, you need to expend no more effort in security than the cost of a breach in security.
Now, there are things that sysops can do that aren't so easily reversible. You could surreptitiously add site JS that captured tokens from checkusers and released large amounts of sensitive data, so it's not exactly without merit. But I don't think it's justifiable to dismiss discussion about whether extra security is "worth it".
2012/4/13 Andrew Garrett agarrett@wikimedia.org
You could surreptitiously add site JS that captured tokens from checkusers and released large amounts of sensitive data,
What can CUs do to prevent this?
Στις 13-04-2012, ημέρα Παρ, και ώρα 12:49 +1000, ο/η Andrew Garrett έγραψε:
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benapetr@gmail.com wrote:
An account with sysop rights cannot do that much damage anyway. Deleting a page does no more damage than deleting a paragraph in an existent page, and the latter can be done by anybody; in fact, deleting a page makes a lot more noise. The same goes for protection, blocking and editing in the MediaWiki space - everything is easily traceable and reversible, and in a functioning wiki community the damage will be minimal.
That isn't excuse to leave project open to damage. Security of mediawiki users and their accounts should be important for us anyway.
Actually, this is the most important thing to think about.
There is no such thing as perfect security. You just need to make it more costly to breach security than the benefit that a hacker would get for it. Conversely, you need to expend no more effort in security than the cost of a breach in security.
Now, there are things that sysops can do that aren't so easily reversible. You could surreptitiously add site JS that captured tokens from checkusers and released large amounts of sensitive data, so it's not exactly without merit. But I don't think it's justifiable to dismiss discussion about whether extra security is "worth it".
If I wanted to cause harm to an editing community, one of the better ways might be to take over a few inactive sysop accounts and slowly start to push for policies and take actions that are divisive. The resulting damage to community trust would be hard indeed to undo; think back to the various infiltration programs of law enforcement into activist groups in the 1960's and 1970's in the U.S. for a prime example of this.
I don't think this justifies automated de-sysopping of inactive accounts (because this also sends a message about trust or value to the account owner), but a notification system of some sort, as has been proposed earlier in this thread, might be nice.
Ariel
No doubt that any user account compromised would be unfortunate and would also mean that developers didn't make the software secure enough. On one side there are needs for big restriction on community developers from being able to access resources (not just shell access is restricted a lot) but it was also announced recently that any site using standard api authentication to wikimedia would be blocked from having access to cluster, unless it uses any other authentication despite that there is no other way (so it completely blocks various projects). On other side you are telling here that security isn't so important since the compromised accounts couldn't do much damage.
I don't really know what is true, but I agree that security is something important, we shouldn't underestimate, so any improvement which actually doesn't cost much (in some cases it does cost literally 0$, for example rewriting some policies on projects requiring sysops to have strong passwords is something what would cost only a time needed to fix it) is worth of implementing.
Ariel: I didn't propose to auto desysop anyone, I proposed to improve security for users themselves, the accounts wouldn't get really desysoped but deactivated and needed to be activated by email. Also if you really want to tell us how is it possible to hack to the site, please don't post it publicly next time, "If I wanted to cause harm to an editing community, one of the better ways might be ..." sounds dangerous from someone who has access to servers :-)
On Fri, Apr 13, 2012 at 9:06 AM, Ariel T. Glenn ariel@wikimedia.org wrote:
Στις 13-04-2012, ημέρα Παρ, και ώρα 12:49 +1000, ο/η Andrew Garrett έγραψε:
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benapetr@gmail.com wrote:
An account with sysop rights cannot do that much damage anyway. Deleting a page does no more damage than deleting a paragraph in an existent page, and the latter can be done by anybody; in fact, deleting a page makes a lot more noise. The same goes for protection, blocking and editing in the MediaWiki space - everything is easily traceable and reversible, and in a functioning wiki community the damage will be minimal.
That isn't excuse to leave project open to damage. Security of mediawiki users and their accounts should be important for us anyway.
Actually, this is the most important thing to think about.
There is no such thing as perfect security. You just need to make it more costly to breach security than the benefit that a hacker would get for it. Conversely, you need to expend no more effort in security than the cost of a breach in security.
Now, there are things that sysops can do that aren't so easily reversible. You could surreptitiously add site JS that captured tokens from checkusers and released large amounts of sensitive data, so it's not exactly without merit. But I don't think it's justifiable to dismiss discussion about whether extra security is "worth it".
If I wanted to cause harm to an editing community, one of the better ways might be to take over a few inactive sysop accounts and slowly start to push for policies and take actions that are divisive. The resulting damage to community trust would be hard indeed to undo; think back to the various infiltration programs of law enforcement into activist groups in the 1960's and 1970's in the U.S. for a prime example of this.
I don't think this justifies automated de-sysopping of inactive accounts (because this also sends a message about trust or value to the account owner), but a notification system of some sort, as has been proposed earlier in this thread, might be nice.
Ariel
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 13/04/12 09:30, Petr Bena wrote:
"If I wanted to cause harm to an editing community, one of the better ways might be ..." sounds dangerous from someone who has access to servers :-)
He is a puppetmaster who wants nothing from his puppets? :) http://xkcd.com/792/
On 13 April 2012 03:49, Andrew Garrett agarrett@wikimedia.org wrote:
Now, there are things that sysops can do that aren't so easily reversible. You could surreptitiously add site JS that captured tokens from checkusers and released large amounts of sensitive data, so it's not exactly without merit. But I don't think it's justifiable to dismiss discussion about whether extra security is "worth it".
Are history merges easily reversible yet?
- d.
2012/4/4 Petr Bena benapetr@gmail.com:
I have seen there is a lot of wikis where people are concerned about inactive sysops. They managed to set up a strange rule where sysop rights are removed from inactive users to improve the security. However the sysops are allowed to request the flag to be restored anytime. This doesn't improve security even a bit as long as hacker who would get to some of inactive accounts could just post a request and get the sysop rights just as if they hacked to active user.
There's no point in making technical solutions for problems which are imaginary in the first place, just as you say. The English Wikipedia community rejects the notion that sysop inactivity is a problem quite firmly, and it does just fine. Meta, Commons, my home Hebrew Wikipedia and some other projects do have such rules, and they are completely pointless.
An account with sysop rights cannot do that much damage anyway. Deleting a page does no more damage than deleting a paragraph in an existent page, and the latter can be done by anybody; in fact, deleting a page makes a lot more noise. The same goes for protection, blocking and editing in the MediaWiki space - everything is easily traceable and reversible, and in a functioning wiki community the damage will be minimal.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
On Wed, Apr 4, 2012 at 5:43 PM, Petr Bena benapetr@gmail.com wrote:
I have seen there is a lot of wikis where people are concerned about inactive sysops. They managed to set up a strange rule where sysop rights are removed from inactive users to improve the security. However the sysops are allowed to request the flag to be restored anytime. This doesn't improve security even a bit as long as hacker who would get to some of inactive accounts could just post a request and get the sysop rights just as if they hacked to active user.
Not all wikis blindly give the user their rights back when they do this "theatrical" based security model.
For this reason I think we should create a new extension auto sysop removal, which would remove the flag from all users who didn't login to system for some time,
There is already one that does this from memory (Without checking, E:LandLord)
and if they logged back, the confirmation code would be sent to email, so that they could reactivate the sysop account.
Again, Just theatrical security, Most people tend to use the same passwords everywhere, if this was the case for said Sysop, Their email is also compromised. Also this would require wikis to have email sending setup, as well as the user to have confirmed theirs.
This would be much simpler and it would actually make hacking to sysop accounts much harder.
Not really, per my point above.
On Wed, Apr 4, 2012 at 5:54 PM, Petr Bena benapetr@gmail.com wrote:
More:
IP addresses which do N bad login attemps should be blocked from accessing login page for Z minutes (You have done too many bad login attempts, please wait 5 minutes before trying again) This would help to avoid bots who try to compromise account by trying random passwords
We already do this, I believe.
The target user should be notified according to their personal config (They could specify if they want to be warned if someone is about to compromise their account or not)
Pointless user prefernce IMHO, we should just send them (for wikis that have email setup) and probably inculde a note along the lines of "You should consider making sure your password is secure, some handy hints are…"
On Wed, Apr 4, 2012 at 6:16 PM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
There's no point in making technical solutions for problems which are imaginary in the first place, just as you say. The English Wikipedia community rejects the notion that sysop inactivity is a problem quite firmly, and it does just fine. Meta, Commons, my home Hebrew Wikipedia and some other projects do have such rules, and they are completely pointless.
En.Wiki does de-Sysop inactivtive accounts now.
On 4 April 2012 18:19, K. Peachey p858snake@gmail.com wrote:
On Wed, Apr 4, 2012 at 5:54 PM, Petr Bena benapetr@gmail.com wrote: More:
IP addresses which do N bad login attemps should be blocked from accessing login page for Z minutes (You have done too many bad login attempts, please wait 5 minutes before trying again) This would help to avoid bots who try to compromise account by trying random passwords
We already do this, I believe.
I believe it's covered through this: https://www.mediawiki.org/wiki/Manual:$wgPasswordAttemptThrottle
On Wed, Apr 4, 2012 at 10:19 AM, K. Peachey p858snake@gmail.com wrote:
On Wed, Apr 4, 2012 at 5:43 PM, Petr Bena benapetr@gmail.com wrote:
I have seen there is a lot of wikis where people are concerned about inactive sysops. They managed to set up a strange rule where sysop rights are removed from inactive users to improve the security. However the sysops are allowed to request the flag to be restored anytime. This doesn't improve security even a bit as long as hacker who would get to some of inactive accounts could just post a request and get the sysop rights just as if they hacked to active user.
Not all wikis blindly give the user their rights back when they do this "theatrical" based security model.
For this reason I think we should create a new extension auto sysop removal, which would remove the flag from all users who didn't login to system for some time,
There is already one that does this from memory (Without checking, E:LandLord)
and if they logged back, the confirmation code would be sent to email, so that they could reactivate the sysop account.
Again, Just theatrical security, Most people tend to use the same passwords everywhere, if this was the case for said Sysop, Their email is also compromised. Also this would require wikis to have email sending setup, as well as the user to have confirmed theirs.
That's the problem of user if they use same password, but I believe that any users with any sense for security don't do that, sysops could be instructed to use different password than in their email.
This would be much simpler and it would actually make hacking to sysop accounts much harder.
Not really, per my point above.
It would per my point above your point.
On Wed, Apr 4, 2012 at 5:54 PM, Petr Bena benapetr@gmail.com wrote:
The target user should be notified according to their personal config (They could specify if they want to be warned if someone is about to compromise their account or not)
Pointless user prefernce IMHO, we should just send them (for wikis that have email setup) and probably inculde a note along the lines of "You should consider making sure your password is secure, some handy hints are…"
What is pointless on that, I believe many users would like to be informed that they are target of some hacker. Even providing information to identify them (to checkuser for example) like ip address, would be usefull to eliminate them somehow. If they don't like it, they can turn it off.
Again, Just theatrical security, Most people tend to use the same passwords everywhere, if this was the case for said Sysop, Their email is also compromised. Also this would require wikis to have email sending setup, as well as the user to have confirmed theirs.
That's the problem of user if they use same password, but I believe that any users with any sense for security don't do that, sysops could be instructed to use different password than in their email.
This would be much simpler and it would actually make hacking to sysop accounts much harder.
Not really, per my point above.
It would per my point above your point.
The problem here is that it doesn't really discuss how a sysop account has been compromised; via the email account? Via some more direct method?
As pointed out it is somewhat security theatre.
Besides; you're looking for a problem to fit the solution. On English Wikipedia compromised accounts are, in themselves, rare occurrences. And compromised sysop accounts rarer (read; I've never seen one!).
We discussed this at length when implementing the age-desysoping, and agreed it wasn't an entirely failsafe method against compromise. But it does provide a level of scrutiny to a returning sysop; and really that is all that is needed. The amount of damage a compromised sysop account could do isn't critical and they can be stopped relatively easily - if they have scrutiny.
This is the best form of security.
Tom
The accounts could be compromised just using a brute force attacks which would be running for a long time. Since user would never know their account is being cracked, they would likely never bother with making their password more strong, neither report it somewhere. If I was an inactive sysop and I received a message that someone has done 500 000 login attempts over night, I would likely ask some bureaucrat to remove my sysop flag, since I don't even need it.
That's not possible now.
Regarding the hacked accounts, there were some in past, there was evidence of that on english wikipedia AFAIK. I still don't see "damage is not so big" as reason to drop work on improving the security.
On Wed, Apr 4, 2012 at 10:39 AM, Thomas Morton morton.thomas@googlemail.com wrote:
Again, Just theatrical security, Most people tend to use the same passwords everywhere, if this was the case for said Sysop, Their email is also compromised. Also this would require wikis to have email sending setup, as well as the user to have confirmed theirs.
That's the problem of user if they use same password, but I believe that any users with any sense for security don't do that, sysops could be instructed to use different password than in their email.
This would be much simpler and it would actually make hacking to sysop accounts much harder.
Not really, per my point above.
It would per my point above your point.
The problem here is that it doesn't really discuss how a sysop account has been compromised; via the email account? Via some more direct method?
As pointed out it is somewhat security theatre.
Besides; you're looking for a problem to fit the solution. On English Wikipedia compromised accounts are, in themselves, rare occurrences. And compromised sysop accounts rarer (read; I've never seen one!).
We discussed this at length when implementing the age-desysoping, and agreed it wasn't an entirely failsafe method against compromise. But it does provide a level of scrutiny to a returning sysop; and really that is all that is needed. The amount of damage a compromised sysop account could do isn't critical and they can be stopped relatively easily - if they have scrutiny.
This is the best form of security.
Tom _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 04/04/12 10:47, Petr Bena wrote:
The accounts could be compromised just using a brute force attacks which would be running for a long time. Since user would never know their account is being cracked, they would likely never bother with making their password more strong, neither report it somewhere. If I was an inactive sysop and I received a message that someone has done 500 000 login attempts over night, I would likely ask some bureaucrat to remove my sysop flag, since I don't even need it.
Many people would complain that wikipedia is spamming them... and do nothing. Note that there's no way to stop an ip from trying to login. I think login failures are aggregated in some server, the sysadmins should be able to detect from there a bruteforce attempt and ban the ips at the squids. I don't know if there's such alarm implemented, though.
I said it would be opt-in so they wouldn't be spammed unless they would like to be
On Wed, Apr 4, 2012 at 2:36 PM, Platonides Platonides@gmail.com wrote:
On 04/04/12 10:47, Petr Bena wrote:
The accounts could be compromised just using a brute force attacks which would be running for a long time. Since user would never know their account is being cracked, they would likely never bother with making their password more strong, neither report it somewhere. If I was an inactive sysop and I received a message that someone has done 500 000 login attempts over night, I would likely ask some bureaucrat to remove my sysop flag, since I don't even need it.
Many people would complain that wikipedia is spamming them... and do nothing. Note that there's no way to stop an ip from trying to login. I think login failures are aggregated in some server, the sysadmins should be able to detect from there a bruteforce attempt and ban the ips at the squids. I don't know if there's such alarm implemented, though.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Apr 4, 2012 at 8:33 AM, Petr Bena benapetr@gmail.com wrote:
I said it would be opt-in so they wouldn't be spammed unless they would like to be
I would like to remind everyone that user preferences are evil--especially when it comes to things relating to security.
The correct thing to do is to come up with sensible defaults that work for everyone.
-Chad
Why is it evil?
On Wed, Apr 4, 2012 at 2:35 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Apr 4, 2012 at 8:33 AM, Petr Bena benapetr@gmail.com wrote:
I said it would be opt-in so they wouldn't be spammed unless they would like to be
I would like to remind everyone that user preferences are evil--especially when it comes to things relating to security.
The correct thing to do is to come up with sensible defaults that work for everyone.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benapetr@gmail.com wrote:
Why is it evil?
Bluntly? Users, for the most part, are stupid. Or rather, they make silly choices that can make systems more vulnerable without knowing better.
That sounds like as microsoft would interpret how perfect system should work, and why I don't like windows:
"We know best what the user wants, so let us configure the system according to what we think that is best for them, without even giving them option to change anything on that"
Seriously, don't make microsoft windows from mediawiki, please. We could as well make mediawiki do what it "thinks that user wants to do" rather than "what user really wants"
On Wed, Apr 4, 2012 at 4:24 PM, OQ overlordq@gmail.com wrote:
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benapetr@gmail.com wrote:
Why is it evil?
Bluntly? Users, for the most part, are stupid. Or rather, they make silly choices that can make systems more vulnerable without knowing better.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Also keep in mind we are talking about accounts which are interesting for hackers, stewards and such. I hope that people who are volunteering as stewards aren't just "stupid" and would eventually read manual / ask someone who knows how does it work, before changing options in insecure way. (Anyway if it was opt-in it would be either more secure or same insecure as it's now)
On Wed, Apr 4, 2012 at 4:35 PM, Petr Bena benapetr@gmail.com wrote:
That sounds like as microsoft would interpret how perfect system should work, and why I don't like windows:
"We know best what the user wants, so let us configure the system according to what we think that is best for them, without even giving them option to change anything on that"
Seriously, don't make microsoft windows from mediawiki, please. We could as well make mediawiki do what it "thinks that user wants to do" rather than "what user really wants"
On Wed, Apr 4, 2012 at 4:24 PM, OQ overlordq@gmail.com wrote:
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benapetr@gmail.com wrote:
Why is it evil?
Bluntly? Users, for the most part, are stupid. Or rather, they make silly choices that can make systems more vulnerable without knowing better.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Let me clarify: we are talking about accounts which are interesting for hackers such as these of stewards.
I didn't want to compare stewards to hackers :-)
On Wed, Apr 4, 2012 at 4:40 PM, Petr Bena benapetr@gmail.com wrote:
Also keep in mind we are talking about accounts which are interesting for hackers, stewards and such. I hope that people who are volunteering as stewards aren't just "stupid" and would eventually read manual / ask someone who knows how does it work, before changing options in insecure way. (Anyway if it was opt-in it would be either more secure or same insecure as it's now)
On Wed, Apr 4, 2012 at 4:35 PM, Petr Bena benapetr@gmail.com wrote:
That sounds like as microsoft would interpret how perfect system should work, and why I don't like windows:
"We know best what the user wants, so let us configure the system according to what we think that is best for them, without even giving them option to change anything on that"
Seriously, don't make microsoft windows from mediawiki, please. We could as well make mediawiki do what it "thinks that user wants to do" rather than "what user really wants"
On Wed, Apr 4, 2012 at 4:24 PM, OQ overlordq@gmail.com wrote:
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benapetr@gmail.com wrote:
Why is it evil?
Bluntly? Users, for the most part, are stupid. Or rather, they make silly choices that can make systems more vulnerable without knowing better.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Apr 5, 2012 at 12:42 AM, Petr Bena benapetr@gmail.com wrote:
Let me clarify: we are talking about accounts which are interesting for hackers such as these of stewards.
Really? You're clearly designing a system targeting inactive sysops who disappear, but it doesnt seem suitable for inactive stewards who disappear. The former happens and nobody notices or cares, whereas the latter rarely happens without anyone noticing/caring, and never happens for more than a year because of steward re-elections.
Unless the software is going to poll stewards who have been inactive for a month or two, it wont be more effective than the current system, and the current system of steward re-elections isnt replaceable with your design (or any other software solution).
That was just an example, interesting are of course even checkuser accounts and such. I don't see any reason why system which notify you that someone is trying to login as you is something bad for stewards.
On Fri, Apr 13, 2012 at 7:17 AM, John Vandenberg jayvdb@gmail.com wrote:
On Thu, Apr 5, 2012 at 12:42 AM, Petr Bena benapetr@gmail.com wrote:
Let me clarify: we are talking about accounts which are interesting for hackers such as these of stewards.
Really? You're clearly designing a system targeting inactive sysops who disappear, but it doesnt seem suitable for inactive stewards who disappear. The former happens and nobody notices or cares, whereas the latter rarely happens without anyone noticing/caring, and never happens for more than a year because of steward re-elections.
Unless the software is going to poll stewards who have been inactive for a month or two, it wont be more effective than the current system, and the current system of steward re-elections isnt replaceable with your design (or any other software solution).
-- John Vandenberg
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 13, 2012 at 3:56 PM, Petr Bena benapetr@gmail.com wrote:
That was just an example, interesting are of course even checkuser accounts and such. I don't see any reason why system which notify you that someone is trying to login as you is something bad for stewards.
That feature would be awesome.
https://bugzilla.wikimedia.org/show_bug.cgi?id=9838
Yes, that is what I just tried to propose in second email :-) I see I am not the only one who believe we need it
On Fri, Apr 13, 2012 at 8:33 AM, John Vandenberg jayvdb@gmail.com wrote:
On Fri, Apr 13, 2012 at 3:56 PM, Petr Bena benapetr@gmail.com wrote:
That was just an example, interesting are of course even checkuser accounts and such. I don't see any reason why system which notify you that someone is trying to login as you is something bad for stewards.
That feature would be awesome.
https://bugzilla.wikimedia.org/show_bug.cgi?id=9838
-- John Vandenberg
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 4 April 2012 15:40, Petr Bena benapetr@gmail.com wrote:
Also keep in mind we are talking about accounts which are interesting for hackers, stewards and such. I hope that people who are volunteering as stewards aren't just "stupid" and would eventually read manual / ask someone who knows how does it work, before changing options in insecure way. (Anyway if it was opt-in it would be either more secure or same insecure as it's now)
Traditionally; the more technically literate a user is, the worse his/her security regime tends to be.
For example; my security regime - a programmer & security consultant - is fairly bad.
Tom
OK, but this is a new option which doesn't exist now, and if it could be turned off, it wouldn't affect the security more than making it just same as it's now. The reason why it should be in preferences is that some users might want it and some would rather not have it. (In fact as default this should be disabled, it's advanced feature for users with risky accounts, like sysops). I am talking about email warning when someone is trying to hack in your account. The auto sysop removal and such should no way be in user preferences.
On Wed, Apr 4, 2012 at 4:56 PM, Thomas Morton morton.thomas@googlemail.com wrote:
On 4 April 2012 15:40, Petr Bena benapetr@gmail.com wrote:
Also keep in mind we are talking about accounts which are interesting for hackers, stewards and such. I hope that people who are volunteering as stewards aren't just "stupid" and would eventually read manual / ask someone who knows how does it work, before changing options in insecure way. (Anyway if it was opt-in it would be either more secure or same insecure as it's now)
Traditionally; the more technically literate a user is, the worse his/her security regime tends to be.
For example; my security regime - a programmer & security consultant - is fairly bad.
Tom _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 4 April 2012 15:35, Petr Bena benapetr@gmail.com wrote:
That sounds like as microsoft would interpret how perfect system should work, and why I don't like windows:
"We know best what the user wants, so let us configure the system according to what we think that is best for them, without even giving them option to change anything on that"
Seriously, don't make microsoft windows from mediawiki, please. We could as well make mediawiki do what it "thinks that user wants to do" rather than "what user really wants"
Actually; what he is describing is super-serious security 101.
Users are always a major security flaw in any system, and leaving security options up the them increases your attack vector (i.e; most people don't use Gmail 2 factor authentication, because it is a pain).
There is a reason Microsoft (successfully) makes use of this model. As does most modern Linux distro's, Mac OSX, etc etc. The key is getting a balance between sane defaults and advanced configuration for those with proven responsibility to understand their own security.
If you make it *easy* for an individual to disable a key security feature then your security effectively becomes useless.
Tom
On Wed, Apr 4, 2012 at 10:24 AM, OQ overlordq@gmail.com wrote:
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benapetr@gmail.com wrote:
Why is it evil?
Bluntly? Users, for the most part, are stupid. Or rather, they make silly choices that can make systems more vulnerable without knowing better.
There's that. There's also the "adding preferences adds to the overall complexity of the system."
-Chad
That's something 1 group of people agree and another strongly disagree
Let's make both, if you really want simple preferences, why not to have "advanced" toggle, which uncover the complex stuff?
On Wed, Apr 4, 2012 at 5:45 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Apr 4, 2012 at 10:24 AM, OQ overlordq@gmail.com wrote:
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benapetr@gmail.com wrote:
Why is it evil?
Bluntly? Users, for the most part, are stupid. Or rather, they make silly choices that can make systems more vulnerable without knowing better.
There's that. There's also the "adding preferences adds to the overall complexity of the system."
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Apr 4, 2012 at 11:48 AM, Petr Bena benapetr@gmail.com wrote:
That's something 1 group of people agree and another strongly disagree
Let's make both, if you really want simple preferences, why not to have "advanced" toggle, which uncover the complex stuff?
Because we've been over this time and time again as a community[0][1] and the consensus is always against adding additional preferences if we can avoid it.
-Chad
[0] http://lists.wikimedia.org/pipermail/wikitech-l/2006-December/028158.html [1] http://lists.wikimedia.org/pipermail/wikitech-l/2007-March/030298.html
On 4 April 2012 09:39, Thomas Morton morton.thomas@googlemail.com wrote:
Besides; you're looking for a problem to fit the solution. On English Wikipedia compromised accounts are, in themselves, rare occurrences. And compromised sysop accounts rarer (read; I've never seen one!).
There was a noteworthy incident a while ago, which pressed home the need for admins to have non-crappy passwords:
http://davidgerard.co.uk/notes/2007/05/07/tubgirl-is-love/
- d.
wikitech-l@lists.wikimedia.org