4 ms·
This is a really good reason to be careful about what you log to log analytics platforms. I just recently implemented an ETL system that has the credentials (a
by rjbwork 10y ago
This is a really good reason to be careful about what you log to log analytics platforms. I just recently implemented an ETL system that has the credentials (along with other stuff about the job) for data access passed into it from a PaaS framework. While I want to log the information, I don't want to log my DB connection strings! It's very easy to overlook such things and produce them as part of application logging/exhaust without realizing it, especially now that we have mass adoption of things like Splunk, Logg.ly, CloudFront, Cortana Analytics, Elmah.IO, LogEntries, Seq, and a dozen others.
- rdtsc 10y ago> It's very easy to overlook such things and produce them as part of application logging/exhaust without realizing it Very true. It is a constant battle between debuggability and not leaking credentials. In Erlang for example, when processes crash they dump their state, their neighbours, links to other processes, and other such useful stuff. That's very helpful, however it means it could dump credentials as well. Luckily there a custom function to format the state of a process http://erlang.org/doc/man/gen_server.html#Module:format_status-2 http://erlang.org/doc/man/gen_server.html#Module:format_stat... which helps with that. But have to implement that each process which holds credentials. Also some of those log ingesting services provide a pre-indexer credentials filtering. I know Splunk has it: http://docs.splunk.com/Documentation/Splunk/6.4.3/Data/Anonymizedata http://docs.splunk.com/Documentation/Splunk/6.4.3/Data/Anony... Of course it is better if it is filtered out before that. But it could be a safety net perhaps.
- mootothemax 10y ago>Very true. It is a constant battle between debuggability and not leaking credentials. And there are so many ways of getting bitten. Another anecdote for you: I recently found out that an API wasn't logging errors anywhere. Easy enough to fix, plug in a library and bam, everything is nicely logged to the database. Including the HTTP headers. Headers that include API auth tokens. Ouch.
- dotancohen 10y agoI'm actually fixing an issue with this right now. My logging framework is capturing user passwords, so I've delayed the release one day while I blacklist certain known-sensitive information from the capture.
- mootothemax 10y ago> while I blacklist certain known-sensitive information Is there any way you can take the opposite approach and whitelist stuff to include? That way you don't have to worry about stuff sneaking in in the future. (not that blacklisting has ever bitten me in the behind before, no siree...)
- brianpan 10y agoGenerally a good approach when it comes to security- default to no access. Much safer in the even of programmer error, misconfiguration, etc.
- lima 10y agoAlso Linux kernel logs. Kernel ASLR requires kernel addresses to be secret, yet dmesg is full of them sometimes and you usually ship those out over unencrypted syslog.
- aram 10y agoCompletely agree. Here's another example: BitDefender (antivirus) passes your email and MD5 of your password in the hash when you want to go to your dashboard. When I contacted them more than 1 year ago about it, their "senior e-threat analyst" said it's nothing to worry about. Absolutely ridiculous. What to do when the company is ignorant and continues to use something as stupid as that?
- joshka 10y agoAlternatively use managed service accounts. You shouldn't even know or be able to expose the db connection credentials - let AD manage that for you. This is Windows specific advice and obviously doesn't count if your services don't support this (log a bug in the product if it doesn't).
- lawpoop 10y agoFor this reason, and others (version control, backups), I think we need to move to key authentication, ring of trust, etc.