iframe basic auth or token security

Question

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.

Answer 1

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.