Risks associated to using a webhook to send new lead records to CRM (MS Dynamics) | Community
Skip to main content
Dan_Stevens_
Dan_Stevens_
Level 10
August 12, 2017
Question

Risks associated to using a webhook to send new lead records to CRM (MS Dynamics)

  • August 12, 2017
  • 1 reply
  • 2162 views

We are in the process of optimizing our current purposeful duplicates process.  Rather than create the duplicate in Marketo via a webhook (and then sync the lead to CRM), we would like to bypass the creation of the lead in Marketo and create it directly in CRM via a webhook.

As you probably know, passwords are stored as plain-text within the Admin area of Marketo:

It's been suggested that we setup S2S (server-to-server) authentication (client ID and token).  This would provide a more secure approach than just using the webhook with a userid and password.  Also, S2S accounts cannot be used for logging into CRM through the UI, it is programmatic use only - so if something needs to be stored in plain text then S2S account is a better candidate than an actual account. The risk is not eliminated completely but is minimized greatly since the account will only have access only on leads and that too in a time bound manner, we have the control of changing/deleting a S2S account from our system more than we have control with a normal account.

We have very strict data security guidelines in place.  So while the risks may be minimal, the team is still hesitant in moving forward with this solution.  I'd be interested to hear from others that have experience with webhooks and this sort of authentication.  Are the concerns that our team has legitimate?

@Sanford Whiteman​, @Paul Wilson​

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

SanfordWhiteman
SanfordWhiteman
Level 10
August 13, 2017

With regard to cleartext, remember this security adage: Any encrypted data that must be decrypted without user intervention is not truly secure. In other words, if stored credentials for a remote service are encrypted using an internal secret, but that secret is automatically used to decrypt the credentials before they're put on the wire, there will always be a point where they're in cleartext in memory.  We may crow about passwords being stored insecurely in INI files, but fuzzing passwords with a constant secret key doesn't solve the problem.  (A counterexample might be when passwords are encrypted with a machine key that's unique across machines and is specially protected by the OS.)

Also, if someone can use credentials to perform arbitrary actions, doesn't matter much if they can't read the credentials. If a webserver has a SQL injection vuln that allows me to read credit card info, the exact username/password/certificate used to log in isn't relevant to the task, right?  Now, the creds are relevant if I want to copy them offsite for further exploits. As you point out, Dan, locking down the creds to only be used for this one task is important. Then you've solved the collateral damage issue and need only look at how much damage can be caused via Marketo itself. If it's no worse than the damage you could cause with the native CRM integration, I'd say go for it.

To speak directly to the q "Is it safe to use a webhook to log into a remote database with a read-write account?": we do it all the time.

Terms & ConditionsAccessibility statement

Loading footer...