2

We have two sites, both are trusted.

On site1 we store the username and password for the user for site2.

We make api calls on site1's backend to site2 via basic auth (all over HTTPS).

Despite the insecurity of storing unencrypted passwords, assuming there is no data breach, this communication is secure on the backend. But what about the front end? I've seen people send the stored username and password to the front end, but this seems like an easy way for someone to grab your password.

It seems like it would be better to generate an auth token on the backend and pass it to the front end but I'm still a bit worried about possible security issues there.

I'm ok with implementing an oauth server if necessary on site2, but so far basic auth has been simpler and I'd like to stick with it if possible.

Sabrina Gelbart
  • 121
  • 1
  • 1
  • 4
  • 1
    Why hurt use oauth on site2 so there's no need to store password at all? – Neil Smithline Jul 27 '16 at 19:51
  • oAuth just seems like overkill. The plugin we found for it added 14 tables to our database! Not that I'm adverse to additional tables, I just don't see the proven benefit of it for our use case. – Sabrina Gelbart Jul 28 '16 at 20:54
  • I'm confused about your workflow. Why would you want to send the password back to the client? What is it that you are trying to accomplish. – Neil Smithline Jul 31 '16 at 20:40

1 Answers1

3

What you are proposing is very dangerous and against security best practices. One problem with it is that users tend to reuse the same passwords across different services. This means that one leaked password can lead to many of their accounts being left vulnerable. (Eg: recent Mark Zuckerberg hack). This combines with the fact that database contents sometimes leak due to flaws such as SQL injection.

To help protect these password reusers, websites must try very hard to protect the values of passwords as a breach makes many sites vulnerable.

This means only storing passwords in a secure, non-reversible format. You can read about the science at How to securely hash passwords?, but you're probably good if you use bcrypt with its default parameters.

If you were integrating with a 3rd-party site that only supported username/password authentication and that site was unwilling to provide a secure authentication mechanism, perhaps it would make sense to store passwords for the remote site (they should be securely encrypted when not in use). But you own the remote site, so just do the right thing and support a better login model than passwords.

Some possible strategies are:

  1. OAuth (perhaps via OpenID), SAML 2 or other existing system that support single sign-on.
  2. Using SSL mutual authentication, site2 could generate client certificates upon registration and pass them to site1. Then a database breach of site1 only exposes certificates and not user's passwords (remember that they use the same passwords for other sites).
  3. Impersonation (perhaps someone can add a better reference in the comments?) works if there's a strong trust model between site1 and site2. Basically, if the sites have the same authors and deployers, you could allow site1 to tell site2 to simply pretend that it's being called by JoeUser without any credentials. Site1 would need to securely authenticate to site2 to make sure that malicious users can't use this feature.
  4. Have the user type their site2 password into site1 whenever site1 needs it.

I'm sure there are more solutions, but storing passwords in a reversible format (eg: encrypted) is not a good practice. And storing passwords as clear-text is unforgivable.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • The site storing the passwords (site1) is SalesForce, I'm not entirely sure how they do, but clearly they feel strong enough in their security to offer it as a solution to developers doing integrations (see https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts_named_credentials.htm). I believe Zapier offers this as well. My question isn't necessarily if storing credentials on the backend is secure or not, it's more about how to pass those credentials to the front end without making it even more insecure, if that makes sense. – Sabrina Gelbart Jul 31 '16 at 19:19
  • 1
    @SabrinaGelbart - just because SalesForce supports uname/pwd authentication, it doesn't mean it is a secure option. They also support OAuth authentication, that is the secure option. I suspect that the uname/pwd solution is for legacy systems that can't support OAuth. The same is true for Zapier and the similar IFTTT. It is very risky to tell a 3rd-party app your password. – Neil Smithline Jul 31 '16 at 20:39
  • @SabrinaGelbart - there are only a [couple of questions on this site about IFTTT](https://security.stackexchange.com/search?q=ifttt). You can read their answers. Both point out that giving a 3rd-party site like IFTTT your credentials is risky. – Neil Smithline Jul 31 '16 at 20:43