What is the Most Secure Method to Handle Customer Submitted Credentials for a Third Party Site Without Retaining Access or Logging Them?

This topic was automatically generated from Slack. You can find the original thread here.

Howdy! I have a question about how to securely handle customer supplied usernames / passwords for a third party site:

I am building a workflow where I need to log into a 3rd party website using a customer supplied username/password. This site doesn’t have oauth, or any other authentication methods. I’m planning to have customers supply their credentials in the POST request directly to Pipedream, then use puppeteer to log in with the credentials, grab the needed information, and then log out, and close the session. I don’t need the credentials after that.

What is the best way for me to securely handle customer submitted credentials? I do not want to have any access to the credentials, or have them logged anywhere. I believe I could disable logging on the workflow. I don’t love doing that, since it is not ideal for troubleshooting. But open to it, if that is the best approach.

Is there a better way to accomplish this? Thanks in advance!

I’d recommend adding them as project secrets. You can’t see the values of secrets after saving, and they’re encrypted in our DB. Secrets are exposed as env vars, and references to env vars (process.env.VAR) shouldn’t show up in logs when used in the HTTP actions / code, so if you don’t add code to log them explicitly, they shouldn’t show up (you can test to make sure this works e2e). So then you shouldn’t need to disable all logging, if that helps

By the way, we’re thinking about a way for you to generate a secure link you can send to the customer to have them enter the creds, then we’d save those as a project secret and you’d never see the credentials at all. Would that be useful?

oh yes that would be killer.

My goal is to not have any access to their creds at all, but just use them once. I don’t even want to store them, but if they are encrypted, that would be acceptable, I think.

And I’m sorry - could you give me a rough lay of the land - how would I convert the user supplied credential into an environment variable, without seeing it?

Does the customer operate a secrets store (like AWS Secrets Manager / Parameter Store), where they could give you limited access to the secrets you need, and then you’d only access them when needed at runtime?

in order to save it as an env var in Pipedream, you would need to see them at least once to enter them

I suppose I could create an “intake” workflow that converts into env variables, and then turn off logging for that workflow only?

And sorry - maybe I didn’t clarify this: Each customer has their own username / password. So when customer A submits a post request, it will contain their own username/password. And then Customer B submits, and it’s their username/password, etc. So I’d be updating that env variable for every workflow run, with a different username/password. Do env variables work in this context?

Ah got it, no env vars wouldn’t work in that context. I’d recommend using a service that ingests the credentials from your customers and store them in a secrets store, then access the credentials at runtime. If you access the credentials directly in code, within a step, you can pass them directly in the HTTP request and log / return no credentials

Got it. Thank you for the insight!

So when will that “service that ingests the credentials” be ready for me to use? :smiley::smiley::smiley:

haha I’ll definitely keep you updated!

I’m using supabase for all of my customer data, so I guess I need to look into their new Vault feature, perhaps. Edit: Well, that may not fully solve my problem, because I can still technically access the credentials. I’ll keep researching. But welcome any tips.

But worst case scenario - can you verify if this is secure?

I create an intake workflow that the customer POSTS directly to, with their credentials. I use the credentials via a puppeteer step to log in, get info, then log out, and close the browser session. Then, I forward along the resulting information to another workflow (but not the username/password). And then I disable logging on that step.

If I do that, I believe there’s no way for me to see those credentials. Is that correct?

You’d need go disable logging on the workflow entirely since we log the body of the HTTP request by default

Ah yes, sorry, I meant disable logging on that workflow entirely.