[#2421] bugfix: restored ability to match passwords from Shiro 1.x that have …

[lprimak]

…private salt

fixes #2421

Following this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a GitHub issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a GitHub issue. Your pull request should address just this issue, without pulling in other changes.
• Format the pull request title like [#XXX] - Fixes bug in SessionManager,
  where you replace #XXX with the appropriate GitHub issue. Best practice
  is to use the GitHub issue title in the pull request title and in the first line of the commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• add fixes #XXX if merging the PR should close a related issue.
• Run mvn verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
• Committers: Make sure a milestone is set on the PR
• Committers: Use "Squash and Merge" to combine all commits into one when merging a PR when appropriate.

Trivial changes like typos do not require a GitHub issue (javadoc, comments...).
In this case, just format the pull request title like [DOC] - Add javadoc in SessionManager.

If this is your first contribution, you have to read the Contribution Guidelines

If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement
if you are unsure please ask on the developers list.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
• In any other case, please file an Apache Individual Contributor License Agreement.

[lprimak]

@bmarwell is it true that Argon and BCrypt do not use private salt? Or is private salt needs to be added to the new algorithms as well?

[bmarwell]

Hi, no salt needs to be nor can be supplied by the user. See:
https://security.stackexchange.com/a/222746

The reason: argon2 and bcrypt and scrypt are NOT general purpose hashes. Hashes are meant to be fast, eg for checking data integrity. They were never meant to be used for passwords. This and adding a salt was always some kind of misuse and workaround.

General purpose hashes: meant to be fast. Adding a salt protects against rainbow tables when misused for passwords. And that's why they need so many rounds.

Password hashing algorithms (like scrypt, argon 2): meant to be memory hard or CPU hard or both, slow. Specifically for protecting passwords. Usually creating a random hash internally.

So, yeah, don't supply user hashes. For the API, just ignore them. Add to the Java doc that they will be ignored for modern functions. sha1, md5 etc are to be removed in the future for this reason.

[lprimak]

Thanks!
Since salt was removed from the API, I think we are good there.

[lprimak]

@bmarwell great feedback, I will make it so

All feedback has been incorporated into the PR now.
Thanks Ben!

[steinarb]

Hm... this one might actually affect both my own usage and the JDBC realm....?

I will dig into both my own code and the changes I made to the JDBC realm (both are very old) and see if I can remember, but too sleepy tonight to think clearly.

[lprimak]

Wonderful. Looking forward to your feedback in the next few days :)
No need to be sleepy

[steinarb]

@lprimak A question about tests: I note no tests on this PR, is there a policy for tests in shiro?

[lprimak]

@steinarb There is no policy currently, but you are right, there probably should be a test added.
The only reason I didn't consider it a must-do is because this is a 1.x backward-compatibility,
but you are making me reconsider. Thank you

[lprimak]

@steinarb I have now added a test

[steinarb]

LGTM!