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:

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:

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.


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.

  • 1
    You hash on the server to avoid pass the hash flaws Commented May 14, 2016 at 23:09
  • From the link it says "The attack exploits an implementation weakness in the authentication protocol in that the password hashes are not salted, and therefore remain static from session to session until the password is next changed." So wouldn't that mean that they would need the salt as well, and if they cannot find the salt, idk how they would know the hashing algorithm either. Also... how exactly do they authenticate without being a part of my application? Would they just know the location and write their own application? I guess this is in the case of hacking my server...
    – XaolingBao
    Commented May 14, 2016 at 23:47
  • However, if my server were hacked, then wouldn't the code, that does the hashing, also be visible to the attacker, thus it wouldn't matter? Just a little confused on what exactly is being protected, and why server side hashing is safer[.[
    – XaolingBao
    Commented May 14, 2016 at 23:50
  • 1
    Yes, it would. Part of the benefit of hashing (using a well-accepted algorithm) is that an attacker knowing your hash algorithm, number of rounds, and salt doesn't mean they can reverse the hashes. They would have the benefit of knowing what route to go down, but with a decent number of rounds that still leaves them with an awful lot of work to do.
    – Bill Weiss
    Commented Nov 29, 2016 at 23:31


You must log in to answer this question.

Browse other questions tagged .