- 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