Il giorno 11/feb/2013, alle ore 16:20, "M.-A. Lemburg" <[email protected]> ha scritto:
> On 11.02.2013 14:49, Christian Heimes wrote: >> Am 11.02.2013 14:38, schrieb Donald Stufft: >>> On Monday, February 11, 2013 at 8:15 AM, M.-A. Lemburg wrote: >>>> Giovanni Bajo wrote: >>>>> Il giorno 11/feb/2013, alle ore 13:25, Jesse Noller >>>>> <[email protected] <mailto:[email protected]>> ha scritto: >>>>> >>>>>> Actually I was thinking about this in the shower: the likelihood >>>>>> that pypi users used the same passwords as they did on the wiki is >>>>>> probably much higher than any of us assume. >>>>> >>>>> Given that the passwords were unsalted in both instances, a set >>>>> intersection is enough to verify. >>>> >>>> The moin wiki passwords were salted. >>>> >>>> The reason we reset the passwords, was that the attackers had >>>> access to both the salt and the hashes. >>>> >>> What were they hashed with? Even with a salt a fast hash is trivial to >>> bruteforce for a large number of passwords in practically no time >>> with trivial hardware. >> >> It uses SSHA, that's sha1(password + salt) with a seven char salt. > > Right, should have added that information. > > BTW: I wonder why salt and password are usually stored together > in the same place. The moin implementation also did not add any > application salt to the password string before calculating the > hash value (ie. x = hash(random_salt + application_salt + password)). > Not sure whether passlib does, either. "application salt" is probably not the correct name, you're thinking of a fixed application secret, as far as I can tell. Fixed secrets shouldn't be appended/prepended in hash computations (there are extensions attacks on family of hash functions). What you want is a PRF function, such as a HMAC step, using an application secret as the key. This is commonly employed to increase the security. You store a secret separately from the DB (it could be filesystem or environment), and then you compute HMAC(app_secret, BCRYPT(salt, pwd)). In this case, if the DB is stolen, it can't be bruteforced at all, unless the app secret is also leaked. The bad news is that you cannot rotate the app_secret easily, and so you will never know whether it has been compromised or not. But still, it is a good, widely documented and studied additional step in password handling. -- Giovanni Bajo :: [email protected] Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
