4 ms·

"New" here refers to "past-2008" – the salt was changed from using user ID then (https://mediawiki.org/wiki/Special:Code/MediaWiki/35923 https://mediawiki.org/w

"New" here refers to "past-2008" – the salt was changed from using user ID then (https://mediawiki.org/wiki/Special:Code/MediaWiki/35923 https://mediawiki.org/wiki/Special:Code/MediaWiki/35923). Accoding to https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt salting was added and made default in MediaWiki 1.1, which is prehistory (something like 2003 or so). The only "not good" part here is using MD5, but, well – that code was written ten years ago, and then MD5 was AFAIK considered perfectly secure. There's an outstanding bug from 2011 about replacing it with something better (https://bugzilla.wikimedia.org/show_bug.cgi?id=28419 https://bugzilla.wikimedia.org/show_bug.cgi?id=28419). edit: I asked the primary Wikimedia Foundation security guy (Chris Steipp) on IRC about that bug and he said he's working on it. One good thing to come out of all this ;)

sehrope 13y ago
> "New" here refers to "past-2008" – the salt was changed from using user ID then (https://mediawiki.org/wiki/Special:Code/MediaWiki/35923 https://mediawiki.org/wiki/Special:Code/MediaWiki/35923). > > Accoding to https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt salting was added and made default in MediaWiki 1.1, which is prehistory (something like 2003 or so). > The only "not good" part here is using MD5, but, well – that code was written ten years ago, and then MD5 was AFAIK considered perfectly secure. It's been a terrible idea to use MD5 (or any other generic hash function) directly for hashing passwords for years. Certainly well before 2003. PBKDF2 has been around since at least 2000 and bcrypt since 1999. Choosing a "better" hash function itself isn't enough. It'd just as bad if it was SHA-1 instead. A large number of rounds is needed to lengthen the time needed to test a guess which is what PBKDF2 and bcrypt do[1]. > There's an outstanding bug from 2011 about replacing it with something better (https://bugzilla.wikimedia.org/show_bug.cgi?id=28419 https://bugzilla.wikimedia.org/show_bug.cgi?id=28419). edit: I asked the primary Wikimedia Foundation security guy (Chris Steipp) on IRC about that bug and he said he's working on it. One good thing to come out of all this ;) Well that's good news. It's sad that it takes events like this to get security fixes prioritized but at least they do. Somewhat related, this is yet another example of why OSS is great. With no experience with the code base it took all of 5 min to figure out how they handle it and get a idea of the effort to fix it. It looks like they already have versioning in place (the A/B) so hopefully it'd be easy to add a C with a better approach (and make it the default). [1]: Or even better scrypt which also increases the memory needed to compute the hash based on the work factor.

sehrope 13y ago

> "New" here refers to "past-2008" – the salt was changed from using user ID then (https://mediawiki.org/wiki/Special:Code/MediaWiki/35923 https://mediawiki.org/wiki/Special:Code/MediaWiki/35923). > > Accoding to https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt salting was added and made default in MediaWiki 1.1, which is prehistory (something like 2003 or so). > The only "not good" part here is using MD5, but, well – that code was written ten years ago, and then MD5 was AFAIK considered perfectly secure. It's been a terrible idea to use MD5 (or any other generic hash function) directly for hashing passwords for years. Certainly well before 2003. PBKDF2 has been around since at least 2000 and bcrypt since 1999. Choosing a "better" hash function itself isn't enough. It'd just as bad if it was SHA-1 instead. A large number of rounds is needed to lengthen the time needed to test a guess which is what PBKDF2 and bcrypt do[1]. > There's an outstanding bug from 2011 about replacing it with something better (https://bugzilla.wikimedia.org/show_bug.cgi?id=28419 https://bugzilla.wikimedia.org/show_bug.cgi?id=28419). edit: I asked the primary Wikimedia Foundation security guy (Chris Steipp) on IRC about that bug and he said he's working on it. One good thing to come out of all this ;) Well that's good news. It's sad that it takes events like this to get security fixes prioritized but at least they do. Somewhat related, this is yet another example of why OSS is great. With no experience with the code base it took all of 5 min to figure out how they handle it and get a idea of the effort to fix it. It looks like they already have versioning in place (the A/B) so hopefully it'd be easy to add a C with a better approach (and make it the default). [1]: Or even better scrypt which also increases the memory needed to compute the hash based on the work factor.