Meta discussions over community, Appreciation threads, GSoC wrapups, Deployment threads, and orthogonal questions. Lately wikitech-l seems to be almost void of one of the most important categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just like Sumana's "Appreciation thread" how about a little thread dedicated to listing out things we'd like to see in MediaWiki or perhaps would like to write ourselves. Not really big things like VisualEditor, Wikidata, and Lua who have teams of people within WMF working on them. But rather those other important things a lot of us may want but always end up pushed to the side and forgotten.
For me... Before I list the small stuff here are 3 big projects right now I wish I could work on but won't possibly have the time unless I find someone willing to pay me enough to drop a normal job an dedicate my programming time to writing things for MediaWiki: - Gareth: It's not exactly a MediaWiki feature. But with the Gerrit annoyances and talk about other review systems I've had a really good idea how to do a review system right this time around. It would be nice to spend a pile of time turning it into a system that we could actually use for our code review. - OAuth: Well not actually OAuth. After getting a full understanding of this topic implementation of actual OAuth (1&2) looks like a dark dead-end. Rather than OAuth I'd like to write a new auth standard that learns from all the good things and the mistakes made in both versions of OAuth and takes note of all the things we really need. And then implement it into MediaWiki and write a series of server and client libraries/sdks so it's also easier to pick up than either OAuth. - Machine-Learning based Anti-spam: Wikipedia has bots like ClueBot NG dealing with spam. It would be nice to have machine-learning based anti-spam built into a MediaWiki extension with a nice intuitive user interface usable outside of WMF so all wikis can have great anti-spam.
Now some old and forgotten code topics: - 404 routing: I'd like us to get to the point where we can set ErrorDocument 404 /w/index.php and MediaWiki will automatically start doing short urls, outputting 404 pages for you, and acting as an implicit thumbnail handler. - Title rewrite: Aaaaincient topic... updating our handling of the page table and titles in general so that the case, whitespace, and all the stuff in a title that just get's normalized away is correctly remembered. So that [[iPod]], even though it's the same as [[IPod]] will always display as "iPod" even in lists outside of the page itself such as Special:Allpages - Password reset tokens: It's unbelievable but we are STILL using temporary passwords instead of reset tokens. Naturally this is less usable and also lowers the security of our password reset system. - An abstract revision system. The way we shove configuration into i18n, i18n into articles, scripts and stylesheets into articles, and extensions go and do the same. All just to get proper revisioning of things. Is horrible. Not to mention the extensions that don't and rely on our logging system which makes it harder to revert things. With all this together I'd like to see an abstract system that lets extensions have their own revision system outside of page content for whatever they need to do. ---- https://www.mediawiki.org/wiki/User:Dantman/Code_Ideas https://www.mediawiki.org/wiki/User:Dantman/Abstract_Revision_System https://www.mediawiki.org/wiki/User:Dantman/Code_Ideas/PageLayouts https://www.mediawiki.org/wiki/User:Dantman/Anti-spam_system https://www.mediawiki.org/wiki/Requests_for_comment/Entrypoint_Routing_and_4... https://www.mediawiki.org/wiki/User:Dantman/CodeReviewSystem and http://gareth-review.com/
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic
implementation of actual OAuth (1&2) looks like a dark dead-end. Rather
than OAuth I'd like
to write a new auth standard that learns from all the good things and
the mistakes made in
both versions of OAuth and takes note of all the things we really need.
And then implement it
into MediaWiki and write a series of server and client libraries/sdks so
it's also easier to pick
up than either OAuth.
Not a good idea: http://xkcd.com/927/ While OAuth has its problems, it's not a terrible protocol (or at least v1 isn't).
Password reset tokens: It's unbelievable but we are STILL using temporary
passwords
instead of reset tokens. Naturally this is less usable and also lowers
the security of our
password reset system.
My focus lately has been on security, so I may take this on in the near future.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 24, 2012 at 1:05 PM, Daniel Friesen daniel@nadir-seen-fire.comwrote:
Meta discussions over community, Appreciation threads, GSoC wrapups, Deployment threads, and orthogonal questions. Lately wikitech-l seems to be almost void of one of the most important categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just like Sumana's "Appreciation thread" how about a little thread dedicated to listing out things we'd like to see in MediaWiki or perhaps would like to write ourselves. Not really big things like VisualEditor, Wikidata, and Lua who have teams of people within WMF working on them. But rather those other important things a lot of us may want but always end up pushed to the side and forgotten.
For me... Before I list the small stuff here are 3 big projects right now I wish I could work on but won't possibly have the time unless I find someone willing to pay me enough to drop a normal job an dedicate my programming time to writing things for MediaWiki:
- Gareth: It's not exactly a MediaWiki feature. But with the Gerrit
annoyances and talk about other review systems I've had a really good idea how to do a review system right this time around. It would be nice to spend a pile of time turning it into a system that we could actually use for our code review.
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic implementation of actual OAuth (1&2) looks like a dark dead-end. Rather than OAuth I'd like to write a new auth standard that learns from all the good things and the mistakes made in both versions of OAuth and takes note of all the things we really need. And then implement it into MediaWiki and write a series of server and client libraries/sdks so it's also easier to pick up than either OAuth.
- Machine-Learning based Anti-spam: Wikipedia has bots like ClueBot NG
dealing with spam. It would be nice to have machine-learning based anti-spam built into a MediaWiki extension with a nice intuitive user interface usable outside of WMF so all wikis can have great anti-spam.
Now some old and forgotten code topics:
- 404 routing: I'd like us to get to the point where we can set
ErrorDocument 404 /w/index.php and MediaWiki will automatically start doing short urls, outputting 404 pages for you, and acting as an implicit thumbnail handler.
- Title rewrite: Aaaaincient topic... updating our handling of the page
table and titles in general so that the case, whitespace, and all the stuff in a title that just get's normalized away is correctly remembered. So that [[iPod]], even though it's the same as [[IPod]] will always display as "iPod" even in lists outside of the page itself such as Special:Allpages
- Password reset tokens: It's unbelievable but we are STILL using
temporary passwords instead of reset tokens. Naturally this is less usable and also lowers the security of our password reset system.
- An abstract revision system. The way we shove configuration into i18n,
i18n into articles, scripts and stylesheets into articles, and extensions go and do the same. All just to get proper revisioning of things. Is horrible. Not to mention the extensions that don't and rely on our logging system which makes it harder to revert things. With all this together I'd like to see an abstract system that lets extensions have their own revision system outside of page content for whatever they need to do.
https://www.mediawiki.org/**wiki/User:Dantman/Code_Ideashttps://www.mediawiki.org/wiki/User:Dantman/Code_Ideas https://www.mediawiki.org/**wiki/User:Dantman/Abstract_**Revision_Systemhttps://www.mediawiki.org/wiki/User:Dantman/Abstract_Revision_System https://www.mediawiki.org/**wiki/User:Dantman/Code_Ideas/**PageLayoutshttps://www.mediawiki.org/wiki/User:Dantman/Code_Ideas/PageLayouts https://www.mediawiki.org/**wiki/User:Dantman/Anti-spam_**systemhttps://www.mediawiki.org/wiki/User:Dantman/Anti-spam_system https://www.mediawiki.org/**wiki/Requests_for_comment/** Entrypoint_Routing_and_404_**handlinghttps://www.mediawiki.org/wiki/Requests_for_comment/Entrypoint_Routing_and_404_handling https://www.mediawiki.org/**wiki/User:Dantman/**CodeReviewSystemhttps://www.mediawiki.org/wiki/User:Dantman/CodeReviewSystemand http://gareth-review.com/
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerromeo@gmail.com wrote:
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic
implementation of actual OAuth (1&2) looks like a dark dead-end. Rather
than OAuth I'd like
to write a new auth standard that learns from all the good things and
the mistakes made in
both versions of OAuth and takes note of all the things we really need.
And then implement it
into MediaWiki and write a series of server and client libraries/sdks so
it's also easier to pick
up than either OAuth.
Not a good idea: http://xkcd.com/927/ While OAuth has its problems, it's not a terrible protocol (or at least v1 isn't).
Seconded -- I'd rather see contributions to making OAuth less painful rather than invent Yet Another Standard.
My personal wishlist: - Persona: Previously called BrowserID. It's come a LONG way in the past few months, and provides another fairly clean identity/authentication system. - OpenBadges: I'd love to explore options for implementing an OpenBadges solution for MW -- methods to encourage good editing and contribution, and to identify those who have consistently demonstrated this capability seems pretty worthwhile.
Nabil
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadreck@gmail.com wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Not a good idea: http://xkcd.com/927/ While OAuth has its problems, it's not a terrible protocol (or at least v1 isn't).
Seconded -- I'd rather see contributions to making OAuth less painful rather than invent Yet Another Standard.
I have to agree too. OAuth has problems, but it would allow several of wmf's current integrations to be more secure overall, and that would be a win for us. If Daniel is able to create a protocol that is as secure, and easier for developers to use securely, then I will definitely push to switch over. But until then, I'm still going to try and get OAuth out.
I'd also love to see MediaWiki support SAML too, for our .edu/.gov users.
My personal wishlist:
- Persona: Previously called BrowserID. It's come a LONG way in the past
few months, and provides another fairly clean identity/authentication system.
Mozilla is also interested in this. I don't think we can use it on wmf sites, but if you're interested in working on it, I can probably get you in touch with someone there. I think it would be a great feature.
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp csteipp@wikimedia.org wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadreck@gmail.com wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Not a good idea: http://xkcd.com/927/ While OAuth has its problems, it's not a terrible protocol (or at least v1 isn't).
Randall is right in general about standards proliferation for standards sake. But that's primarily about just writing a standard for other people to use. If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already exists, etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in.
- OAuth 1 had some important issues too. In particular the temporary credentials and the limitations on the user experience caused by the single flow. - The flow limitations is probably a big one for us. And it is possible to work around the issue by separating OAuth into two parts. But by doing that you diverge from the spec and there isn't much more reason to stick with that standard. And afaik the libraries for doing OAuth 1 don't support these alternative types of flows.
Seconded -- I'd rather see contributions to making OAuth less painful rather than invent Yet Another Standard.
I have to agree too. OAuth has problems, but it would allow several of wmf's current integrations to be more secure overall, and that would be a win for us. If Daniel is able to create a protocol that is as secure, and easier for developers to use securely, then I will definitely push to switch over. But until then, I'm still going to try and get OAuth out.
Thanks. I already know what I have lying around in my head will keep OAuth 1 level security while making signatures easier to implement. Although the fundamental idea in this area is auth should always be done by a library/SDK anyways. The stuff making my head spin actually isn't even any part of the basic auth. It's not even discovery itself. The hardest thing to figure out is what to do about making discovery and dynamic registration over HTTP secure. Which frankly is something that no protocol has anyways.
The only problem with writing out an actual standard for the rest of the stuff is all my good hours are taken up by work. The leftovers wouldn't be enough to get out a good enough quality standard and reference/testing implementation.
Rather than jumping to "get OAuth out" what about first trying to get the fundamental base pieces we need for all of these into core. ie: Abstract authorizations and applications. Revocation pages. Attaching an authorization/application to changes like revisions, logs, etc... and tools to mass-revert by confidential application or multiple public authorizations. We'll need that stuff no matter what we implement. And it's going to take awhile just to implement those things. We can decide whether we want OAuth or something else when we finally get to that point.
I'd also love to see MediaWiki support SAML too, for our .edu/.gov users.
Did these organizations need to use those SAML credentials directly for API things or is this just another method we want to support for logging in?
My personal wishlist:
- Persona: Previously called BrowserID. It's come a LONG way in the
past few months, and provides another fairly clean identity/authentication system.
Mozilla is also interested in this. I don't think we can use it on wmf sites, but if you're interested in working on it, I can probably get you in touch with someone there. I think it would be a great feature.
Did these organizations need to use those SAML credentials directly for API things or is this just another method we want to support for logging in?
https://meta.wikimedia.org/wiki/Wikimedia_Fellowships/Project_Ideas/The_Wiki...
That's the biggest current reason for wanting to support SAML.
- Ryan
On Fri, 24 Aug 2012 15:10:55 -0700, Ryan Lane rlane32@gmail.com wrote:
Did these organizations need to use those SAML credentials directly for API things or is this just another method we want to support for logging in?
https://meta.wikimedia.org/wiki/Wikimedia_Fellowships/Project_Ideas/The_Wiki...
That's the biggest current reason for wanting to support SAML.
- Ryan
Oh... so not SAML logins or SAML assertions for the api but acting as a provider of SAML accounts for logging into a 3rd party source with a Wikipedia account?
Oh... so not SAML logins or SAML assertions for the api but acting as a provider of SAML accounts for logging into a 3rd party source with a Wikipedia account?
Yeah. It's the more interesting situation at first. I'm sure there are some interesting use cases the opposite way, but we have an immediate use case to act as an identity provider.
- Ryan
On Fri, 24 Aug 2012 14:14:30 -0700, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp csteipp@wikimedia.org wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadreck@gmail.com wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Not a good idea: http://xkcd.com/927/ While OAuth has its problems, it's not a terrible protocol (or at least v1 isn't).
Randall is right in general about standards proliferation for standards sake. But that's primarily about just writing a standard for other people to use. If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already exists, etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in.
- OAuth 1 had some important issues too. In particular the temporary
credentials and the limitations on the user experience caused by the single flow.
- The flow limitations is probably a big one for us. And it is possible
to work around the issue by separating OAuth into two parts. But by doing that you diverge from the spec and there isn't much more reason to stick with that standard. And afaik the libraries for doing OAuth 1 don't support these alternative types of flows.
Seconded -- I'd rather see contributions to making OAuth less painful rather than invent Yet Another Standard.
I have to agree too. OAuth has problems, but it would allow several of wmf's current integrations to be more secure overall, and that would be a win for us. If Daniel is able to create a protocol that is as secure, and easier for developers to use securely, then I will definitely push to switch over. But until then, I'm still going to try and get OAuth out.
Thanks. I already know what I have lying around in my head will keep OAuth 1 level security while making signatures easier to implement. Although the fundamental idea in this area is auth should always be done by a library/SDK anyways. The stuff making my head spin actually isn't even any part of the basic auth. It's not even discovery itself. The hardest thing to figure out is what to do about making discovery and dynamic registration over HTTP secure. Which frankly is something that no protocol has anyways.
The only problem with writing out an actual standard for the rest of the stuff is all my good hours are taken up by work. The leftovers wouldn't be enough to get out a good enough quality standard and reference/testing implementation.
I just spent two ENTIRE days in a trance with nothing but auth flows spinning around in my head. All I was able to get out in writing so far is this draft collection of high-level auth flows to aim to support. https://github.com/dantman/protoauth-spec/blob/master/auth-flows.md
Rather than jumping to "get OAuth out" what about first trying to get the fundamental base pieces we need for all of these into core. ie: Abstract authorizations and applications. Revocation pages. Attaching an authorization/application to changes like revisions, logs, etc... and tools to mass-revert by confidential application or multiple public authorizations. We'll need that stuff no matter what we implement. And it's going to take awhile just to implement those things. We can decide whether we want OAuth or something else when we finally get to that point.
I'd also love to see MediaWiki support SAML too, for our .edu/.gov users.
Did these organizations need to use those SAML credentials directly for API things or is this just another method we want to support for logging in?
My personal wishlist:
- Persona: Previously called BrowserID. It's come a LONG way in the
past few months, and provides another fairly clean identity/authentication system.
Mozilla is also interested in this. I don't think we can use it on wmf sites, but if you're interested in working on it, I can probably get you in touch with someone there. I think it would be a great feature.
On 8/24/12 12:33 PM, Nabil Maynard wrote:
My personal wishlist:
- Persona: Previously called BrowserID. It's come a LONG way in the past
few months, and provides another fairly clean identity/authentication system.
That's on Mozilla's wishlist, too!
For background, Persona is an open, decentralized identity system that tries to learn from and build on the foundation set by previous systems like OpenID.
Mozilla is using it in production on quite a few sites (MDN, Bugzilla, Mozillians, Marketplace, Firefox Affiliates, Popcorn, OpenBadges, etc), and we'd love to see Persona as an option for Mediawiki-based sites. Especially for wiki.mozilla.org.
From what I understand, one of the biggest hurdles is the account model. Persona replaces usernames and passwords with email addresses and cryptographic proofs of ownership. IIRC, MediaWiki doesn't necessarily collect email addresses for new accounts, so a plugin would have to have some sort of interactive migration built in for when a user first authenticates with Persona.
This isn't insurmountable (MDN dealt with a similar problem), but thus far a plugin hasn't materialized.
Our docs are at https://developer.mozilla.org, we hang out in #identity on irc.mozilla.org, and our mailing list is at https://lists.mozilla.org/listinfo/dev-identity
As a member of the Identity team at Mozilla, I'm also personally available to help out / answer any questions an implementer might have.
Cheers, -Dan
I also thought about implementing Persona (BrowserID) for user login. Although solving the "account model problem" by replacing email addresses with SUL usernames. :)
On 08/24/2012 01:33 PM, Nabil Maynard wrote:
- Persona: Previously called BrowserID. It's come a LONG way in the past
few months, and provides another fairly clean identity/authentication system.
As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla.
2012/8/26 Mark A. Hershberger mah@everybody.org:
On 08/24/2012 01:33 PM, Nabil Maynard wrote:
- Persona: Previously called BrowserID. It's come a LONG way in the past
few months, and provides another fairly clean identity/authentication system.
As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla.
+[[Crore]].
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already exists, etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in.
But the problem is that "it already exists" is in fact a valid reason to use a protocol. There are numerous libraries out there (including a PHP extension) that allow people to use OAuth to authenticate with services. Making our own protocol just makes it more difficult for application developers since, in addition to developing their application, they have to make their own client side functionality to fulfill our custom protocol. Furthermore, as I said before, OAuth 1 isn't bad. It provides for secure authentication and authorization of the client while protecting against replay attacks. Furthermore, I'd like to at least put some faith in the IETF, considering they are quite intelligent people, and not just toss out their protocol because it isn't "perfect" (quotes are intentional). If somebody wants to go ahead and make an extension for a custom authentication protocol, feel free to do so, but I still believe OAuth support should be our ultimate goal in terms of third-party application security.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Aug 26, 2012 at 2:38 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
2012/8/26 Mark A. Hershberger mah@everybody.org:
On 08/24/2012 01:33 PM, Nabil Maynard wrote:
- Persona: Previously called BrowserID. It's come a LONG way in the
past
few months, and provides another fairly clean identity/authentication system.
As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla.
+[[Crore]].
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, I have re-read the Wikipedia article about OpenID and OpenAuth.
OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already said too much about its need.
It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve? Thanks, GerardM
On 27 August 2012 01:48, Tyler Romeo tylerromeo@gmail.com wrote:
If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already
exists,
etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in.
But the problem is that "it already exists" is in fact a valid reason to use a protocol. There are numerous libraries out there (including a PHP extension) that allow people to use OAuth to authenticate with services. Making our own protocol just makes it more difficult for application developers since, in addition to developing their application, they have to make their own client side functionality to fulfill our custom protocol. Furthermore, as I said before, OAuth 1 isn't bad. It provides for secure authentication and authorization of the client while protecting against replay attacks. Furthermore, I'd like to at least put some faith in the IETF, considering they are quite intelligent people, and not just toss out their protocol because it isn't "perfect" (quotes are intentional). If somebody wants to go ahead and make an extension for a custom authentication protocol, feel free to do so, but I still believe OAuth support should be our ultimate goal in terms of third-party application security.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Aug 26, 2012 at 2:38 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
2012/8/26 Mark A. Hershberger mah@everybody.org:
On 08/24/2012 01:33 PM, Nabil Maynard wrote:
- Persona: Previously called BrowserID. It's come a LONG way in the
past
few months, and provides another fairly clean identity/authentication system.
As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla.
+[[Crore]].
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OpenID is an identity management system. It allows users to authenticate to one site using another site as their identity. A use case for this is, for example, using your Facebook account to log in to Wikipedia. This may be useful, as it would allow users to more easily register for Wikipedia.
OAuth is a third-party authentication and authorization system that allows outside applications to do stuff on behalf of a user. The reason for this is because currently toolserver applications, etc. authenticate to Wikipedia using a plaintext username and password, which is extremely insecure for a number of reasons I will not elaborate on here.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Aug 27, 2012 at 9:52 AM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
Hoi, I have re-read the Wikipedia article about OpenID and OpenAuth.
OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already said too much about its need.
It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve? Thanks, GerardM
On 27 August 2012 01:48, Tyler Romeo tylerromeo@gmail.com wrote:
If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already
exists,
etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid
situation
to write a new standard in.
But the problem is that "it already exists" is in fact a valid reason to use a protocol. There are numerous libraries out there (including a PHP extension) that allow people to use OAuth to authenticate with services. Making our own protocol just makes it more difficult for application developers since, in addition to developing their application, they have
to
make their own client side functionality to fulfill our custom protocol. Furthermore, as I said before, OAuth 1 isn't bad. It provides for secure authentication and authorization of the client while protecting against replay attacks. Furthermore, I'd like to at least put some faith in the IETF, considering they are quite intelligent people, and not just toss
out
their protocol because it isn't "perfect" (quotes are intentional). If somebody wants to go ahead and make an extension for a custom authentication protocol, feel free to do so, but I still believe OAuth support should be our ultimate goal in terms of third-party application security.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Aug 26, 2012 at 2:38 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
2012/8/26 Mark A. Hershberger mah@everybody.org:
On 08/24/2012 01:33 PM, Nabil Maynard wrote:
- Persona: Previously called BrowserID. It's come a LONG way in
the
past
few months, and provides another fairly clean
identity/authentication
system.
As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla.
+[[Crore]].
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I have re-read the Wikipedia article about OpenID and OpenAuth.
OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already said too much about its need.
It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve?
OAuth will solve more practical problems than OpenID. Toolserver has had a need for this for years. Labs has the same need. Tools need to act on behalf of users. We can't let these tools request or store the credentials of our users, because that's insecure and gives the tool author access to the credentials. OAuth allows the tool to store a token, rather than the user's password. Of course, this goes past just tools. Beta Labs has this problem too. Bots could also benefit from this greatly.
OpenID would be helpful, and really a combination of OpenID and OAuth would be the best thing, but the priority of implementing these definitely leans in favor of OAuth.
- Ryan
Bots could also benefit from this greatly.
Indeed. In fact, it could (possibly) even change the way bots are done altogether. Right now bots are put on separate bot accounts so that if they are compromised the main user account is still secure (and also so that the permissions are separated). OAuth could change this by allowing bots to operate directly under the user's account.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Aug 27, 2012 at 12:57 PM, Ryan Lane rlane32@gmail.com wrote:
I have re-read the Wikipedia article about OpenID and OpenAuth.
OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already
said
too much about its need.
It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve?
OAuth will solve more practical problems than OpenID. Toolserver has had a need for this for years. Labs has the same need. Tools need to act on behalf of users. We can't let these tools request or store the credentials of our users, because that's insecure and gives the tool author access to the credentials. OAuth allows the tool to store a token, rather than the user's password. Of course, this goes past just tools. Beta Labs has this problem too. Bots could also benefit from this greatly.
OpenID would be helpful, and really a combination of OpenID and OAuth would be the best thing, but the priority of implementing these definitely leans in favor of OAuth.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Bots could also benefit from this greatly.
Indeed. In fact, it could (possibly) even change the way bots are done altogether. Right now bots are put on separate bot accounts so that if they are compromised the main user account is still secure (and also so that the permissions are separated). OAuth could change this by allowing bots to operate directly under the user's account.
I don't think that's something we really want to do. Granting bot permissions hides someone from RecentChanges by default, which you wouldn't want as a normal user (well you might, but I don't think communities would).
-Chad
On Mon, Aug 27, 2012 at 1:08 PM, Chad innocentkiller@gmail.com wrote:
On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Indeed. In fact, it could (possibly) even change the way bots are done altogether. Right now bots are put on separate bot accounts so that if they are compromised the main user account is still secure (and also so that the permissions are separated). OAuth could change this by allowing bots to operate directly under the user's account.
I don't think that's something we really want to do. Granting bot permissions hides someone from RecentChanges by default, which you wouldn't want as a normal user (well you might, but I don't think communities would).
Indeed. Communities also want separate bot accounts so it's easy to tell what contributions are automated and so bots can be blocked without blocking their operators.
-Madman
I don't think that's something we really want to do. Granting bot permissions hides someone from RecentChanges by default, which you wouldn't want as a normal user (well you might, but I don't think communities would).
Indeed. Communities also want separate bot accounts so it's easy to tell what contributions are automated and so bots can be blocked without blocking their operators.
Well, with OAuth, it might be possible to mark actions as bot actions. It would also be possible to revoke just the OAuth key that allows the bot to operate, thus avoiding blocking the user.
- Ryan
Well, with OAuth, it might be possible to mark actions as bot actions. It would also be possible to revoke just the OAuth key that allows the bot to operate, thus avoiding blocking the user.
It would still be easier though for an end user to look at a username and see the bot. The user pages for Bots usually include quite a bit of information on them as well. Definitely think replacing Bot accounts with OAuth is the wrong way to go. I like the idea of using it for the toolserver though.
Thank you, Derric Atzrott
It would still be easier though for an end user to look at a username and see the bot. The user pages for Bots usually include quite a bit of information on them as well. Definitely think replacing Bot accounts with OAuth is the wrong way to go. I like the idea of using it for the toolserver though.
Yeah, likely best to continue to use bot accounts. It avoids the problem of bots being compromised in Labs from other users, though.
- Ryan
I agree that bot accounts should still be separate, I just wanted to make the point that, theoretically, since the permissions are separated, you could do it that way if so desired.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Aug 27, 2012 at 2:11 PM, Ryan Lane rlane32@gmail.com wrote:
It would still be easier though for an end user to look at a username
and see
the bot. The user pages for Bots usually include quite a bit of
information on
them as well. Definitely think replacing Bot accounts with OAuth is the
wrong
way to go. I like the idea of using it for the toolserver though.
Yeah, likely best to continue to use bot accounts. It avoids the problem of bots being compromised in Labs from other users, though.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Meta discussions over community, Appreciation threads, GSoC wrapups, Deployment threads, and orthogonal questions. Lately wikitech-l seems to be almost void of one of the most important categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just like Sumana's "Appreciation thread" how about a little thread dedicated to listing out things we'd like to see in MediaWiki or perhaps would like to write ourselves. Not really big things like VisualEditor, Wikidata, and Lua who have teams of people within WMF working on them. But rather those other important things a lot of us may want but always end up pushed to the side and forgotten.
For me...
...
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic implementation of actual OAuth (1&2) looks like a dark dead-end. Rather than OAuth I'd like to write a new auth standard that learns from all the good things and the mistakes made in both versions of OAuth and takes note of all the things we really need. And then implement it into MediaWiki and write a series of server and client libraries/sdks so it's also easier to pick up than either OAuth.
Obligitory XKCD: http://xkcd.com/927/
...
Now some old and forgotten code topics:
...
- Password reset tokens: It's unbelievable but we are STILL using
temporary passwords instead of reset tokens. Naturally this is less usable and also lowers the security of our password reset system.
I had no idea we were doing that. That /is/ really bad!
- An abstract revision system. The way we shove configuration into i18n,
i18n into articles, scripts and stylesheets into articles, and extensions go and do the same. All just to get proper revisioning of things. Is horrible. Not to mention the extensions that don't and rely on our logging system which makes it harder to revert things. With all this together I'd like to see an abstract system that lets extensions have their own revision system outside of page content for whatever they need to do.
This. I would pay you for this one. Not a living by any means, but I would be willing to put $20-$30 towards whoever implements that as a gift and a "Thank you". All my extensions at my job have to keep track of revisions and it is a pain to reimplement it every time. I still haven't gotten my history UIs anywhere close to as nice as the one used by Mediawiki.
-------------
That all said, this a fantastic topic idea. I can't wait to see where this goes.
Thank you, Derric Atzrott
Wait a second. Concerning the password reset, currently it uses the user_newpassword field, which means the user is required to reset their password upon login. How is this any different than using a reset token, where the user supplies the reset token and changes their password?
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 24, 2012 at 1:38 PM, Derric Atzrott < datzrott@alizeepathology.com> wrote:
Meta discussions over community, Appreciation threads, GSoC wrapups, Deployment threads, and orthogonal questions. Lately wikitech-l seems to be almost void of one of the most important categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just like Sumana's "Appreciation thread" how about a little thread dedicated to listing out things we'd like to see in MediaWiki or perhaps would like to write ourselves. Not really big things like VisualEditor, Wikidata, and Lua who have teams of people within WMF working on them. But rather those other important things a lot of us may want but always end up pushed to the side and forgotten.
For me...
...
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic implementation of actual OAuth (1&2) looks like a dark dead-end. Rather than OAuth I'd like to write a new auth standard that learns from all the good things and the mistakes made in both versions of OAuth and takes note of all the things we really need. And then implement it into MediaWiki and write a series of server and client libraries/sdks so it's also easier to pick up than either OAuth.
Obligitory XKCD: http://xkcd.com/927/
...
Now some old and forgotten code topics:
...
- Password reset tokens: It's unbelievable but we are STILL using
temporary passwords instead of reset tokens. Naturally this is less usable and also lowers the security of our password reset system.
I had no idea we were doing that. That /is/ really bad!
- An abstract revision system. The way we shove configuration into i18n,
i18n into articles, scripts and stylesheets into articles, and extensions go and do the same. All just to get proper revisioning of things. Is horrible. Not to mention the extensions that don't and rely on our logging system which makes it harder to revert things. With all this together I'd like to see an abstract system that lets extensions have their own revision system outside of page content for whatever they need to do.
This. I would pay you for this one. Not a living by any means, but I would be willing to put $20-$30 towards whoever implements that as a gift and a "Thank you". All my extensions at my job have to keep track of revisions and it is a pain to reimplement it every time. I still haven't gotten my history UIs anywhere close to as nice as the one used by Mediawiki.
That all said, this a fantastic topic idea. I can't wait to see where this goes.
Thank you, Derric Atzrott
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Aug 24, 2012 at 1:52 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Wait a second. Concerning the password reset, currently it uses the user_newpassword field, which means the user is required to reset their password upon login. How is this any different than using a reset token, where the user supplies the reset token and changes their password?
Well I assume we'd put the token in the url we give the user, so they don't have to type anything in.
-Chad
Yes, but that's only increased convenience. I'm wondering exactly what security implications there are to our current system v. a token reset system.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 24, 2012 at 1:56 PM, Chad innocentkiller@gmail.com wrote:
On Fri, Aug 24, 2012 at 1:52 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Wait a second. Concerning the password reset, currently it uses the user_newpassword field, which means the user is required to reset their password upon login. How is this any different than using a reset token, where the user supplies the reset token and changes their password?
Well I assume we'd put the token in the url we give the user, so they don't have to type anything in.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
n 24 August 2012 18:57, Tyler Romeo tylerromeo@gmail.com wrote:
Yes, but that's only increased convenience. I'm wondering exactly what security implications there are to our current system v. a token reset system.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
How long is the generated password? Might be a brute force vulnerability.
Tom
The password length is whatever $wgMinimalPasswordLength is set to, and according to DefaultSettings.php it's 1 :P. Maybe we should increase the length of passwords from User::randomPassword.
- Security: Because the temporary password is being entered by the user it
ends up being much shorter than it should be. The temporary passwords have really low entropy and if we expired them any later than we do now it would theoretically be possible to brute force a password reset. Frankly right now if someone was persistent enough to brute force randomly and make a second reset after the first expires they may actually have a sane enough chance at brute forcing into an account.
Ah I see, so in the end it's pretty much about brute force attacks. Well what we can do (in order to avoid schema changes), is keep the newpassword field, increase temporary password lengths to something like 64, and then shift the Special:ResetPassword and User::mailPasswordInternal logic to use URLs instead of entering the password manually.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 24, 2012 at 1:59 PM, Thomas Morton <morton.thomas@googlemail.com
wrote:
n 24 August 2012 18:57, Tyler Romeo tylerromeo@gmail.com wrote:
Yes, but that's only increased convenience. I'm wondering exactly what security implications there are to our current system v. a token reset system.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
How long is the generated password? Might be a brute force vulnerability.
Tom _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The password length is whatever $wgMinimalPasswordLength is set to, and according to DefaultSettings.php it's 1 :P. Maybe we should increase the length of passwords from User::randomPassword.
- Security: Because the temporary password is being entered by the user it
ends up being much shorter than it should be. The temporary passwords have really low entropy and if we expired them any later than we do now it would theoretically be possible to brute force a password reset. Frankly right now if someone was persistent enough to brute force randomly and make a second reset after the first expires they may actually have a sane enough chance at brute forcing into an account.
Ah I see, so in the end it's pretty much about brute force attacks. Well what we can do (in order to avoid schema changes), is keep the newpassword field, increase temporary password lengths to something like 64, and then shift the Special:ResetPassword and User::mailPasswordInternal logic to use URLs instead of entering the password manually.
The other thing though that can be done with tokens that can't be done with passwords (at least without violating user expectations) is making the token expire. Having the randomly generated token/password expire after a day or so greatly reduces the amount of time available for an attack.
Thank you, Derric Atzrott
- Usability: Forcing the user to manually enter the token is a very bad user experience. We have good email confirmation tokens but don't bother to do password resets the same way. - Security: Because the temporary password is being entered by the user it ends up being much shorter than it should be. The temporary passwords have really low entropy and if we expired them any later than we do now it would theoretically be possible to brute force a password reset. Frankly right now if someone was persistent enough to brute force randomly and make a second reset after the first expires they may actually have a sane enough chance at brute forcing into an account.
On Fri, 24 Aug 2012 10:52:00 -0700, Tyler Romeo tylerromeo@gmail.com wrote:
Wait a second. Concerning the password reset, currently it uses the user_newpassword field, which means the user is required to reset their password upon login. How is this any different than using a reset token, where the user supplies the reset token and changes their password?
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 24, 2012 at 1:38 PM, Derric Atzrott < datzrott@alizeepathology.com> wrote:
Meta discussions over community, Appreciation threads, GSoC wrapups, Deployment threads, and orthogonal questions. Lately wikitech-l seems to be almost void of one of the most important categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just like Sumana's "Appreciation thread" how about a little thread dedicated to listing out things we'd like to see in MediaWiki or
perhaps
would like to write ourselves. Not really big things like VisualEditor, Wikidata, and Lua who have
teams
of people within WMF working on them. But rather those other important things a lot of us may want but always end up pushed to the side and forgotten.
For me...
...
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic implementation of actual OAuth (1&2) looks like a dark dead-end. Rather than OAuth I'd like to write a new auth standard that learns from all the good things and the mistakes made in both versions
of
OAuth and takes note of all the things we really need. And then
implement
it into MediaWiki and write a series of server and client
libraries/sdks
so it's also easier to pick up than either OAuth.
Obligitory XKCD: http://xkcd.com/927/
...
Now some old and forgotten code topics:
...
- Password reset tokens: It's unbelievable but we are STILL using
temporary passwords instead of reset tokens. Naturally this is less
usable
and also lowers the security of our password reset system.
I had no idea we were doing that. That /is/ really bad!
- An abstract revision system. The way we shove configuration into
i18n,
i18n into articles, scripts and stylesheets into articles, and
extensions
go and do the same. All just to get proper revisioning of things. Is horrible. Not to mention the extensions that don't and rely on our
logging
system which makes it harder to revert things. With all this together
I'd
like to see an abstract system that lets extensions have their own revision system outside of page content for whatever they need to do.
This. I would pay you for this one. Not a living by any means, but I would be willing to put $20-$30 towards whoever implements that as a gift and a "Thank you". All my extensions at my job have to keep track of revisions and it is a pain to reimplement it every time. I still haven't gotten my history UIs anywhere close to as nice as the one used by Mediawiki.
That all said, this a fantastic topic idea. I can't wait to see where this goes.
Thank you, Derric Atzrott
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Tyler Romeo wrote:
Wait a second. Concerning the password reset, currently it uses the user_newpassword field, which means the user is required to reset their password upon login. How is this any different than using a reset token, where the user supplies the reset token and changes their password?
Thanks Tyler, I was wondering the same.
Tyler Romeo wrote:
The password length is whatever $wgMinimalPasswordLength is set to, and according to DefaultSettings.php it's 1 :P. Maybe we should increase the length of passwords from User::randomPassword.
But we never generate random passwords shorter than 10 characters. (includes/User.php line 859) We can increase that hardcoded value as much as we want.
Derric wrote:
The other thing though that can be done with tokens that can't be done with passwords (at least without violating user expectations) is making the token expire. Having the randomly generated token/password expire after a day or so greatly reduces the amount of time available for an attack.
Our temporary passwords do expire.
Daniel Friesen wrote:
- Usability: Forcing the user to manually enter the token is a very bad
user experience. We have good email confirmation tokens but don't bother to do password resets the same way.
- Security: Because the temporary password is being entered by the user
it ends up being much shorter than it should be. The temporary passwords have really low entropy
It's using MWCryptRand, 46 bits. It could be improved, but it's not that bad.
and if we expired them any later than we do now it would theoretically be possible to brute force a password reset. Frankly right now if someone was persistent enough to brute force randomly and make a second reset after the first expires they may actually have a sane enough chance at brute forcing into an account.
Mailman integration: You just got promoted to sysop / steward / checkuser/arbcom ? You now have a new checkbox at [[Special:MailingLists]] for subscribing to the relevant private list!
(I suggest to add the new ideas as direct children of the root post, and use other descendents for discussing the ideas themselves)
wikitech-l@lists.wikimedia.org