https://bugzilla.wikimedia.org/show_bug.cgi?id=28419

--- Comment #66 from Daniel Friesen <[email protected]> 
2012-08-06 12:29:25 UTC ---
(In reply to comment #64)
> (In reply to comment #61)
> > I suggest we stop the cryptoparanoia competition here and finally get at 
> > least
> > SHA-2 or WHIRLPOOL (since you people make such a great deal of implementing
> > PBKDF2 so you can't get it done without tearing each other apart). We're 
> > still
> > using MD5 right now for password storage.
> > 
> > I could go ahead and patch the system myself. But it looks that it has been
> > done at least twice, can we finally get *something* into gerrit? 
> > Preferrably in
> > the small portions. If I were you, I'd start with OOP rewrite of the current
> > password system without any new backends, then commit a patch with PDKBF2
> > backend, etc.
> 
> There already was something in Gerrit. I submitted a patch earlier last week
> that fully implemented an OOP password system. You can see the patch here:
> https://gerrit.wikimedia.org/r/16049
> 
> Unfortunately, I abandoned it due to the insane arguments we've been having in
> this thread. If you want I can adjust the patch (so that it uses hard-coded
> types like Daniel has proposed) and re-submit it to Gerrit.

Both our implementations are still incomplete.
Namely neither of us have implemented handling for displaying issues on the
login form. We can't go outputting fatal errors and "Incorrect password
entered." when we have an issue with the data stored in the database.

I've cleaned up my implementation a bit since the last time. The Status trick
is gone, I've added some documentation, and split up and renamed some of the
code.
I plan to push the password update code once I've been able to test it
(Platonides broke maintenance/dev/ and I had to fix it).
I'm also considering renaming the isPreferred[...], and switching the interface
to an abstract class like you had.
I considered the idea of tests in implementation code like you have. It's a
nice idea but I'm still trying to think of how to do that while still making
things like rfc6070 testing possible without introducing the possibility of
serialization mistakes letting bugs in the implementation slip by. Maybe I'll
split it out into a plain pbkdf2 implementation and pbkdf2 based password
storage implementation so I can separate the tests and make the code easier to
read and add hash_pbkdf2 to.

I was hoping to collaborate on getting this branch of code I started months ago
finished and ready for actual use in core.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to