Il giorno 11/feb/2013, alle ore 11:52, Jesse Noller <[email protected]> ha scritto:
> Both issues. As for the # of rounds for bcrypt: yes, it should be increased; > but maxing somewhere reasonable - 250+ ms for calculation is probably "OK" > but it's going to be trivial to DoS unless this merge request also comes with > all the other things you propose (rate limiting, etc). > If we increase the # of bcrypt rounds without simultaneously fixing the > potential DoS we're stabbing ourselves in the face, not making it more > secure. As I already said in my last comment, feel free to merge my patch and then downgrade bcrypt security as you please, because of DoS concerns; it's one number in one file. For instance, on my computer, going from 2**12 rounds to 2**6 rounds brings computation time down to 6ms. As for the rate limiting, I can add a todo list item to the whole security discussion, so that I can get back to it later (when more important items have been handled), add the rate limiting, and hopefully convincing the maintainers to raise the number of rounds. You didn't comment on the migration path. -- 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
