https://issues.apache.org/bugzilla/show_bug.cgi?id=56403
--- Comment #3 from Gabriel <gabrielesanc...@gmail.com> --- (In reply to Christopher Schultz from comment #2) > I don't see a reason not to back-port it to Tomcat 7. Since it's a breaking > API change, I'll be asking for RTC for a back-port. I suspect it will make > it. That would be very good, since many systems, for example those running Ubuntu 14.04 LTS for the next few years, will be running Tomcat 7 by default. > > Note that Tomcat 6's implementation (identical in all important ways to that > of Tomcat 7 and 8) is not /insecure/, just not terribly secure if being used > without any additional controls. I understand that if the password table is never stolen this is not an issue, but I don't want to be irresponsible, and not use best practices. The current implementation makes it difficult for admins to follow best practice. > > As for providing salted passwords out of the box, I'd suggest that salting > isn't enough and that iteration is also necessary, etc. and that at this > point simply using PBKDF2 or some other password-munging scheme is more > appropriate. I do note that PBKDF2 (mist-typed as PBKDF11 in the > description) does not store the number of iterations in the generated > password which means that you either need to adjust the data you actually > store to include it, or you can never change the number of iterations. Agree that PBKDF2 is the way to go if one want to be conservative but follow best practice. It is what I wish to use in my web applications. Changing the number of iterations should be allowed. I would prefer to have separate data columns for salt, password digest, and number of iterations, but wouldn't mind if they are all in one delimited field. The beauty of the proposed pluggable interface is that it will be easy to do either, right? > > I suspect we'll provide a PBKDF2 implementation out of the box, but nothing > else to avoid any library dependencies. Using the PBKDF2 implementation as > an example would make writing a bcrypt- or scrypt-based implementation > fairly easy. That would be splendid. Noting that this bug is about the pluggable interface and not the PBKDF2 implementation, and that a PBKDF2 implementation would probably use the new pluggable interface (am I right to assume that?), should a new bug be created that depends on this one? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
