On Nov 3, 2010, at 3:10 PM, Les Hazlewood wrote: > I was thinking that we should have a CredentialsManager interface that > knows about hashing and encryption and performs all of this for > end-users. This name is inline with the existing authc 'credential' > package. I'd like to avoid creating something like 'PasswordManager' > or 'EncryptionManager': the former implies it is limited to passwords > only, whereas any credential could technically be hashed/encrypted and > the latter implies its primary purpose is associated with cryptography > and/or ciphers.
I agree that PasswordManager would not be an ideal name, it's vague. However, HashManager and EncryptionManager reflect the one-way and two-way functions. I would be worried that we would be mixing concerns in a CredentialsManager. I am making my comments with my previous outline in mind. It might be useful if you provided bits of code to give a bit more context. > Also, we already have Hash and CipherService concepts in Shiro (no > need for something like Encryptor that I can see) - the Can you explain your statement "no need for something like Encryptor that I can see"? > CredentialsManager would just sit a level above these and use them > both, probably along with a RandomNumberGenerator and tie all three > things together. Again, a bit more code would help here. :) > Finally, it doesn't make sense to me to have a 'key' attribute forced > upon a Hash interface. Hashes have no concept of a 'key' and that > shouldn't be reflected in the core interface. I'm also confused as to > why the Encrypted interface (and it's 'key') would exist, especially > when ByteSource already exists. The key is critical since it is used to indicate what hash or encryption was used to obtain that bit of data. Regards, Alan
