2 of 2 people found this helpful
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.