shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sreyan Chakravarty <>
Subject Fwd: Difference between Password Service and Hash Service
Date Mon, 14 Sep 2015 19:31:15 GMT
---------- Forwarded message ----------
From: Sreyan Chakravarty <>
Date: Fri, Sep 11, 2015 at 12:55 AM
Subject: Re: Difference between Password Service and Hash Service
To: Apache Shiro Users <>

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 <> 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 <>
> wrote:
>> On Wed, Sep 9, 2015 at 11:09 AM, Sreyan Chakravarty <
>>> 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!

View raw message