"The best thing to do for this would be to create a new ScryptHash implementation, and ensure the HashService can create those types of hashes, not a password service."
Why not ? You just said that a password service should be used in place of a regular hashing implementation for passwords. Also wouldn't it be better if sCrypt Passwords could be stored in MCF formats (though I didn't find a MCF identifier for sCrypt, not sure it has one) How would I go about making a Hash implementation that can be used by the HashService ? Could you please give me some guidelines on where to start ? I mean which classes to extend and interfaces to implement and where to put the finished implementation. On Wed, Sep 9, 2015 at 11:57 PM, Les Hazlewood <[email protected]> wrote: > On Wed, Sep 9, 2015 at 11:09 AM, Sreyan Chakravarty < > [email protected]> wrote: > >> Yes that does help Les. Thanks for the reply. However I need a few >> explanations from you since I want to write my own PasswordService for >> Shiro that will use sCrypt. >> > > The best thing to do for this would be to create a new ScryptHash > implementation, and ensure the HashService can create those types of > hashes, not a password service. If you implement this, please contribute > it to the project, we'd very much like to support this. > >> >> 1. Why is it necessary to have a password in the MCF format ? I am no >> cryptography expert but shouldn't just hashing and salting work fine ? >> >> MCF is the de-facto standard for representing password hashes in a text > format. If you store them in a data store somewhere, it's almost always > easier to store them as a string (rather than the raw bytes), and if you > store them as text, it's always better to use a supported format that > password-knowledgeable tools are likely to support. > > >> 1. What is the Shiro1 Crypto format ? Why use it ? I have seen >> passwords hashed by it as "shiro1$50000...." isn't that a security breach >> ? >> I mean you basically giving away the framework and crypto format used. >> >> Password hashing security is not based on seeing the algorithm - it is > based on computational complexity and how long it would take to brute force > passwords. Seeing an MCF-formatted string does tell an attacker what > algorithm was used, but it doesn't matter - they still have to perform all > of those computations for *each* password attempted. That it would take a > massive amount of computing power to do that is what the security is rooted > in. In any event, one should keep their databases (and backups!) secure. > > The Shiro1 Crypt Format allows Shiro to support different hashing > algorithms and parameters via a single MCF String. Typically MCF strings > have their algorithm represented as a hard-coded MCF identifier (e.g. $2y$ > = bcrypt). This was done in the older unix days when saving a couple of > characters was important. It's not important nowadays, so making the alg > name as a configurable parameter is more flexible and allows for more > algorithms to be supported easily. > > >> >> 1. Could you please explain what the ParsableHashFormat ? Why use it >> ? The implementation of DefaultPasswordService says that >> >> //First check to see if we can reconstitute the original hash - this >> allows us to >> //perform password hash comparisons even for previously saved >> passwords that don't >> //match the current HashService configuration values. This >> is a very nice feature >> //for password comparisons because it ensures backwards >> compatibility even after >> //configuration changes. >> >> Correct me if I am wrong. This means that if passwords were stored >> with different crypto formats and different iteration values then >> ParsableHashFormat would be able to detect those. Am I right ? >> >> Yes, exactly - which is usually what you want: if you change your > password hash parameters tomorrow, you still want all of the passwords > currently stored in the database to work during a login attempt. You don't > want to change your config and have that immediately invalidate all stored > passwords. > >> >> 1. What's a HashRequest ? Whats the use of having such a design >> pattern ? Why not just go straight to hashing ? >> >> It allows one to specify whatever hash parameters they want at the time > the computation is performed, *without* knowing the hash implementation > classes - it allows you to decouple your code from underlying Hash > implementation classes. > > A HashService also allows you to set defaults that should be applied if > not specified in a HashRequest. This is convenient for those that *only* > want to specify the data to be hashed and let the algorithm, iterations, > etc be configured on the service. This way the calling code doesn't need > to know about any of that information - it can specify just a file (for > example), and get a Hash without having to know anything else. This is > nice because it allows the application dev to configure these things > separately (e.g. in a text file, spring config, etc) and your code doesn't > have to change when you change algorithms or iterations. > > Cheers! >
