---------- Forwarded message ---------- From: Sreyan Chakravarty <[email protected]> Date: Fri, Sep 11, 2015 at 12:55 AM Subject: Re: Difference between Password Service and Hash Service To: Apache Shiro Users <[email protected]>
Also how can I implement password hash that is used by the HashService since the HashService recognizes only hashes supported bu MessageDigest class. Now sCrypt isn't one of them. So how do I use that with the hashing service ? On Thu, Sep 10, 2015 at 5:22 PM, Sreyan Chakravarty < [email protected]> wrote: > "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! >> > >
