<story><title>Dropbox employee’s password reuse led to theft of 60M+ user credentials</title><url>https://techcrunch.com/2016/08/30/dropbox-employees-password-reuse-led-to-theft-of-60m-user-credentials/?ncid=rss&amp;utm_source=feedburner&amp;utm_medium=feed&amp;utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29</url></story><parent_chain><item><author>rjbwork</author><text>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&amp;#x27;t want to log my DB connection strings!  It&amp;#x27;s very easy to overlook such things and produce them as part of application logging&amp;#x2F;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.</text></item></parent_chain><comment><author>rdtsc</author><text>&amp;gt;  It&amp;#x27;s very easy to overlook such things and produce them as part of application logging&amp;#x2F;exhaust without realizing it&lt;p&gt;Very true. It is a constant battle between debuggability and not leaking credentials.&lt;p&gt;In Erlang for example, when processes crash they dump their state, their neighbours, links to other processes, and other such useful stuff. That&amp;#x27;s very helpful, however it means it could dump credentials as well.&lt;p&gt;Luckily there a custom function to format the state of a process &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;erlang.org&amp;#x2F;doc&amp;#x2F;man&amp;#x2F;gen_server.html#Module:format_status-2&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;erlang.org&amp;#x2F;doc&amp;#x2F;man&amp;#x2F;gen_server.html#Module:format_stat...&lt;/a&gt; which helps with that. But have to implement that each process which holds credentials.&lt;p&gt;Also some of those log ingesting services provide a pre-indexer credentials filtering. I know Splunk has it:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;docs.splunk.com&amp;#x2F;Documentation&amp;#x2F;Splunk&amp;#x2F;6.4.3&amp;#x2F;Data&amp;#x2F;Anonymizedata&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;docs.splunk.com&amp;#x2F;Documentation&amp;#x2F;Splunk&amp;#x2F;6.4.3&amp;#x2F;Data&amp;#x2F;Anony...&lt;/a&gt;&lt;p&gt;Of course it is better if it is filtered out before that. But it could be a safety net perhaps.</text></comment>
<story><title>Dropbox employee’s password reuse led to theft of 60M+ user credentials</title><url>https://techcrunch.com/2016/08/30/dropbox-employees-password-reuse-led-to-theft-of-60m-user-credentials/?ncid=rss&amp;utm_source=feedburner&amp;utm_medium=feed&amp;utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29</url></story><parent_chain><item><author>rjbwork</author><text>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&amp;#x27;t want to log my DB connection strings!  It&amp;#x27;s very easy to overlook such things and produce them as part of application logging&amp;#x2F;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.</text></item></parent_chain><comment><author>dotancohen</author><text>I&amp;#x27;m actually fixing an issue with this right now. My logging framework is capturing user passwords, so I&amp;#x27;ve delayed the release one day while I blacklist certain known-sensitive information from the capture.</text></comment>