https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #35 from Daniel Friesen <[email protected]> 2012-03-31 04:18:13 UTC --- (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. The 'Password' class handles the :TYPE: while type implementations work with the raw data after the :TYPE:. This provides a guarantee that: - New data will never match our old 32 char strings - There is always a type identifier for the password - The password type implementations may work with raw data if necessary so they can use a suitable data serialization. > Regardless, in a pluggable hashing system, it is not the hashing function's > job > to format the hash for storage in the database. Formatting and storage is > something that should be unified and handled in a centralized manner by some > sort of Password class. I cannot foresee any reason ever for MediaWiki to want > to up and switch delimiters for no apparent reason. > > All that is needed is a central Password class that will handle all formatting > and hash parsing and then pass off actual cryptography work to the respective > functions. And yes, the colon-separated format is a format WE came up with, > but > why in God's name would MediaWiki need to allow hashing functions to change > the > delimiter or storage format? There is no security advantage to using dollar > signs over colons that I know of. There's not security advantage. There is however a fact you are ignoring. There are already existing implementations that use dollar signs. crypt(), bcrypt(), etc... (likely scrypt as well) Enforcing that all data must use : separators interferes with the ability to write a password implementation that plugs a well known 3rd party password hashing library that uses a different separator into MediaWiki. -- 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
