Encrypted password in db, why does it tell the Hash and iterations in it

[NabbleSometimesSucks <bi...@yahoo.com>]

So, I was thinking that for my user in my database that the password would
just be the encrypted password. However, looking in the database it has
$Shiro$<encryptionType>$<numberOfIterations>$<encryptedpassword>

Where it is explicit in the type and number of Iterations. I would think
that information as well as the salt would need to be stored somewhere else
and not right there with the password. 

I would think if someone got the data from the database knowing that
knowledge they could decrypt the passwords much easier.

Thanks

Mark



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Encrypted-password-in-db-why-does-it-tell-the-Hash-and-iterations-in-it-tp7578510.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Encrypted password in db, why does it tell the Hash and iterations in it

[Les Hazlewood <lh...@apache.org>]

P.P.S.  Public salts should _always_ be used/generated when hashing
passwords.  Whether or not you wish to use a private salt is up to you (but
recommended).

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Thu, Apr 18, 2013 at 9:59 AM, Les Hazlewood <lh...@apache.org>wrote:

> Yes, I'm glad Jon brought up the private salt.  If you don't store this
> information in the same data store as where your passwords are stored (e.g.
> in app configuration or a private config file not easily accessible
> somewhere), then brute force wouldn't be possible at all until the attacker
> could also acquire that private salt.
>
> Compromising both could be _extremely_ hard, depending on how your
> application infrastructure is set up.  For example, maybe an attacker could
> gets access to your data (maybe they were able to get access to a mysql
> dump file or similar), but they may not be able to get access to the
> location of the private salt (e.g. maybe its in a file they can't access or
> in a Chef encrypted data bag, etc).
>
> I forgot to mention this - thanks Jon!
>
> Best,
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>
>
> On Thu, Apr 18, 2013 at 9:50 AM, jonlinux <jo...@hpdsoftware.com>wrote:
>
>> If you specify the use of a private salt, or set the option to use a
>> public
>> salt, you will have something similar in your database:
>>
>>
>> $shiro1$SHA-512$475494$w9b57Sqavc3YfrxfUpjtWg==$+Wc4fFL+ZnrjrxCGNIRP5fsIYJqc1X8Vj7IInxntrIi0bGjJ4RMJt80Crqeh5RFwt5qgy/seD19IqlriuwWzLg==
>>
>> Thus you can see the hashing algorithm used as well as the number of
>> iterations. And in this instance there is the addition of the public salt
>> (w9b57Sqavc3YfrxfUpjtWg== in the example above).
>> This public salt is different for every password entry in the database,
>> thus
>> it would hinder any pre-computed rainbow table attack on the passwords.
>>
>> Additionally, there is a private salt used which you can set within your
>> Shiro configuration. This means that even if someone walks off with your
>> database, they still will not be able to "decrypt" the passwords.
>>
>> In your example (with no salt), it might be possible to get the password
>> in
>> an unencrypted form by just hashing lots of plain text passwords using the
>> parameters you define, yes. A pre-computed rainbow table could be used in
>> this scenario.
>> But that is why it is recommended that salting of passwords is carried
>> out.
>>
>>
>>
>> --
>> View this message in context:
>> http://shiro-user.582556.n2.nabble.com/Encrypted-password-in-db-why-does-it-tell-the-Hash-and-iterations-in-it-tp7578510p7578622.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>

Re: Encrypted password in db, why does it tell the Hash and iterations in it

[Les Hazlewood <lh...@apache.org>]

Yes, I'm glad Jon brought up the private salt.  If you don't store this
information in the same data store as where your passwords are stored (e.g.
in app configuration or a private config file not easily accessible
somewhere), then brute force wouldn't be possible at all until the attacker
could also acquire that private salt.

Compromising both could be _extremely_ hard, depending on how your
application infrastructure is set up.  For example, maybe an attacker could
gets access to your data (maybe they were able to get access to a mysql
dump file or similar), but they may not be able to get access to the
location of the private salt (e.g. maybe its in a file they can't access or
in a Chef encrypted data bag, etc).

I forgot to mention this - thanks Jon!

Best,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Thu, Apr 18, 2013 at 9:50 AM, jonlinux <jo...@hpdsoftware.com>wrote:

> If you specify the use of a private salt, or set the option to use a public
> salt, you will have something similar in your database:
>
>
> $shiro1$SHA-512$475494$w9b57Sqavc3YfrxfUpjtWg==$+Wc4fFL+ZnrjrxCGNIRP5fsIYJqc1X8Vj7IInxntrIi0bGjJ4RMJt80Crqeh5RFwt5qgy/seD19IqlriuwWzLg==
>
> Thus you can see the hashing algorithm used as well as the number of
> iterations. And in this instance there is the addition of the public salt
> (w9b57Sqavc3YfrxfUpjtWg== in the example above).
> This public salt is different for every password entry in the database,
> thus
> it would hinder any pre-computed rainbow table attack on the passwords.
>
> Additionally, there is a private salt used which you can set within your
> Shiro configuration. This means that even if someone walks off with your
> database, they still will not be able to "decrypt" the passwords.
>
> In your example (with no salt), it might be possible to get the password in
> an unencrypted form by just hashing lots of plain text passwords using the
> parameters you define, yes. A pre-computed rainbow table could be used in
> this scenario.
> But that is why it is recommended that salting of passwords is carried out.
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Encrypted-password-in-db-why-does-it-tell-the-Hash-and-iterations-in-it-tp7578510p7578622.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Encrypted password in db, why does it tell the Hash and iterations in it

