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!
