If your salted password end up being completely numeric when
represented in hexadecimal (less than 1 password per 10 millions),
it is also possible to login by providing another password that only
matches the first 9 bytes (instead of the full 16 ones) if it turns out
to also be completely numeric with your assigned salt (which is completely unknown).
The odds of finding an equivalent password with such characteristics, over a double md5
with an unknown salt, are really low. Even if the attacker broke into the servers and
robbed the salts, making use of this property would require a preimage attack of a partial
md5 (2^18) with the output of another md5 hash, for which a full preimage would still be
needed. Breaking the hashes using conventional attacks would be easier, so this is not
a critical update.
Change-Id: I8d1153fb91ca6507bd1df91e9953561f74f12ef6
The error is "PHP Strict Standards: Creating default object from empty value in includes/User.php on line 2142"; the problem was that I forgot to renamed an instance of that variable while refactoring the code.
Change-Id: I4e32311693708ec5a0227d60f7818b374fccd4cc
* Much more easier to find it in the User class than in Preferences and it's general enough to be in that class.
* Rewrote the function for better readbility
* It now always return a Status object so that it's easier to interpret its result.
* Update the only caller in core (in Special:ChangeEmail) and moved the PrefsEmailAdit hook there
Change-Id: I55939bb5295e73594c3fdf7287dddbc16a233ce4
- MWCryptRand: A new api for generating cryptographic randomness for security tokens. Uses whatever cryptographic source is available and if not falls back to using random state and clock drift.
- wfRandomString - A simple non-cryptographic pesudo-random string generation function to replace wfGenerateToken which was written pretending to be secure when it's really not.
- Core updates to use MWCryptRand in various places:
-- user_token generation (to do this we stop generating user_token implicitly and only generate it when needed to avoid depleting the system's entropy pool by reading random data we'll never use)
-- email confirmation token generation
-- password salt generation
-- temporary password generation
-- Generation of the automatic watchlist token
-- login and create user tokens
-- session ids when php's entropy sources are not set
-- the installer when generating wgSecretKey and the upgrade key
* Made WatchedItem select wl_notificationtimestamp instead of "1"
* Added loading mechanism, accessor to wl_notificationtimestamp and method to reset that timestamp
This allows the entire user_token column to be regenerated after a leak by running `UPDATE user SET user_token = NULL;` and letting the user_tokens be regenerated as users try to log back in.
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from TalkpageView::show in /www/w/extensions/LiquidThreads/pages/TalkpageView.php at line 251] in /www/w/includes/GlobalFunctions.php on line 3520
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from MessageTable::contents in /www/w/extensions/Translate/utils/MessageTable.php at line 98] in /www/w/includes/GlobalFunctions.php on line 3520
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from TranslationHelpers::ajaxEditLink in /www/w/extensions/Translate/utils/TranslationHelpers.php at line 1186] in /www/w/includes/GlobalFunctions.php on line 3520
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from ThreadPermalinkView::getSubtitle in /www/w/extensions/LiquidThreads/pages/ThreadPermalinkView.php at line 153] in /www/w/includes/GlobalFunctions.php on line 3520
and maybe more
This is the wrong configuration format for such a feature, and the wrong interface. We already have certain per-namespace permissions in the Title class, and we didn't need to add extra formal parameters to a whole lot of User methods in order to get them. The feature should be implemented wholly in Title, and the concept of user rights should remain relatively simple and easy to understand, and independent of its many applications, i.e. a user either has a right or doesn't. Rights are just a tool for developing access policies; the complexity should be in the caller.
The revert was mostly done by hand, since there were a lot of conflicts. I tried to preserve the gist of conflicting changes in r102187 and r102873. The test changes are not simple reverts, rather I just edited out the per-namespace tests. I reverted the followups r92589 and r104310.
email address is removed
In Preferences::trySetUserEmail no point trying to reset the users email if it's the same
Same for User::setEmail
After setting the email though, invalidate email auth tokens
Add a UserDisplayName hook to allow extensions to give custom display names for users.
Add a $wgRealNameInInterface to use the real name of a user as the display name.
To start of the first use of the display name functionality tweak SkinTemplate to declare the userdisplayname and use it inside of personal_urls.
