¿Cómo es seguro almacenar una clave secreta de API en texto plano (en una base de datos)?

Tu pensamiento sobre esto es demasiado blanco y negro: seguro o inseguro. Aquí no hay seguridad, solo un espectro de riesgo.

Las compañías que proporcionan estas API están haciendo una llamada de juicio y tratando de equilibrar el riesgo con el rendimiento. No todas las llamadas a la API tienen que suceder a través de SSL. Piense en subir una imagen a S3, ¿necesita estar encriptada? Probablemente no. El requisito clave es que las llamadas estén autenticadas y autorizadas . Piense en un millón de llamadas distintas a SDB o SQS, ¿cuánta sobrecarga en el lado del cliente y del servidor creará SSL? Básicamente, SHA2 es rápido y SSL costoso, ahora se multiplica por 1,000,000.

¿Existe el riesgo de mantener las claves de la API en texto sin formato en el lado del servidor? Ciertamente, pero estas compañías están apostando a que pueden colocar otras mitigaciones en torno a las tiendas clave que reducen el riesgo a un nivel aceptable. (En última instancia, si obtengo acceso a tu almacén de claves, hash o texto simple, hay varias cosas maliciosas que puedo hacer, como intercambiar mi clave secreta por la tuya).

Acerca de su declaración: "realmente no ofrece ninguna garantía de que el cliente sea quien dice ser"

Eso es cierto en casi todos los esquemas de autenticación. Si alguien inicia sesión en este sitio con mi nombre de usuario y contraseña, no prueba que sean yo, solo que poseen mis credenciales. Si alguien usa mi huella digital para desbloquear un candado biométrico, indica que tiene alguna forma de proporcionar mi huella digital de una manera en que el candado lo acepte. Lo que cambia aquí es lo difícil que es. El robo de credenciales puede no ser tan difícil, y la suplantación de huellas digitales probablemente sea más difícil pero no imposible.

En resumen, no lo es, sin embargo, la clave secreta no necesariamente debe almacenarse en texto sin formato en el servidor. En sí mismo podría estar encriptado (pero no encriptado como otros han explicado) con información que forma parte de una solicitud del cliente.

Del mismo modo, si inicia sesión en un servicio que muestra sus claves secretas, no es necesario que las claves se hayan almacenado en texto sin formato, ya que podrían cifrarse con una derivada de una manera de la contraseña que se utilizó para iniciar sesión y que se mantiene asociada con la sesión. Si bien la clave secreta podría descubrirse si se accediera a los datos de la sesión, solo un subconjunto de claves secretas de cliente estaría en riesgo al mismo tiempo.

Recientemente agregué una respuesta a la otra pregunta que creo que también es relevante aquí. He editado mi respuesta un poco para abordar más directamente tu pregunta:

Hay una diferencia más importante entre una clave API y una contraseña. Las claves API son únicas para su sitio. La parte que hace que la seguridad de la contraseña sea tan importante es compartir la contraseña. Si alguien retiene la contraseña que un usuario guardó en su sitio, no es solo su sitio el que está comprometido: son todos los otros sitios para los que el usuario usó esa contraseña (y correo electrónico / nombre de usuario).

Una clave API es un escenario completamente diferente porque es exclusivo de su sitio. Como resultado, si es robado, el atacante obtiene acceso a su sitio, pero no gana nada que pueda utilizar contra el banco / correo electrónico / etc de esa persona. Esto significa que las claves de API son más similares a los identificadores de sesión que a las contraseñas.

Desde un punto de vista de seguridad, verá el problema con mayor claridad si piensa que las claves API no son contraseñas sino identificadores de sesión, especialmente en los casos en que las claves API pueden asignarse automáticamente (OAuth y similares). Sí, las claves de API pueden ser robadas, lo que resultará en que su cuenta se vea comprometida, pero las formas en que las claves son vulnerables a ser robadas son muy diferentes a las formas en que se puede robar una contraseña. En particular, una contraseña (en teoría) solo se almacena en dos lugares: la cabeza del usuario y su base de datos. Como resultado, su base de datos es la mayor amenaza para la seguridad de la contraseña (si ignoramos los ataques de phishing), y la reutilización de la contraseña hace que el peligro real para los usuarios finales sea muy alto en el caso de que su base de datos sea robada con contraseñas de texto simple.

Sin embargo, en el caso de un identificador de sesión o clave de API, ninguno de ese análisis es verdadero. Las claves API se almacenan en su base de datos, pero también se almacenan en cualquier cliente que use la contraseña. Esto podría estar en la memoria de una aplicación de front-end javascript (que es vulnerable a ataques XSS), un archivo de configuración en un servidor que se integra con la API (que es vulnerable a un conjunto de ataques completamente diferente), o quién sabe dónde más. Como resultado, la base de datos ya no es el principal vector de ataque para obtener acceso a las claves API. Esto definitivamente cambia las prioridades de seguridad.

Para hacer un punto más, los identificadores de sesión son la perspectiva correcta para ver las claves API desde. Cualquier sitio web que se basa en sesiones para almacenar datos de usuarios generalmente tiene un ID de sesión que también se almacena en la base de datos y se almacena en una cookie con el navegador del usuario. Como resultado, si su base de datos es hackeada y descargada, las sesiones de sus usuarios están completamente comprometidas. Un usuario malintencionado podría tomar un identificador de sesión, editar su cookie para su sitio web y iniciar sesión como cualquier usuario casi sin esfuerzo. Hashear los identificadores de sesión antes de almacenarlos en la base de datos detendría este ataque en particular, pero no haría nada para detener los ataques XSS que se usan más comúnmente para robar sesiones.