aplicación iOS: ¿contraseña de usuario hash en la aplicación o en el servidor?

Use SSL para manejar las comunicaciones a través de Internet de manera segura, luego introduzca la contraseña en el servidor. De lo contrario, el hash de la contraseña solo se convierte en la contraseña, en lo que respecta al servicio, y un atacante que obtiene acceso a su base de datos puede iniciar sesión como cualquiera de sus usuarios como si sus contraseñas estuvieran almacenadas en texto sin formato. SSL es vital para evitar que las credenciales de sus usuarios sean interceptadas en la red.

¿Por qué no pueden ser las dos cosas? Cuando el usuario ingrese su contraseña (como usuario nuevo o durante el inicio de sesión), córtelo por el lado del cliente y luego envíelo a través de un canal seguro al servidor, que lo hará nuevamente antes de hacer cualquier comparación. Redundante, seguridad distribuida; siempre que el atacante no esté "encendido" en la máquina en la que se ingresa la contraseña de texto simple (usando un keylogger, etc.), tendrá que romper múltiples hashes / capas de cifrado, y ningún nodo en el sistema sabe todo lo que necesita Se sabe que se obtiene de la contraseña de texto simple al hash almacenado en la base de datos.

El hash realizado en el servidor debe ser costoso, como bcrypt o scrypt; el del cliente aún debería ser un hash de fuerza criptográfica, pero algo más rápido como SHA-512 está bien.

El protocolo más seguro actualmente disponible incluye la criptografía de clave pública.

• generar una clave privada de "servidor" en el servidor. La clave privada nunca abandona el servidor. De alguna manera obtener la clave pública correspondiente a la aplicación. Usar HTTPS (TLS) es la forma más común de manejar esto. Normalmente, el servidor web sysadmin paga alrededor de $ 100 para obtener la clave pública firmada por una autoridad de certificación; pero esto no es técnicamente necesario.
• genere las claves privadas del "dispositivo" localmente en la aplicación, cuando la aplicación se ejecute por primera vez en ese dispositivo. Las claves privadas nunca abandonan el dispositivo. (La mejor práctica es generar una clave privada de "firma" y una clave privada de "cifrado", y luego las claves públicas derivadas de ellas). De alguna manera, obtenga esas claves públicas de la aplicación al servidor, tal vez en el momento en que el usuario crea una cuenta.
• Utilice algún tipo de autenticación mutua. Me han dicho que la parte (opcional) de "autenticación de cliente" de TLS ("Protocolo de enlace de TLS autenticado por el cliente") es una forma de hacerlo.

Lamentablemente, es un poco difícil manejar a un solo usuario que tiene varios dispositivos (cada uno con su propio par de llaves público / privado).

Parece que está buscando un acuerdo de clave autenticado por contraseña (PAKE). Entiendo que hay varias bibliotecas de software que admiten " protocolo de contraseña remota segura " (SRP) o algún otro PAKE protocolo, incluyendo GnuTLS , OpenSSL , Bouncy Castle , y otras implementaciones de TLS .