Asegure forma de almacenar contraseñas en las API sin OpenID?

Question

Me hizo una pregunta similar aquí hace un tiempo, pero todos las respuestas estaban ofreciendo OpenID que es agradable, pero no funciona con los servicios que requieren autenticación que no lo usan (como Eventbrite).

Say Quiero crear una aplicación que sus listas de eventos de Brite evento, y sus análisis (que incluye Eventbrite). Cualquier persona puede inscribirse en este servicio a la lista de sus eventos. Pero desde Eventbrite no tiene OpenID para autenticarse, tengo que conseguir de alguna manera el nombre de usuario y contraseña para Eventbrite.

Algunas soluciones posibles son:

1. credenciales en tienda a YAML como esto . Hackable fácilmente.
2. Tienes usuario introduzca las credenciales en un formulario en mi sitio, guardar las credenciales a mi base de datos, y los utilizan para acceder a Eventbrite. Hackable fácilmente.
3. Tienes usuario introducir las credenciales y las he dejado pasar directamente a Eventbrite sin guardar, y ahorro los cookies cabecera de la respuesta a la base de datos, y cuando caducan, haga que conectarse de nuevo. ¿Es esto fácilmente piratear?

Este servicio hipotética también quiere comprobar automáticamente eventos (digamos a través de cron), por lo que no depende de que el usuario va a mi sitio a través del navegador. Así galletas o credientials necesitan ser almacenados en algún lugar.

La cosa es, después de pedir este pregunta similar sobre la confidencialidad y seguridad suena como usted debe no crear una aplicación que hace lo que yo estoy describiendo. Tiene que haber alguna manera de construir algo como esto está bien.

¿Cuál es esa manera? ¿Qué me estoy perdiendo? ¿Está bien para ir con # 3 y guardar las galletas (pero todavía necesitan que el usuario enviar su correo electrónico / contraseña a través de una forma que le envío a Eventbrite)? ¿Qué es una solución aceptable al problema?

Answer 1

There isn't a secure way to do this. You can employ workarounds, but that's about it.

1. Storing passwords in YAML or XML in cleartext is definitely out
2. In fact, even encrypting and storing passwords is wrong. Your application would need a way to decrypt the passwords, so the attacker can also decrypt the passwords.
3. The recommended way to store passwords is Salt + Hash, but because it becomes unrecoverable, it is useless in your case.
4. Because of 2 & 3, no matter where you store the users credentials, you are vulnerable.
5. Storing the cookies instead of the passwords is a better idea. But again, this involves the password going through your website, which isn't good.

Given your situation, storing the cookie is a better approach. Use HTTPS throughout, even on your website. Its less than ideal though, and you and your users should be aware of it.

Answer 2

Eventbrite has recently release new documentation describing how to implement OAuth2.0 for cross-site user authentication. I would recommend using our javascipt-based OAuth2.0 widget, which stores the user's authentication tokens in their browser's localStorage by default. Since the auth tokens are stored in the user's browser, and are prevented from being accessed by other domains, it's not likely that there would be any security leaks.

The need for email and password combos are completely avoided in this authentication scheme.

Answer 3

Most sites only support direct login with the original cleartext password, so you have to get, store and provide that too. And I would never ever trust you with that. The problem with your concept is that you require the password to be given to a third party. The solution is not to involve a third party, for example my browser is pretty good at storing and filling in passwords for me automatically (my hard-drive is password protected too). And they are dozens of other password wallet apps too. I wouldn't gain anything by subscribing, using your service.

Before going into such a business, consider you are going to be the #1 target. Facebook, Google are incredibly paranoid about security, spending a lot of time, money and effort to keep the logins safe. Do you have the same resources? Then you are a better target. Also by hacking your service, they immediately get multiple accounts, passwords of your users, also seeing who is always reusing its password.

Answer 4

For working with the Eventbrite API, I'd recommend ensuring that all connections are over SSL, and that you authenticate using a user_key rather than a username and password.

More information about authentication for the Eventbrite API is here: http://developer.eventbrite.com/doc/auth/

After logging in, users can find their user_key here: http://www.eventbrite.com/userkeyapi

This should prevent username and password information from being intercepted over the wire, or read from a local data store.