Twitter disclosed on Thursday afternoon that a bug in the company's password-handling pipeline had logged user passwords in plaintext to an internal log file before the bcrypt hashing step (Twitter blog post by Parag Agrawal, CTO, May 3). The bug was discovered through internal review, the affected log was identified and contained, the company has stated that there is no evidence of misuse or external access to the affected logs, and the company is recommending that all users change their Twitter passwords as a precaution. Approximately 330 million accounts are potentially affected — the entire active user base.
The disclosure is unusually clean by current industry standards. The notification was issued voluntarily, on the basis of an internal-discovery and risk-assessment exercise, with no evidence of external compromise and no specific harm having been demonstrated to users. Twitter's choice to disclose anyway — rather than to remediate quietly and not publicise — is the right call and the right precedent. The post-Uber-disclosure environment makes that kind of voluntary disclosure more clearly the operationally appropriate posture, and the GDPR enforcement window starting in three weeks does not directly require disclosure of incidents with no demonstrated risk to data subjects but does set the cultural norm that disclosure is the default.
The technical lesson is about logging hygiene. The bug — which Twitter has characterised as "we identified a bug that stored passwords unmasked in an internal log" — is a class of error that is depressingly common across organisations of all sizes. Application code logs the value of variables for debugging or audit purposes; the value of a variable holding a credential, before the credential is processed by a one-way hashing function, is the credential itself; the log file ends up containing the credentials. The defensive practices to prevent this are well-known: tag credential-bearing variables in the type system or in code-review checklists, use a logging framework that filters known credential field names from log output, and audit log content periodically for credential-shaped strings. None of these practices are universal. The Twitter case is a worked example for customer briefings on why the practices matter.
The CSO of the customer-organisation pen-testing engagements I have been on this year asks, with some frequency, what specific things to add to the application-security review checklist, and the answer for some months has included logging-pipeline review as a specific category. Most application security reviews focus on the input side (input validation, authentication, authorisation) and on the persistence side (database storage, encryption-at-rest, key management). The logging side — what does the application write to log files, where do those log files end up, who can read them, how long are they retained — is reviewed less consistently and is, on the working evidence, where many of the credential-disclosure incidents in customer-organisation environments originate. We have been pushing this as a review category for the post-WannaCry pen testing programme; the Twitter case will sharpen the conversation.
For the customer organisations, the action this week is the standard credential-rotation and authentication-anomaly-monitoring posture. Customer-organisation employees who use Twitter and have passwords that overlap with corporate credentials need to rotate; the credential-stuffing detection rules at the customer-organisation authentication endpoints will be tuned for the next few weeks against the elevated risk of Twitter-credential-derived attempts. The corporate-side direct exposure is small; the indirect exposure via password-reuse is the more substantial concern.
The wider point — which I have been making in customer briefings continuously since the LinkedIn 2012-resurfacing in May 2016 — is that the credential-reuse threat model is now structurally adverse to password-only authentication. The aggregate exposed-credential population is large enough that any password used across multiple services should be considered known to adversaries. The defensive posture is multi-factor authentication everywhere it can be enforced, and the customer-organisation programmes to roll out MFA across staff and customer populations are the most consequential single security investment of the past three years. The Twitter incident is one more datapoint in that pattern; the lesson is the same.
I will note for the personal-blog reader that I changed my own Twitter password after the disclosure and that doing so revealed several other services where I had reused some component of the password — none of them critical, all of them now reset. The discipline of password-management discipline is one I keep meaning to write a personal post about. I will. Sometime.