The sources and methods we've been using for the generation of security tokens in our code has been either fairly inadequate or has system support issues.
-- TL;DR portion -- In the installer we try to use /dev/urandom directly. While this is a good source it's not available in some situations. And if it's not available, then we all the way back to nearly the weakest random number generator we could have.
For the generation of user_token we take the secret key generated during installation (or use microtime if not available), combine it with mt_rand( 0, 0x7fffffff ), the wiki id, and the user_id and the md5 it. Given that both the wiki id and the user id are public and mt_rand is weak we basically rely entirely on the secret key. If the secret key is leaked then it becomes a mere matter of time before one could find out what token was used by trying the possible values of mt_rand. And the entire user_token column needs to be reset. Also given that people regularly post their LocalSettings.php in #mediawiki and some forget to strip out their $wgSecretKey it would be a good idea to not depend so heavily on the secret key actually being secret.
For the generation of other security tokens like email confirmation tokens and temporary passwords we use nothing but mt_rand() not even bothering to see if there is a proper source of random data. -- END --
In light of that, I've built a new MWCryptRandom class intended to be used in the installer for generating tokens, when generating user_token, and when generating other cryptographic random tokens.
The class is in-part based on Drupal's drupal_random_bytes[1] method, some of our own code, some code I had written prior to writing this (eg: I had already planned to use openssl_get_random_bytes in User::setToken before I wrote this), and some extras added into the theory based on what we have available.
Since it's security related I'd like people to look over the code and give some feedback on it.
The class was committed in r111964 but backed out till after the git migration: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111964 If you want to try out and test the class yourself you can get it into your trunk svn checkout by using: $ svn merge -c 111964 .
[1] http://api.drupal.org/api/drupal/core!includes!bootstrap.inc/function/drupal...
Le 21/02/12 03:33, Daniel Friesen a écrit :
The class was committed in r111964 but backed out till after the git migration: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111964 If you want to try out and test the class yourself you can get it into your trunk svn checkout by using: $ svn merge -c 111964 .
Chad will confirm, but I guess you can work on it in a branch and we can migrate that branch to git. That will keep trunk clean and let you work on this feature with other people.
On Tue, Feb 21, 2012 at 2:01 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 21/02/12 03:33, Daniel Friesen a écrit :
The class was committed in r111964 but backed out till after the git migration: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111964 If you want to try out and test the class yourself you can get it into your trunk svn checkout by using: $ svn merge -c 111964 .
Chad will confirm, but I guess you can work on it in a branch and we can migrate that branch to git. That will keep trunk clean and let you work on this feature with other people.
Please, no more branches. In fact, it would be super useful if everyone could find something else to do and stop committing entirely until after the migration ;-)
-Chad
Le 21/02/12 13:09, Chad a écrit :
Please, no more branches. In fact, it would be super useful if everyone could find something else to do and stop committing entirely until after the migration;-)
Hey guys, lets start an online encyclopedia written using a forum. I have started hacking PHPBB. -- The new Magnus
On Tue, Feb 21, 2012 at 1:51 PM, Antoine Musso hashar+wmf@free.fr wrote:
I have started hacking PHPBB. -- The new Magnus
Huh?
Le 21/02/12 14:55, Magnus Manske a écrit :
On Tue, Feb 21, 2012 at 1:51 PM, Antoine Mussohashar+wmf@free.fr wrote:
I have started hacking PHPBB. -- The new Magnus
Huh?
Sorry Magnus,
Was just referring to how you hacked up a new PHP software to replace UseModWiki.
On Tue, 21 Feb 2012 05:51:59 -0800, Antoine Musso hashar+wmf@free.fr wrote:
Le 21/02/12 13:09, Chad a écrit :
Please, no more branches. In fact, it would be super useful if everyone could find something else to do and stop committing entirely until after the migration;-)
Hey guys, lets start an online encyclopedia written using a forum. I have started hacking PHPBB. -- The new Magnus
No, no, not a wiki. Let's fork the basic core code we use in MediaWiki (routing code, WebRequest, database code, etc...) and turn it into a framework library that can be shared with other applications. And then use that to write a new blogging engine.
Then we can ditch WordPress!
Daniel Friesen wrote:
No, no, not a wiki. Let's fork the basic core code we use in MediaWiki (routing code, WebRequest, database code, etc...) and turn it into a framework library that can be shared with other applications. And then use that to write a new blogging engine.
I would love to have some part of our code made into a framework then rebase MediaWiki on top of that. We might benefit from it since that would probably mean more developer will know about our code and thus be able to submit patch and hack MediaWiki :-)
Some years ago I have asked to factor out some of our code to submit it in PEAR, but: - that repo is too restrictive when it comes to coding style - we did not want to be depending on a third party - will have to maintains our code for other usage we have no interest into. So I have abandoned the PEAR idea.
On 29/02/12 10:09, Antoine Musso wrote:
Daniel Friesen wrote:
No, no, not a wiki. Let's fork the basic core code we use in MediaWiki (routing code, WebRequest, database code, etc...) and turn it into a framework library that can be shared with other applications. And then use that to write a new blogging engine.
I would love to have some part of our code made into a framework then rebase MediaWiki on top of that. We might benefit from it since that would probably mean more developer will know about our code and thus be able to submit patch and hack MediaWiki :-)
Some years ago I have asked to factor out some of our code to submit it in PEAR, but:
- that repo is too restrictive when it comes to coding style
- we did not want to be depending on a third party
- will have to maintains our code for other usage we have no interest
into. So I have abandoned the PEAR idea.
It isn't a too bad idea. Although it may not be easy. I suspect there may be hidden knowledge about the deeper layers inside the front end ones. But forcing those classes to be used standalone, can help make a more robust system.
wikitech-l@lists.wikimedia.org