Question

I asked a similar question here a while back but all the answers were offering OpenID which is nice but it doesn’t work with services that require authentication that don’t use it (such as EventBrite).

Say I want to create an app that lists your events from event brite, and their analytics (which eventbrite includes). Any person can sign up for this service to list their events. But since EventBrite doesn’t have OpenID to authenticate, I need to somehow get the user login and password to EventBrite.

Some possible solutions are:

1. Store credentials in YAML like this. Easily hackable.
2. Have user enter in credentials into a form on my site, I save the credentials to my database, and use them to login to EventBrite. Easily hackable.
3. Have user enter in credentials and I pass them directly to EventBrite without saving, and I save the response header Cookies to the database, and when they expire, have them login again. Is this easily hackable?

This hypothetical service also wants to automatically check events (say via cron), so it doesn’t depend on the user going to my site via the browser. So cookies or credientials need to be stored somewhere.

The thing is, after asking this similar question about confidentiality and security it sounds like you should never build an application that does what I’m describing. There’s got to be some way building something like this is okay.

What is that way? What am I missing? Is it okay to go with #3 and save the cookies (but still needing the user to submit their email/password via a form which I send to Eventbrite)? What is an acceptable solution to the problem?

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.