Entiende el código correctamente previamente a utilizarlo a tu proyecto y si tquieres aportar algo puedes compartirlo con nosotros.
Solución:
Su pensamiento sobre esto es demasiado blanco y negro: seguro o inseguro. Aquí no hay caja fuerte, solo un espectro de riesgo.
Las empresas que proporcionan estas API están tomando decisiones y tratando de equilibrar el riesgo con el rendimiento. No todas estas llamadas a la API deben realizarse a través de SSL. Piense en cargar una imagen en S3, ¿es necesario cifrarla? Probablemente no. El key requisito es que las llamadas sean autenticado y autorizado. 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 caro, ahora multiplíquelo por 1.000.000.
¿Existe algún riesgo al mantener la API? keys en texto plano en el lado del servidor? Ciertamente, pero estas empresas están apostando a que pueden poner otras mitigaciones en torno a esos key tiendas que reducen el riesgo a un nivel aceptable. (En última instancia, si tengo acceso a su key almacenar, hash o texto sin formato, hay varias cosas maliciosas que puedo hacer, como intercambiar mi secreto key para ti.)
Acerca de su declaración: “realmente no proporciona ninguna garantía de que el cliente sea quien dice ser”
Ese es true sobre 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 sea yo, solo que posee 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 que el candado lo acepte. Lo que cambia aquí es lo difícil que es. Robar credenciales puede no ser tan difícil, hacerse pasar por las huellas dactilares probablemente sea más difícil, pero no imposible.
En resumen, no es, sin embargo, el secreto. key no es necesario que se almacene en texto plano en el servidor. Podría estar encriptado (pero no codificado como otros han explicado) con información que es parte de una solicitud del cliente.
Del mismo modo, si inicia sesión en un servicio que muestra su secreto keys, el keys no es necesario que se hayan almacenado en texto plano, ya que podrían cifrarse con un derivado unidireccional de la contraseña que se utilizó para iniciar sesión y que se mantiene asociada con la sesión. Mientras el secreto key podría descubrirse con acceso a los datos de la sesión, solo un subconjunto del secreto del cliente keys estaría en riesgo en cualquier momento.
Recientemente agregué una respuesta a la otra pregunta que creo que también es relevante aquí. Sin embargo, he editado un poco mi respuesta para abordar más directamente su pregunta:
Hay una diferencia más importante entre una API key y una contraseña. Las claves de API son exclusivas de su sitio. La parte que hace que la seguridad de las contraseñas sea tan crítica es el uso compartido de contraseñas. Si alguien obtiene la contraseña que un usuario guardó en su sitio, no es solo su sitio el que está comprometido: es cualquier otro sitio para el que el usuario usó esa contraseña (y correo electrónico / nombre de usuario).
Una clave API es un escenario completamente diferente porque es única para su sitio. Como resultado, si es robado, el atacante obtiene acceso a su sitio, pero no obtiene nada que pueda aprovechar contra el banco / correo electrónico / etc. de esa persona. Esto significa API keys son más parecidos a identificadores de sesión que a contraseñas.
Desde el punto de vista de la seguridad, verá el problema con más claridad si piensa en API keys no como contraseñas, sino como ID de sesión, especialmente en los casos en que API keys se puede asignar automáticamente (OAuth y similares). Sí, API keys pueden ser robadas, lo que provocará que su cuenta se vea comprometida, pero las formas en las que keys son vulnerables al robo son muy diferentes a las formas en que se puede robar una contraseña. En particular, una contraseña (teóricamente) 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 las contraseñas (si ignoramos los ataques de phishing), y la reutilización de contraseñas 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 sin formato.
En el caso de un identificador de sesión o API key sin embargo, ninguno de esos análisis es true. API keys se almacenan en su base de datos, pero también se almacenan en cualquier cliente que esté usando la contraseña. Esto podría estar en la memoria de una aplicación javascript de front-end (que es vulnerable a ataques XSS), un archivo de configuración en un servidor que se está integrando 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 vector de ataque principal desde el cual obtener acceso a la API. keys. Esto definitivamente cambia las prioridades de seguridad.
Para señalar un punto más, los identificadores de sesión son la perspectiva adecuada para ver la API keys desde. Cualquier sitio web que se basa en sesiones para almacenar datos del usuario normalmente tiene una identificación 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 pirateada y descargada, las sesiones de su usuario se verán completamente comprometidas. Un usuario malintencionado podría obtener una identificación de sesión, editar su cookie para su sitio web e iniciar sesión como cualquier usuario sin casi ningún esfuerzo. El hash de 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.