How to transfer a database of usernames and passwords to a friend

Question

Caveat: I basically know nothing about information security, so I apologize in advance. I'll try to keep the question as general as possible.

I have a website X over which I have administrator privileges (someone else helped set up the website for me, though). There are users A,B,C on my website, with usernames and passwords.

I assume that somewhere in the infrastructure of my website, there's a:

• Table of registered usernames
• Table of encrypted passwords using a hash algorithm
• Some description of what this hash algorithm is

My trusted friend (important, because the security problem isn't that he might be shady) is making a different website Y. He wants A,B,C to be able to log into Y using the same credentials that they use for X. This is just a one-time thing; if D joins my website X tomorrow, my friend doesn't care about having D be able to use his login credentials on Y.

However, not all of my users necessarily want to join Y, and I don't know a priori which of them do.

What information can I give my friend such that, if A and C want to log into Y with their X credentials, they can, but also ensuring that the information of B is protected?

---

Note: I understand fully that A,B,C shouldn't be re-using their passwords on multiple websites, but X and Y are related in some way such that it would not only be convenient for the users, but it would also just make sense for them to have the same login credentials.

Answer 1

What you are asking to do violates some foundational concepts of security, so I am advising against a technical solution.

Credentials are meant to validate a user against that trusted asset. Passing those passwords to a 3rd party breaks that trust (even if you trust the 3rd party, your users do not have that chance). If I was one of your users, I would be very, very angry. What you propose is called a "breach". You are exposing a user's passwords to a 3rd party without their consent.

Even OAuth allows the user to specifically state what service they want to log in on, giving the power to the user.

The best solution is to simply invite the users to create a new account on the 3rd party service, and there are lots of ways to make that streamlined without disclosing your user's passwords. Like sending a pre-filled account creation link for the new site.

Answer 2

I assume that the passwords are not stored anywhere and that verification is done using hashes.

You have two choices, basically:

1. Give Y a dump of username and passwords and let Y care about how to integrate those
2. Use SSO (e.g. with OAuth): X becomes the trusted party and Y the relying client. This option works for all users registered at X, no matter when they joined nor when the SSO was enabled.

P.S.: These two options can be varied in many, many different ways. Which of these is most appropriate depends on the requirements, budget dedicated to the feature, ...

Answer 3

What information can I give my friend such that, if A and C want to log into Y with their X credentials, they can, but also ensuring that the information of B is protected?

The short answer is "nothing."

Since you don't know who out of the set of all users wants to be associated with the new site, you would have to include the entire set of users.

A straight forward reading of your question would imply you don't even know what you are handing over to your friend.

"I assume that somewhere in the infrastructure of my website, there's a: •Table of registered usernames •Table of encrypted passwords using a hash algorithm •Some description of what this hash algorithm is"

Maybe they are stored in plain text, or protected with a weak hashing algorithm. Are they salted or not? These are things that shouldn't be assumed, especially when you plan to hand them over to a third party.

Your friend may not be shady, but handing over credentials without knowing who wants to be associated with the new site is shady.

Metadata is real data.

For example, say someone joins site "A". The administrator gives the credentials to site "B" without the user's consent. Site "B" gets hacked, raided, or otherwise leaked. Now the user is associated with site "B" through no action of their own. What if site "B" is a terrorist site? Welcome to watch-list land. What if it's Ashley Madison? Welcome to "significant other" troubles. "Really, it wasn't me!"

If you're testing the new site's functionality, just use dummy data. Otherwise have the users opt in.