Stavo guardando questa domanda
Come funziona la memorizzazione delle password hash?
e ogni risposta in sostanza dice che l'hash è fatto tramite il server, o la maggior parte di esso dovrebbe, poiché questo è il modo più sicuro per farlo. Capisco il loro ragionamento per le applicazioni basate sul Web, ma per quanto riguarda le applicazioni che risiedono sul desktop, ma connettersi a un server / database?
Ora, la bellezza di Shiro è che sono in grado di usarlo sia nel mio codice Java Desktop che nel web, ma sono curioso di sapere se ci sono paure simili con il Desktop e Hashing, dato che il loro è con i web-client. Se è così, come fa Shiro a gestirlo?
Da quello che ho visto da Apache Shiro link
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
...
Posso creare password con hash, con un sale, e memorizzarlo nel DB, ma sembra che tutto sarebbe stato fatto sul client, a meno che non ci sia modo per me di inviare l'hash al server, e quindi attivare un'applicazione lì (ora sono sicuro di come farlo da un'applicazione desktop),
Ora secondo link
dice
Use a Session API in any environment, even without web or EJB containers.
e
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.
mostrando anche il loro obiettivo principale,
Shiro targets what the Shiro development team calls "the four cornerstones of application security" - Authentication, Authorization, Session Management, and Cryptography:
...
mentre il supporto web non è l'obiettivo principale
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.
Quindi la mia domanda è: in che modo esattamente Apache Shiro rende i miei hash protetti, se non sta eseguendo l'hashing lato server per i client basati su desktop?
Mostra chiaramente che Apache Shiro è pensato per molti ambienti, Desktop è uno di questi, poiché "il supporto Web" è l'obiettivo principale.
Molte delle risposte di cui sopra sembravano parlare del fatto che il Browser Client non è buono a causa della facilità di accesso di vedere cosa sta succedendo, quindi è per questo che vai al server;
tuttavia ci sono state menzioni che se la password hash è stata trovata, allora l'attaccante poteva semplicemente un modo per inviare la password direttamente al server, e accedere in quel modo, ma sono curioso di sapere come lo fanno, se l'unico punto di accesso "voce" è attraverso la mia domanda? Come faranno loro a conoscere la password hash se non riescono ad accedere al contenuto ??? .... O mi sto perdendo qualcosa ...?
C'è una SAlt che è richiesta, e sembra che Salting sia molto importante, e sembra che possa risolvere il problema dato che, indipendentemente dal fatto che trovino l'algoritmo di hashing (in qualche modo), non hanno idea del sale.
Che aggiunge un'altra domanda .... Dove conservare il sale? È meglio avere il sale protetto in un client, o dovremmo chiamare un altro database (che verrebbe chiamato dal client, o forse il server per fare l'hash)?
Sono un po 'nuovo a tutto questo, ma voglio davvero imparare a proteggere le mie applicazioni e i miei siti web il più possibile.
Grazie per qualsiasi consiglio.