https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #71 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> 2012-08-07 14:41:41 UTC --- (In reply to comment #70) > (In reply to comment #69) > > - I've cleaned the code up some more and added some more documentation. > > - Implemented password upgrading. > > - Switched to the test-cases-in-implementation style. > > - Separated the PBKDF2-HMAC implementation into it's own method and prepared > > the system for hash_pbkdf2 to be used when released. > > - Implemented login form and api handling for the new password system. > > > > A Gerrit branch is being created so the code will end up in the repo soon. > > > > The code is pretty much complete at this point. However I'm still mulling > > over > > how to handle recursive layer password types like a PEPPER type that adds a > > fixed salt not stored in the database but does it without mandating what > > password type you use. > > Awesome! Yeah I saw the Gerrit branch yesterday. I asked for the branch but the ability to push was never setup. Then I was told that Gerrit has private sandboxes and I could have actually pushed the code directly there and had them create a branch based off of it. So now I'm waiting for someone to either setup push or drop the branch and have me push to my private sandbox. > And I was thinking about that as well (the recursive layers idea). > Unfortunately, to create a proper implementation of such a feature, a given > layer would have to be compatible with any other type of hash. That means that > each layer would either a) have to use every possible option (impossible) or > b) > only use things that are common to all hash types. Yeah layering is really tricky. I can't think of a way to implement actual pepper (ie: a static config based salt) without involving an extra complex api, restrictions that get in the way of flexibility, restrictions that make pepper only work on specific implementations, or forcing pepper to be re-implemented for every type. The only alternative I could think of was to make an encryption layer rather than a pepper layer. Instead of peppering the salt the layer's output would contain a key to indicate which shared secret is used and an IV. The next big blob of raw data would be decrypted with the shared secret and then would be passed through Password::verify (ie: The blob of data would be encrypted password data output from Password::crypt()). That would let us create a layer that serves the same purpose of making password data useless without the config file even though we're using encryption instead of pepper. This might actually also have the advantage of working in password types where it's impossible to control the salt and data format. eg: A crypt() like system where you can't specify the salt would still work. ;) It's a fairly worthless fact, but this would also mean our worthless saltless :A: md5 hash would actually be compatible with this tactic. ((I was actually going to try writing it, until I found that mcrypt is not installed on my laptop and it's hell to try to install it in OSX)) Oh btw, do you have a better name than BasePasswordType that does not involve the word "Hash"? OnewayPasswordType KeyCompareHashType, ... bleh I sort of want a better name than BasePasswordType but I'm really trying to avoid perpetuating the lie of calling these a hash because we're not storing hashes. These cease to be cryptographic hash algorithms the moment we start introducing things like salts. What we're doing is practically key derivation rather than hashing. But trying to jump into something like DKeyPasswordType will just be confusing. -- 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
