Estaba mirando esta pregunta
¿Cómo funciona el almacenamiento de contraseñas hash?
y cada respuesta esencialmente dice que el hash se realiza a través del servidor, o la mayoría debería, ya que es la forma más segura de hacerlo. Entiendo su razonamiento para las aplicaciones basadas en la Web, pero ¿qué pasa con las aplicaciones que residen en el Escritorio, pero que se conectan a un servidor / base de datos?
Ahora, la belleza de Shiro, es que puedo usarlo en mi código de Java Desktop así como en la web, pero tengo curiosidad por si hay temores similares con el Desktop y el Hashing, ya que son con web-clientes. Si es así, ¿cómo maneja esto Shiro?
Por lo que he visto de Apache Shiro enlace
Por ejemplo, supongamos que su aplicación utiliza pares de nombre de usuario / contraseña para la autenticación. Y debido a los beneficios de las credenciales de hash que se describen anteriormente, supongamos que desea crear una contraseña de usuario de hash unidireccional mediante el algoritmo SHA-256 al crear una cuenta de usuario. Debería codificar la contraseña de texto sin formato del usuario y guardar ese valor:
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);
Ya que tiene el hash SHA-256 de las contraseñas de sus usuarios, debe decirle a Shiro que use el HashedCredentialsMatcher apropiado para que coincida con sus preferencias de hashing. En este ejemplo, creamos un salt aleatorio y realizamos 1024 iteraciones de hash para una mayor seguridad (consulte el HashedCredentialsMatcher JavaDoc para saber por qué). Aquí está la configuración de Shiro INI para hacer que esto funcione:
[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
...
Puedo crear contraseñas con hash, con un salt, y almacenarlas en la base de datos, pero parece que todo se haría en el cliente, a menos que haya una manera de enviar el hash al servidor y luego activar una aplicación en allí (ahora estoy seguro de cómo lo haría desde una aplicación de escritorio),
Ahora de acuerdo a enlace
dice
Utilice una API de sesión en cualquier entorno, incluso sin contenedores web o EJB.
y
Shiro intenta alcanzar estos objetivos para todos los entornos de aplicaciones, desde la aplicación de línea de comandos más simple hasta las aplicaciones empresariales más grandes, sin forzar las dependencias de otros marcos de terceros, contenedores o servidores de aplicaciones.
mientras que también muestra su enfoque principal,
Shiro apunta a lo que el equipo de desarrollo de Shiro llama "los cuatro pilares de la seguridad de la aplicación": autenticación, autorización, gestión de sesión y criptografía:
...
mientras que el soporte web no es un foco principal
También hay características adicionales para apoyar y reforzar estas inquietudes en diferentes entornos de aplicación, especialmente:
Soporte web: las API de soporte web de Shiro ayudan a proteger fácilmente las aplicaciones web.
Entonces, mi pregunta es, ¿cómo es exactamente que Apache Shiro está protegiendo mis hashes, si no está haciendo hashing del lado del servidor para los Clientes que están basados en el Escritorio?
Esto muestra claramente que Apache Shiro está diseñado para muchos entornos, el escritorio es uno de ellos, ya que el "Soporte Web" es un enfoque principal.
Muchas de las respuestas anteriores parecían hablar de que Browser Client no es bueno debido a la facilidad de acceso para ver lo que está sucediendo, por lo que es por eso que va al servidor;
sin embargo, se mencionó que si se encontraba la contraseña con hash, entonces el atacante podría encontrar una manera de enviar la contraseña directamente al servidor e iniciar sesión de esa manera, pero tengo curiosidad por cómo lo hacen, si es el único ¿Punto de inicio de sesión "entrada" es a través de mi aplicación? ¿Cómo sabrán que la contraseña con hash les beneficiará si no pueden acceder al contenido? ... ¿O me falta algo ...?
Se requiere un SAlt, y parece que Salting es muy importante, y parece que podría resolver el problema ya que, independientemente de que encuentren el algoritmo de hash (de alguna manera), no tienen idea de la sal.
Lo que agrega otra pregunta ... ¿Dónde almacenar la sal? ¿Es mejor tener la sal protegida en un cliente, o deberíamos llamar a otra base de datos (a la que se llamaría desde el Cliente, o posiblemente al servidor para hacer el hash)?
Soy un poco nuevo en todo esto, pero realmente quiero aprender sobre cómo proteger mis aplicaciones y mis sitios web tanto como sea posible.
Gracias por cualquier consejo.