database - estandar - oauth authentication
Securly Almacenamiento de identificadores OpenID y tokens OAuth (5)
Estoy creando una aplicación web que utilizará los inicios de sesión de OpenID y los tokens de OAuth con Youtube. Actualmente estoy almacenando la identidad de OpenID y el token de OAuth / secreto de token en texto sin formato en la base de datos.
¿Es inapropiado almacenar estos valores como texto sin formato? Podría usar un cifrado de una vía para el identificador de OpenID, pero no sé si eso es necesario. Para los tokens de OAuth, necesitaría usar un cifrado bidireccional ya que mi aplicación depende de obtener el token de sesión para algunos usos.
¿Es necesario encriptar la identidad de OpenID? ¿Podría alguien usarlo para obtener acceso a la cuenta de un usuario?
El token y el secreto de OAuth deben mantenerse seguros en su base de datos, pero no puede almacenarlos usando el cifrado de 1 vía de la misma forma que lo haría con una contraseña. La razón es que necesita el token y el secreto para poder firmar la solicitud.
Este también sería el caso si está ejecutando un servidor OAuth, aún necesita el token / secreto original para verificar la solicitud.
Si lo desea, podría encriptarlos utilizando un algoritmo de cifrado bidireccional como AES para ofrecer seguridad en caso de que la base de datos o las copias de seguridad de la base de datos se vean comprometidas.
Hay dos escuelas de pensamiento aquí.
El primer argumento es que: debe tratar los tokens de OAuth como contraseñas. Si alguien tuviera acceso a su base de datos, obtuviera todos los pares OpenID / OAuth y ejecutara un ataque man-in-the-middle, podría suplantar a cualquier usuario en su sitio.
El segundo argumento es el siguiente: para cuando alguien tiene acceso a su base de datos y un acceso suficiente a su red para ejecutar un ataque de hombre en el medio, de todos modos le rocían las mangueras.
Personalmente, me equivoco por el lado de la precaución y solo los encripto; es una práctica estándar para las contraseñas, por lo que también podría darse esa pequeña tranquilidad adicional.
Mientras tanto, Google tiene este consejo:
"Los tokens deben tratarse de forma tan segura como cualquier otra información confidencial almacenada en el servidor".
fuente: http://code.google.com/apis/accounts/docs/OAuth.html
Y algún tipo al azar en la web tiene consejos específicos de implementación:
- Si están en un archivo de disco normal, protéjalos con los permisos del sistema de archivos, asegúrese de que estén encriptados y oculte bien la contraseña.
- Si están en una base de datos, cifre los campos, almacene bien la clave y proteja el acceso a la base de datos con cuidado. *
- Si están en LDAP, haz lo mismo.
http://brail.org/wordpress/2009/05/01/implementing-oauth-take-care-with-those-keys/
La URL de OpenID no debe encriptarse porque esta es su "identificación abierta" literalmente, todos deben conocer el valor. Además, la URL debe ser un índice en la base de datos y siempre es problemático cifrar el índice en la base de datos.
El token / secreto de OAuth debe ser secreto y el cifrado puede mejorar la seguridad si tiene que almacenar el token a largo plazo. En nuestra aplicación de consumidor OAuth, token / secret solo se almacena en sesión por un tiempo breve y elegimos no encriptarlos. Creo que eso es lo suficientemente seguro. Si alguien puede echar un vistazo al almacenamiento de nuestra sesión, probablemente también tenga nuestra clave de encriptación.
Sí, estos deben cifrarse simétricamente (por ejemplo, AES-256 en modo CBC) en reposo en una base de datos. Una forma sencilla de encriptar estos tokens es usar el cifrado de SecureDB como API RESTful de un servicio.
Divulgación: trabajo en SecureDB.
Primero, hay una aplicación registrada que tiene consumer_key y consumer_secret .
Cuando los usuarios se autentican y "permiten" su aplicación registrada, usted recibe de vuelta: un access_token que se considera la "contraseña" del usuario y permitiría SOLO SU aplicación actuar en nombre del usuario.
Por lo tanto, obtener solo access_token del usuario de su base de datos no ayudará mucho si no tienen también la consumer_key y consumer_secret para un acceso completo.
El proveedor de servicios compara los 4 parámetros bajo pedido. Sería inteligente encriptar estos 4 parámetros antes del almacenamiento y descifrarlos antes de la respuesta.
Esto es justo cuando necesita actualizar o realizar cambios en el propietario del recurso del usuario en nombre de un usuario. Para mantener a un usuario conectado a su sitio, use sesiones.