On Fri, Apr 13, 2012 at 3:56 PM, Petr Bena benap...@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
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 jay...@gmail.com wrote:
On Fri, Apr 13, 2012 at 3:56 PM, Petr Bena benap...@gmail.com wrote:
That was just an example, interesting
Στις 13-04-2012, ημέρα Παρ, και ώρα 12:49 +1000, ο/η Andrew Garrett
έγραψε:
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benap...@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
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
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 agarr...@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
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benap...@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
2012/4/13 Andrew Garrett agarr...@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?
--
Bináris
___
Wikitech-l mailing list
On Thu, Apr 5, 2012 at 12:42 AM, Petr Bena benap...@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
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 jay...@gmail.com wrote:
On Thu, Apr 5,
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
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
On Wed, Apr 4, 2012 at 5:43 PM, Petr Bena benap...@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
2012/4/4 Petr Bena benap...@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
On Wed, Apr 4, 2012 at 5:43 PM, Petr Bena benap...@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
On Wed, Apr 4, 2012 at 10:15 AM, John Vandenberg jay...@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
On 4 April 2012 18:19, K. Peachey p858sn...@gmail.com wrote:
On Wed, Apr 4, 2012 at 5:54 PM, Petr Bena benap...@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
On Wed, Apr 4, 2012 at 10:19 AM, K. Peachey p858sn...@gmail.com wrote:
On Wed, Apr 4, 2012 at 5:43 PM, Petr Bena benap...@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
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
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
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benap...@gmail.com wrote:
On Wed, Apr 4, 2012 at 10:15 AM, John Vandenberg jay...@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
2012/4/4 John Vandenberg jay...@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
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
On Wed, Apr 4, 2012 at 7:12 PM, Petr Bena benap...@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
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
On 4 April 2012 10:21, Petr Bena benap...@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
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.tho...@googlemail.com wrote:
On 4 April
On 4 April 2012 10:28, Petr Bena benap...@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
On Wed, Apr 4, 2012 at 7:28 PM, Petr Bena benap...@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
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
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
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
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
On 4 April 2012 09:39, Thomas Morton morton.tho...@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
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
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...)?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Wed, 04 Apr 2012 04:31:02 -0700, Petr Bena
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
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 platoni...@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
On Wed, Apr 4, 2012 at 8:33 AM, Petr Bena benap...@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
Why is it evil?
On Wed, Apr 4, 2012 at 2:35 PM, Chad innocentkil...@gmail.com wrote:
On Wed, Apr 4, 2012 at 8:33 AM, Petr Bena benap...@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
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benap...@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
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,
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
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 benap...@gmail.com wrote:
Also keep in mind we are talking about accounts which are interesting
On 4 April 2012 15:35, Petr Bena benap...@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
On 4 April 2012 15:40, Petr Bena benap...@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
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
On Wed, Apr 4, 2012 at 10:24 AM, OQ overlo...@gmail.com wrote:
On Wed, Apr 4, 2012 at 7:38 AM, Petr Bena benap...@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'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 innocentkil...@gmail.com wrote:
On Wed, Apr 4, 2012 at 10:24 AM,
On Wed, Apr 4, 2012 at 11:48 AM, Petr Bena benap...@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
On Wed, Apr 4, 2012 at 7:53 AM, Daniel Friesen
li...@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.
51 matches
Mail list logo
