I was looking at this question
How does storing hash passwords work?
and every answer essentially says that Hashing is done via the server, or most of it should, as that is the safest way to do it. I understand their reasoning for Web based applications, but what about applications that reside on the Desktop, but connect to a server/database?
Now, the beauty of Shiro, is that I am able to use it in my Java Desktop code as well as in the web, but I'm curious if there is similar fears with the Desktop, and Hashing, as their is with web-clients. If so, how does Shiro handle this?
From what I've seen from Apache Shiro http://shiro.apache.org/realm.html#Realm-HashingCredentials
For example, let's say your application uses username/password pairs for authentication. And due to the benefits of hashing credentials described above, let's say you want to one-way hash a user's password using the SHA-256 algorithm when you create a user account. You would hash the user's entered plain-text password and save that value:
import org.apache.shiro.crypto.hash.Sha256Hash;
import org.apache.shiro.crypto.RandomNumberGenerator;
import org.apache.shiro.crypto.SecureRandomNumberGenerator;
...
//We'll use a Random Number Generator to generate salts. This
//is much more secure than using a username as a salt or not
//having a salt at all. Shiro makes this easy.
//
//Note that a normal app would reference an attribute rather
//than create a new RNG every time:
RandomNumberGenerator rng = new SecureRandomNumberGenerator();
Object salt = rng.nextBytes();
//Now hash the plain-text password with the random salt and multiple
//iterations and then Base64-encode the value (requires less space than Hex):
String hashedPasswordBase64 = new Sha256Hash(plainTextPassword, salt, 1024).toBase64();
User user = new User(username, hashedPasswordBase64);
//save the salt with the new account. The HashedCredentialsMatcher
//will need it later when handling login attempts:
user.setPasswordSalt(salt);
userDAO.create(user);
Since you're SHA-256 hashing your user's passwords, you need to tell Shiro to use the appropriate HashedCredentialsMatcher to match your hashing preferences. In this example, we create a random salt and perform 1024 hash iterations for strong security (see the HashedCredentialsMatcher JavaDoc for why). Here is the Shiro INI configuration to make this work:
[main]
...
credentialsMatcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher
# base64 encoding, not hex in this example:
credentialsMatcher.storedCredentialsHexEncoded = false
credentialsMatcher.hashIterations = 1024
# This next property is only needed in Shiro 1.0. Remove it in 1.1 and later:
credentialsMatcher.hashSalted = true
...
myRealm = com.company.....
myRealm.credentialsMatcher = $credentialsMatcher
...
I can create hashed passwords, with a salt, and store it to the DB, but it seems everything would be done on the client, unless there's a way for me to send the hash to the server, and then activate an application on there (now sure how I would do thatt from a desktop application),
Now according to http://shiro.apache.org/introduction.html
it says
Use a Session API in any environment, even without web or EJB containers.
and
Shiro attempts to achieve these goals for all application environments - from the simplest command line application to the largest enterprise applications, without forcing dependencies on other 3rd party frameworks, containers, or application servers.
while also showing their main focus,
Shiro targets what the Shiro development team calls "the four cornerstones of application security" - Authentication, Authorization, Session Management, and Cryptography:
...
while web support isn't a main focus
There are also additional features to support and reinforce these concerns in different application environments, especially:
Web Support: Shiro's web support APIs help easily secure web applications.
So my question is, how exactly is Apache Shiro making my hashes protected, if it isn't doing server side hashing for Clients that are Desktop based?
It clearly shows that Apache Shiro is meant for many enviroments, Desktop being one of them, as "Web Support" is a main focus.
A lot of the answers above seemed to talk about the Browser Client not being good due to the ease of access of seeing what's going on, so that's why you go to the server;
however there were mentions that if the hashed password was found, then the attacker could just fine a way to send the password directly to the server, and login that way, but I'm curious how they do that, if the only point of login "entry" is through my application? How will them knowing the hashed password benefit them if they cannot access the content???.... Or am I missing something...?
There is a SAlt that is required, and it seems that Salting is very important, and seems that it might solve the issue since, regardless if they find the hashing algorithm (somehow), they have no clue about the salt..
Which adds another question.... Where to store the Salt? Is it better to have the salt protected in a client, or should we call another database (which would be called from the Client, or possibly the server to do the hash)?
I'm a bit new to all of this, but I really want to learn about protecting my applications, and my websites as much as possible.
Thank you for any advice.