[jonlinux <jo...@hpdsoftware.com>]

If you specify the use of a private salt, or set the option to use a public
salt, you will have something similar in your database:

$shiro1$SHA-512$475494$w9b57Sqavc3YfrxfUpjtWg==$+Wc4fFL+ZnrjrxCGNIRP5fsIYJqc1X8Vj7IInxntrIi0bGjJ4RMJt80Crqeh5RFwt5qgy/seD19IqlriuwWzLg==

Thus you can see the hashing algorithm used as well as the number of
iterations. And in this instance there is the addition of the public salt
(w9b57Sqavc3YfrxfUpjtWg== in the example above).
This public salt is different for every password entry in the database, thus
it would hinder any pre-computed rainbow table attack on the passwords.

Additionally, there is a private salt used which you can set within your
Shiro configuration. This means that even if someone walks off with your
database, they still will not be able to "decrypt" the passwords.

In your example (with no salt), it might be possible to get the password in
an unencrypted form by just hashing lots of plain text passwords using the
parameters you define, yes. A pre-computed rainbow table could be used in
this scenario.
But that is why it is recommended that salting of passwords is carried out.



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Encrypted-password-in-db-why-does-it-tell-the-Hash-and-iterations-in-it-tp7578510p7578622.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Encrypted password in db, why does it tell the Hash and iterations in it

[Les Hazlewood <lh...@apache.org>]

You can't inspect the hashed/salted/iterated output and figure out what the
raw password is, even if it is 'password'.  I think Mike was stating that
you could try to take the hashed output, put it in a program (that knows
how to hash things like Shiro), and start trying random values (like
'password').

But for this to happen, the attacker needs to 1) compromise your data store
and pull out all the hashed values, 2) know how to replicate the hashing
algorithm that Shiro uses, and 3) set up a test harness that allows them to
enter in random values.

This is all pretty difficult to do, but not impossible, and that's why the
iteration (or 'complexity factor') component of hashing exists.  Even if an
attacker were able to do all 3 of these things, it would take them an
exponentially long amount of time to brute force compared to if no
complexity factor existed.

HTH,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Thu, Apr 18, 2013 at 9:21 AM, NabbleSometimesSucks <
bigtrashcaninthesky@yahoo.com> wrote:

> drmike01. Sorry for so late in seeing this.
>
> Are you sure???
>
> That would be scary considering that the hash and the iterations is
> supposed
> to make it impossible for the dictionary attack to easily figure out
> password of password.
>
> If that is true then there is no reason to even encrypt it at all. the
> difference between in plain text and this encryption then would be just
> making it not readable to the visible eye.
>
> The whole purpose of Shiro's encryption here with SHA-128 or SHA-256 is
> that
> dictionary attacks would take a really long time, and that even if they
> figured one password out, that same "key" won't work on other accounts.
>
> Thanks
>
> Mark
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Encrypted-password-in-db-why-does-it-tell-the-Hash-and-iterations-in-it-tp7578510p7578619.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Encrypted password in db, why does it tell the Hash and iterations in it

[NabbleSometimesSucks <bi...@yahoo.com>]

drmike01. Sorry for so late in seeing this.

Are you sure???

That would be scary considering that the hash and the iterations is supposed
to make it impossible for the dictionary attack to easily figure out
password of password.

If that is true then there is no reason to even encrypt it at all. the
difference between in plain text and this encryption then would be just
making it not readable to the visible eye.

The whole purpose of Shiro's encryption here with SHA-128 or SHA-256 is that
dictionary attacks would take a really long time, and that even if they
figured one password out, that same "key" won't work on other accounts.

Thanks

Mark



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Encrypted-password-in-db-why-does-it-tell-the-Hash-and-iterations-in-it-tp7578510p7578619.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Encrypted password in db, why does it tell the Hash and iterations in it

[drmike01 <ms...@gmail.com>]

The password is stored as a one-way hash, so it's not really possible to
"decrypt" it. What the salt does is that it makes it resistent to dictionary
attacks. That said, if someone picks the password "password" then one could
figure it out regardless.



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Encrypted-password-in-db-why-does-it-tell-the-Hash-and-iterations-in-it-tp7578510p7578550.html
Sent from the Shiro User mailing list archive at Nabble.com.