-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Roger,
On 12/31/16 2:30 PM, Roger Marquis wrote: >>> Do we also need to derive the algorithm, saltLength and >>> iterations from server.xml? >> >> Nope. If you follow what's in that presentation starting on slide >> 29, > > This is the design element that isn't clear. Since the stored hash > will constant across 99% of use cases, if not 100%, usability > measures indicate it should be an optional default? It's also odd > considering the method doesn't require a dev to derive any other > hash elements. I'm not sure what you mean, here. You're right, once set, a set of parameters (e.g. salt length = 64 bits, iteration count=10k), they aren't likely to change for a while. But the encapsulation of everything into the CredentialHandler implementation means that you can adjust those parameters upward (e.g. salt length=128 bits, iteration count=100k) in the future without having to change any code at all. You can even change from salted-iteration over to PBKDF2 or bcrypt or whatever trivially by changing the CH configuration to use a set of nested CredentialHandlers: <CredentialHandler type="combined"> (paraphrasing) <CredentialHandler type="pbkdf2" /> (the new scheme) <CredentialHandler type="sha256" /> (the old scheme) </CredentialHandler> No code needs to change and you can switch algorithms. >> You could easily write your own CredentialHandler > > That would be easy enough but also likely to require more > refactoring across subsequent Tomcat releases. Minimizing > maintenance is one of the main reasons we prefer Tomcat (and Java) > to other http backends. Understood. The introduction of the CredentialHandler interface was done precisely because it was awkward to do anything similar with previous versions. You can never really divorce this kind of thing from the container entirely. What you can do is write a custom CredentialHandler and package it in a separate JAR file that is independent from your application (but semi-dependent upon the Tomcat version). For the most part, the built-in CredentialHandler implementations should meet the needs of most environments, but new ones can be written and plugged-in should the need arise. And, of course, the application can get a reference to the configured CH for an application and use it, either for verification of an existing password or for mutating a new one (e.g. for "change password" operations). - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYaKqdAAoJEBzwKT+lPKRY1HoQAIkJM3zWOkkw+J+0Cd7KFDgf YevIcrHZyb6NXfyMZ4vW4DsscoYZvXA6xFaicPqvhkpLugvDV9EnFVxrXZZOwCJL a3Ni13npKD6oBMLWfg+HmuTsg9VhCDZBzz5139LccyNyUUTo5Hww04b/ffKqjl1M ZWoxn63xWXLOSY2BpbNr8AyzYV3nE5MXURFM7U/mauQcYdf4ZOIlOlSti8ireGm6 iYgPIbHgJ7S0xNWdg3jP/AWrYY7yYos7tM/H6ZlqvfgBAuoyvUCNkgSi0zI7geB8 Ad4EQ4x0J2rfKqTPlWZenuwI/LAeq2jhZr606tTXg62jAajtIr103LLqJfN3C83U kbKLeS1U/Qn7o6tvJVvTmwFIt65T3HDXn8N5/1msIbZFVh14MOS9wEpWAVv5wjBb 25yb244DzchOf4PntwifqvvyFEcR+EKriMM7IGSKkqr/97RVA9fw91Kbg48eetfF +jI6QKcMNaTcOg9OHewXIAfLlNFwZeLbkWnief0ekU5PrxEEEk30+u01sYY4Xn5F I6FMP1lkS8O1GMglSBQRmr9e7ELlqvmH3IdHjNkxcfcju18iaa4KCPz74C5eECJc 4vRp80ogCbrDr8OqpgaZZ/RkF/BLEDhAh+8VTsGhBcF4oIWHQ8bDtU+Ann2ZqauR Uxo76eLV2Xmo9w9Hihcs =KpQ+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
