https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #12 from Happy-melon <[email protected]> 2011-05-12 00:06:51 UTC --- But given that the whole point is to include a physical barrier to someone being able to brute-force a stolen database on a GPU cluster or somesuch, storing a hash of the non-db key in the db turns the problem back into resting on the preimage security of whatever hash function is used on the key. Generate the (potentially many) preimages that match the hash (by brute force if necessary), and run them in parallel in a dictionary attack on the entire password set. You only need *one* user to have used a trivial password to identify which of the hash preimages is the actual secret key, thereafter it's exactly the same as currently, just with a larger salt. Having a non-db secret key only provides a fundamentally *new* layer of protection (as opposed to just an incrementally stronger implementation of the existing security) if no information at all about it is stored in the database. This is all rather off-topic for this particular bug, anyway... -- 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
