Ok, that has to be made clear to the poor guy merging the PR I'm also fine with Christian's migration path; I share his concerns about your approach.
On Feb 11, 2013, at 6:21 AM, Giovanni Bajo <[email protected]> wrote: > 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 > _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
