On Sat, Aug 24, 2013 at 10:05 AM, Tyler Romeo tylerro...@gmail.com wrote:
On Sat, Aug 24, 2013 at 12:50 PM, Seb35 seb35wikipe...@gmail.com wrote:
An other solution is the use of one-time passwords [1] for high-security
or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser
On Mon, Aug 26, 2013 at 11:50 AM, Chris Steipp cste...@wikimedia.orgwrote:
One piece I wasn't able to get into our Auth
rework this summer was having 2-step login, so that we could require OATH
for some people, but normal users wouldn't have to. But yeah,
Yeah...that's a little bit of my
Brion wrote
* stop exposing IP addresses of any users at all (whether logged-in or
anonymous)
+1
replace IP editing with a simple solution for creating a consistent
anonymous identity with a minimum of effort (for example, automatically
create an ID cookie which links to an anonymous 'account'
Le Sat, 24 Aug 2013 00:45:05 +0200, Tyler Romeo tylerro...@gmail.com a
écrit:
Unfortunately it's very difficult to do this. On our login forms you
enter
your username and password simultaneously, which means the server can't
possibly know if the user has to be using HTTPS until they've
On Sat, Aug 24, 2013 at 12:50 PM, Seb35 seb35wikipe...@gmail.com wrote:
An other solution is the use of one-time passwords [1] for high-security
or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser
action). Such one-time passwords can be generated entirely on the client
side
Le Sat, 24 Aug 2013 19:05:38 +0200, Tyler Romeo tylerro...@gmail.com a
écrit:
On Sat, Aug 24, 2013 at 12:50 PM, Seb35 seb35wikipe...@gmail.com wrote:
An other solution is the use of one-time passwords [1] for high-security
or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser
On Friday, August 23, 2013, Brion Vibber wrote:
On Fri, Aug 23, 2013 at 4:38 PM, Tilman Bayer
tba...@wikimedia.orgjavascript:;
wrote:
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber
bvib...@wikimedia.orgjavascript:;
wrote:
I'd recommend some out-of-the-box thinking instead,
Hi all,
With all the talk about turning on $wgSecureLogin for WMF sites, there has
been a lot of misconceptions about how the option works, and difference of
opinions about how they should work in the future.
I started:
https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
It would
- Should MediaWiki support allowing some users to use http for their
login, while most users use https? If yes, what are reasonable criteria for
determining who can use http (e.g., user groups, GeoIP, or some other
criteria)?
I don't have an answer for this, but if it is done
On Aug 23, 2013 7:46 PM, Chris Steipp cste...@wikimedia.org wrote:
Hi all,
With all the talk about turning on $wgSecureLogin for WMF sites, there has
been a lot of misconceptions about how the option works, and difference of
opinions about how they should work in the future.
I started:
On Fri, Aug 23, 2013 at 10:46 AM, Chris Steipp cste...@wikimedia.org wrote:
With all the talk about turning on $wgSecureLogin for WMF sites, there has
been a lot of misconceptions about how the option works, and difference of
opinions about how they should work in the future.
I started:
On 08/23/2013 02:36 PM, Tyler Romeo wrote:
You mean like my $wgSecureGroups approach? Because if people actually still
want that I can attempt to revive that part of my patch. I think it'd be of
especial interest to require HTTPS for checkusers and oversight people, due
to the legal problems
On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
Requiring https for advanced privileges seems odd. Would that require a
second set of credentials over a https only page?
You're missing the point. People who have (for instance) checkuser or
oversight should be simply disallowed from logging in
On 23 August 2013 21:28, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
Requiring https for advanced privileges seems odd. Would that require a
second set of credentials over a https only page?
You're missing the point. People who have (for
On 23 August 2013 16:25, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 02:36 PM, Tyler Romeo wrote:
You mean like my $wgSecureGroups approach? Because if people actually
still
want that I can attempt to revive that part of my patch. I think it'd be
of
especial interest to
On 08/23/2013 04:35 PM, Risker wrote:
I'd like to see what can be developed, however, to support
Checkusers/Oversighters/Stewards who have difficulty using HTTPS
Pretty much by definition the accounts holding those bits are the one we
/least/ want to have their password snooped, and the ones
On 23 August 2013 17:10, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 04:35 PM, Risker wrote:
I'd like to see what can be developed, however, to support
Checkusers/Oversighters/Stewards who have difficulty using HTTPS
Pretty much by definition the accounts holding those bits are
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker...@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those geographical regions from serving Wikimedia communities. A decision
to
On Fri, Aug 23, 2013 at 6:16 PM, Ryan Lane rlan...@gmail.com wrote:
Well, it's also possible that you're just not having clever enough ideas,
eh? ;)
True, but to be honest, if we come up with a clever enough idea, from
China's perspective that's just us getting around their security, which
On 23 August 2013 18:13, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker...@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those
On 23 August 2013 23:31, Risker risker...@gmail.com wrote:
There are other options. The question is whether or not they can be made to
work in the MediaWiki/WMF circumstances. If you looked at the data
collected to see where HTTPS attempts were unsuccessful, you'd see that
there are editors
On Fri, Aug 23, 2013 at 6:35 PM, David Gerard dger...@gmail.com wrote:
And until then, it actually needs to be HTTPS-only. I'm horrified it
isn't already.
Also, now would be a good time to mention that it is impossible to force
HTTPS login for checkusers due to the current GeoIP solution that
So, some ideas:
As for the idea that we need to fix internet that's so bad it can't handle
HTTPS for technical reasons; anything that's that broken is pretty
hopeless to fix from the web server's end. Instead, consider:
* provide support to groups working for improving internet access in areas
On 23 August 2013 18:35, David Gerard dger...@gmail.com wrote:
On 23 August 2013 23:31, Risker risker...@gmail.com wrote:
There are other options. The question is whether or not they can be made
to
work in the MediaWiki/WMF circumstances. If you looked at the data
collected to see where
On Fri, Aug 23, 2013 at 6:43 PM, Risker risker...@gmail.com wrote:
Well, I'm not terribly technical, but I don't think there's ever been
consideration of linking login requirements to user permissions. Perhaps
that needs to change. I'm concerned too.
Unfortunately it's very difficult to do
On 23 August 2013 18:42, Brion Vibber bvib...@wikimedia.org wrote:
So, some ideas:
snip
And for the some countries block our HTTPS issue:
* *actually support* use of Tor etc for editing, allowing folks in the
know to work around the government blocks and use the site over HTTPS
snip
On Fri, Aug 23, 2013 at 3:47 PM, Risker risker...@gmail.com wrote:
Just for the record, anyone at administrator level or higher has IPBE built
into their tools (I believe on all projects), so they can
edit/administer/checkuser/etc using Tor.
But given that over 95% of anything that comes
On 08/23/2013 05:33 PM, Risker wrote:
there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those geographical regions from serving Wikimedia communities
Interesting. Would you care to share with whom that offline
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber bvib...@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:47 PM, Risker risker...@gmail.com wrote:
Just for the record, anyone at administrator level or higher has IPBE built
into their tools (I believe on all projects), so they can
On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
Would you care to share with whom that offline discussion
is happening?
... and, more importantly, /why/ is that discussion taking place offline
in the first place?
-- Marc
___
Wikitech-l mailing
On Fri, Aug 23, 2013 at 3:43 PM, Risker risker...@gmail.com wrote:
No it doesn't change the security consideration. What changes is the
recognition that the problem may actually be bigger than initially thought.
Everyone knew about China and Iran. Probably nobody knew about Pakistan,
On Fri, Aug 23, 2013 at 4:38 PM, Tilman Bayer tba...@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber bvib...@wikimedia.org
wrote:
I would strongly recommend a saner signup/account moderation system for
less trusted network origins such as Tor nodes, though. The key is
On 23 August 2013 19:40, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
Would you care to share with whom that offline discussion
is happening?
... and, more importantly, /why/ is that discussion taking place offline
in the first place?
As you
On 23 August 2013 19:55, Rob Lanphier ro...@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:43 PM, Risker risker...@gmail.com wrote:
No it doesn't change the security consideration. What changes is the
recognition that the problem may actually be bigger than initially
thought.
Everyone
Tim Starling wrote:
The test used upload.wikimedia.org, at a time when the
browser would already have a keepalive connection open to port 80 but
not port 443. Client-side aborts caused by navigating away from the
page are not logged, and so if the HTTP request completes earlier than
the HTTPS
35 matches
Mail list logo
