https://issues.apache.org/bugzilla/show_bug.cgi?id=56403
--- Comment #4 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Gabriel from comment #3) > (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. Just remember that switching from one password standard to another is ... hard. If you want to switch from using MD5 to SHA1 to SHA2 to RIPEMD, you basically have to write your own passwork-checker. Fortunately, this will be entirely possible using the tools we will provide. > > 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. +1 > > 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? One delimited field is what pretty much everyone expects. Besides, the Tomcat interface is going to have to be simple so I suspect we'll just have a single "stored credential" byte array or string and present the user's (attempted) password in the same format. The password-munger can do whatever is necessary to compare the two. I suppose it couldn't hurt to add "iterations" to the list of understood configuration attributes. Since we'll need it for PBKDF2, we may as well enable it for the digest-based algorithms, too. > > 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? Let's just assume that PBKDF2 is my target implementation (as well as a backward-compatible plain-old-digest implementation of course) and go ahead and track suggestions for it, here. There's no need to file additional enhancement requests. -- 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
