I've seen both approaches, variables & constants, with storing API credentials. I've also seen private keys stored outside the webroot.
In all these cases you have, roughly, the same level of security. An intruder needs to penetrate (code injection) and discover your credentials. You could argue that with constants or external files are more "secure" since an intruder is unlikely to know about those, whereas he will likely know the
variables table will have many goodies in it, but as any security-minded person will tell you, security through obscurity just isn't security.
Anyone that has access to inject server-side code will eventually figure out how to grab everything if they're so motivated. Given that, your best bet for security is to prevent penetration in the first place.
- Keep all your whole software stack (Drupal, contrib modules, web server, database, & OS) up to date.
- Be proactive about monitoring any odd errors occurring in Drupal / web server logs.
- Follow good programming practices (e.g. understand how to defend yourself against SQL injection, XSS, and other attacks)
- Don't install modules / PHP libraries from an untrusted source
- Keep up to date about any news with Drupal/PHP or any exploits related to your entire stack (e.g. drupal.org has security mailing list for recently discovered exploits)
Unless you're a high profile target, the most likely attacks you will see are script bots hitting you with well known exploits. As such, the above advice should keep you covered. Just keep in mind, the bigger you are the more time you should be investing into security.
With all that said, I'd say the only other difference between the different methods of securing credentials is usability. If these are credentials that a developer should only ever touch, constants/secure files should be fine. If these are credentials that can change (e.g. module reuse across many sites) and you want other non-developers to change them, then the variable approach is the way to go.