https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #36 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> 2012-03-31 04:38:25 UTC --- (In reply to comment #35) > (In reply to comment #34) > > There are a number of problems with that that I don't think you realize. > > There > > needs to be some way to determine what type of hash it is, and that cannot > > be > > done if the delimiter can be whatever the hell the hashing plugin wants. > Yes it can. > > We can have one of 2 formats: > - A 32 char lowercase hex string; This is an old password from before we > introduced types. It gets compared with oldCrypt. > - Data starting with ':A:', etc... > > Data which is not an oldCrypt string must start with ':TYPE:', a TYPE cannot > contain a :. The data after the type identifier is treated as raw and passed > to > the password type implementation raw allowing it to handle the data in > whatever > format it wants. FWIW, what I described here is almost precisely what we already do with ':A:', ':B:'. We don't explode everything by ':' at the type comparison, we test the string to see if it starts with ':A:' or ':B:'. We only use explode() once we get into the actual type implementation. The only difference here is we can now use type names that aren't single characters. And we give proper error conditions if the stored data does not match a valid format. A crypt() backed password implementation may end up storing passwords in an end format that looks like: :CRYPT:$1$nsYRDLy7$invZ4E66PRu85Uss0mmdA0 ((The fact that a :CRYPT: exists at the start being transparent to the implementation)) The implementation would look something like what I posted before. ---- There's another factor I should mention. Password may not necessarily stay purely static. Take a look at MWCryptRand. The class was actually originally written purely with static variables. Now you see a singleton structure with real* methods and statics that everyone uses. This was an intentional design decision TimStarling had me change the code to fit. He wants the unit test framework to be able to easily set up and tear down instances and have test subclasses that allow the unit test framework to be able to play with the internals and ensure that the class functions correctly. It's a distinct possibility that Password may end up the same way in order to allow the unit test framework to control it. So lumping password type and password into a single class may be short-sighted ignoring how it could possibly get in the way of later decisions on how to unit test it. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
