- 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 <tylerro...@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 | tylerro...@gmail.com



On Fri, Aug 24, 2012 at 1:38 PM, Derric Atzrott <
datzr...@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



--
~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-l

Reply via email to