¿Es posible firmar digitalmente información con una contraseña?

Se movió a otra pregunta:

Cualquiera ¿Problemas con este diseño de seguridad para almacenamiento en la nube? El servidor ni siquiera necesita saber la contraseña para iniciar sesión en alguien

Hashear varias veces para disminuir la fuerza bruta es una mala idea, porque cada vez que hash reduce la entrofilia y hace que las colisiones incidentales sean más probables. Cuando intencionalmente quieras ralentizar el cálculo de hash, utiliza un algoritmo con una complejidad ajustable, como bcrypt .

Cuando desee asegurarse de que un mensaje es 1. del usuario del que espera que venga y 2. no se manipuló, debe usar un firma criptográfica . Se puede crear una firma criptográfica creando un hash del mensaje y luego encriptando ese hash con la clave privada del remitente. El receptor puede calcular el hash del mensaje que recibe, descifrar el hash supuesto con la clave pública del remitente y verificar que coincidan los hashes. La seguridad proviene del hecho de que es imposible forjar un hash coincidente sin conocer la clave privada del remitente.

¿Pero cómo obtiene la clave pública del remitente? O lo recibiste de antemano en un canal más confiable. O puede obtener una tercera parte de confianza para firmar de forma criptográfica la clave pública de los remitentes con su clave privada. Puede confiar en alguna "autoridad de certificación" confiable que verificó correctamente la identidad de su interlocutor. Y enhorabuena, acabas de reinventar TLS.

"Pero ¿qué pasa con la contraseña"? Bueno, en algún momento en el pasado, su servidor debe haber recibido la contraseña. O el hash de la contraseña. O el hash del hash de la contraseña. La contraseña es igual que la clave pública del usuario. ¿Cómo sabes que esta primera vez que recibiste esto no fue manipulado? Usted no puede Ningún sistema criptográfico funciona sin haber verificado la identidad de uno de los socios de comunicación en algún momento en el pasado, ya sea directamente oa través de una cadena de certificados.

Si no desea que el servidor tenga la contraseña ni ningún tipo de hash, necesitará algún tipo de credencial alternativo.

Podría, por ejemplo, crear su propia CA (no necesita que nadie más confíe en ella) y emitir los certificados de autenticación de cliente de los usuarios.

Sin embargo, si está dispuesto a darle al servidor el hash de la contraseña, puede hacer lo siguiente:

• Permite al usuario elegir una contraseña segura
• Permita que el usuario obtenga dos claves aleatorias de 256 bits de esta contraseña utilizando PBKDF2
• La primera clave ahora es una clave privada de firma ECDSA. El usuario calcula la clave pública y le proporciona durante el registro. Esta clave ahora representa al usuario. Cualquier solicitud de API debe estar firmada con esta clave.
• La segunda clave se utiliza para cifrar simétricamente los archivos.

Ahora, esto significaría que el usuario nunca puede cambiar su contraseña. Por este motivo, lo que suele ocurrir es lo siguiente:

• Permite al usuario elegir una contraseña segura
• Deje que el usuario derive dos claves, pwkeyA y pwkeyB.
• El usuario genera algo que puede usar para autenticarse correctamente con usted (por ejemplo, un par de llaves o una clave simétrica de la que recibe una copia). La clave simétrica o la clave privada es authKey.
• El usuario genera una clave de cifrado de archivo encKey.
• El usuario cifra encKey y authKey bajo pwkeyA, lo que resulta en un blob encriptado. Ahora te da esta burbuja encriptada. Nota: ahora puede intentar imponer una fuerza bruta a la contraseña del usuario derivando pwkeyA e intentando descifrar el blob.
• Si el usuario desea acceder a sus datos, solicita el blob, lo descifra con pwkeyA y se autentica utilizando authKey. Luego descarga un archivo y lo desencripta utilizando encKey.
• Si el usuario desea cambiar su contraseña, descarga el blob, lo desencripta utilizando pwkeyA (derivado de la contraseña anterior), lo cifra mediante pwkeyA (derivado de la nueva contraseña) y lo almacena en su servidor.
• Ahora, no quieres que nadie pueda borrar la mancha de teclas de tu usuario, ¿verdad? Es probable que tampoco desee que nadie permita descargar ese blob y ejecutar bruteforce sin conexión en él. Ahí es donde entra en juego pwkeyB. Esto se utiliza como una "contraseña" para iniciar sesión en el "almacenamiento de claves" y descargar / cargar el blob de claves. Tenga en cuenta que pwkeyB es básicamente un hash de la contraseña. Podría mejorar aún más la seguridad utilizando pwkeyB como una clave ECDSA privada y haciendo las cosas en el primer ejemplo.

Para verificar la integridad de los archivos, el usuario puede querer derivar más claves de la clave de cifrado y usar una para AES-CBC, la otra para HMAC. O utilizar un modo de cifrado de autenticación. Sin embargo, esto es irrelevante para el problema de administración de claves.

NOTA: Soy un tipo criptográfico de sillón ... (también conocido como no matemático), así que tenlo en cuenta. Sin embargo, he probado y "roto" una parte justa de criptografía mal implementada .

Paso 1, asegure adecuadamente el canal de comunicaciones.

Asegúrese de que sus certificados TLS / SSL implementen un perfecto secreto hacia adelante. La buena noticia es que no es difícil de implementar , pero tiene que hacerse en el servidor. Esto evita que los adversarios puedan capturar el tráfico y luego descifrarlo después de que hayan obtenido su clave TLS privada (ya sea legal o ilegalmente).

En Moxie's (escribió SSLstrip) crítica reciente de Lavabit , explica algunos problemas de seguridad relacionados con el correo electrónico proveedores, que pueden ser relevantes en su situación.

  

Un proveedor de correo electrónico típico (sin cifrar) tiene tres adversarios principales:

     

1. El operador, que tiene acceso al servidor.
  
2. Un atacante que puede obtener acceso al servidor.
  
3. Un atacante que puede interceptar la comunicación al servidor.
  

Me alegra ver que hasheado completamente la contraseña, pero comentarla me sacaría de mi profundidad. Escucho a mucha gente más inteligente en crypto que yo, recomiendo PBKDF2 .

Esta es solo una respuesta parcial, pero asegurar el canal de comunicaciones con perfecto secreto hacia adelante es el trabajo 1.