¿Es seguro para autenticar solicitudes de API utilizando un RSA? [cerrado]

0

Me gustaría dar a nuestros usuarios acceso a datos privados mediante una API.

  • No quiero almacenar las credenciales de la API en mi base de datos. (Por la misma razón no almaceno la contraseña en la base de datos.

  • No tengo ningún problema en que otros podrán leer los datos que se envían a nuestro servidor.

  • No quiero que las credenciales se envíen a nuestro servidor porque otros podrán clonar las credenciales.

  • No confío en SSL. (Algunos usuarios pueden tener certificados de raíz que no son de confianza)

Lo que otros hicieron, fue usar api_key y secreto. Usaron el secreto para firmar el mensaje. (Consulte Bitfinex, por ejemplo, enlace )

Pensé que es más seguro usar RSA. Cada usuario obtendrá una clave privada (no la almacenaremos). Lo usarán para cifrar el mensaje (usando nonce), usaremos una clave pública para descifrarlo.

Sé que hay un problema de rendimiento con RSA, pero es para mensajes muy cortos, por lo que no me concierne.

¿Por qué otros no lo hacen? ¿Hay algún problema de seguridad con él?

    
pregunta Aminadav Glickshtein 10.01.2018 - 11:37
fuente

2 respuestas

1

Es posible crear un sistema seguro de esta manera utilizando RSA, pero estás buscando un mundo de dolor y es probable que termines creando un sistema inseguro.

RSA es una primitiva criptográfica de muy bajo nivel, es un nivel demasiado bajo para que un desarrollador de aplicaciones pueda trabajar y usarlo lo expone a muchas vulnerabilidades si no se usa correctamente. Deje el código criptográfico de escritura a los expertos y use criptografía de nivel superior, ya sea TLS o OpenPGP debe ser el nivel que está mirando, no RSA.

  

Sé que hay un problema de rendimiento con RSA, pero es para mensajes muy cortos, por lo que no me concierne.

El problema con RSA no es solo el rendimiento. RSA no se puede usar para cifrar datos más grandes que el tamaño de la clave menos los rellenos, lo que significa que una clave RSA de 2048 bits tiene una tamaño máximo de entrada de 256 bytes (o 245 bytes si usa el relleno v1.5). Esto significa que si desea cifrar datos más grandes que este tamaño, debe implementar un modo de encadenamiento y encadenamiento El modo es una de las cosas más fáciles de equivocarse al implementar la criptografía. Además, nadie ha implementado nunca o realiza ningún criptoanálisis en el modo de encadenamiento RSA (la mayoría de los modos de encadenamiento se analizan en busca de cifrados simétricos), por lo que está solo.

Otro problema es que todas las primitivas criptográficas eventualmente deben reemplazarse a medida que las computadoras se vuelven más fuertes y se encuentran vulnerabilidades en estas primitivas. Por lo tanto, todas las aplicaciones de criptografía prácticas deben agregar metadatos que permitan la negociación y el reemplazo de las primitivas de cifrado y sus parámetros. TLS, S / MIME, OpenPGP y el formato hash de contraseña de cifrado tienen esta capacidad incorporada en el protocolo. Este es otro aspecto en el que es fácil equivocarse.

Otro problema que no hace RSA simple es la prevención de repetición. Para esto, necesitas agregar una sal o IV, y posiblemente un desafío. Y el la firma de capas y el cifrado También viene con sus propias trampas.

Podría pasar todos los días explicando los diversos escollos si está tratando de usar RSA simple para implementar cualquier sistema de criptografía.

Los protocolos de alto nivel como OpenPGP y TLS usan RSA como la primitiva subyacente, pero cuando se usan protocolos criptográficos de alto nivel, los expertos en criptógrafos han pensado sobre estos temas y sus implementaciones también han sido altamente analizadas. Todos los problemas restantes se resuelven o es bastante fácil configurar el sistema cuando hay una compensación.

OpenPGP, en particular, tiene un modo de firma, que efectivamente hace lo que usted mencionó, usando una clave privada para firmar un dato para probar la autoría, aunque de formas más sofisticadas. Una firma OpenPGP se crea cifrando un hash del mensaje en lugar del mensaje en sí mismo, evitando así la necesidad de encadenar y agrega una cantidad de metadatos para proteger contra varios ataques. TLS tiene propiedades similares durante el protocolo de enlace si utiliza la autenticación mutua pero están implícitas en la conexión, por lo que puede no ser adecuado si desea almacenar y / o enviar la prueba de autoría a otra entidad.

TL; DR No haga su propia criptografía . Si necesita conservar la prueba de autoría, use la firma OpenPGP; de lo contrario, simplemente ajuste la comunicación en TLS utilizando la autenticación mutua.

  

¿Por qué otros no lo hacen? ¿Hay algún problema de seguridad con él?

Debido a que es estúpidamente complicado hacerlo bien, cuando puedes usar la autenticación mutua TLS con solo unas pocas líneas de código. A menos que su esquema sea tan masivamente analizado como TLS y OpenPGP, puedo asegurarle que su esquema tendrá puntos débiles que prácticamente no tendrá oportunidad de descubrir.

    
respondido por el Lie Ryan 10.01.2018 - 13:22
fuente
0
  

Usaremos una clave pública para descifrarla.

Lo que propones es cambiar el significado de privado y público dentro de un par de claves RSA. La clave pública se considera pública ya que su conocimiento por parte de un atacante no es un problema de seguridad. Pero, como usted propone cifrar con la clave privada y descifrar con la clave pública, esta última es la que debe protegerse, es decir, su clave pública debe mantenerse privada, mientras que la clave privada asociada puede publicarse. / p>

En otras palabras: un atacante que obtiene acceso al servidor puede descifrar cualquier mensaje que se envíe al servidor usando solo la información que se encuentra en el servidor (es decir, sus claves "públicas"). Y esto es exactamente lo que intentaste prevenir en primer lugar.

    
respondido por el Steffen Ullrich 10.01.2018 - 12:06
fuente

Lea otras preguntas en las etiquetas