Twitter's Holy Bug Story

Quite the story. Lots of holes.

Get It Try It

DORSEYTOWN (Rixstep) — Sometime late last night, Twitter Support issued the following.



'We recently found a bug that stored passwords unmasked in an internal log. We fixed the bug and have no indication of a breach or misuse by anyone. As a precaution, consider changing your password on all services where you've used this password.'

https://twitter.com/TwitterSupport/status/992132808192634881
http://archive.fo/neGLn

Shortly after, Twitter CTO Parag Agrawal came with this:



https://twitter.com/paraga/status/992135139994943488
http://archive.fo/miERK

And then this:



https://twitter.com/paraga/status/992146630232043520
http://archive.fo/8Afdk

That's the official story at any rate. An alert was sent to every Twitter account when logging in (some several times) asking them to change their password.

There are approximately 330 million Twitter accounts, making this the biggest IT privacy scandal in history.

The only problem with Twitter's holy bug story is it's all wrong. And it's highly disconcerting to see how many bought into the crap. Then again, what would they know?

• Bugs don't make code suddenly store passwords.
• Passwords are never 'masked' or 'unmasked'. There is no such thing.
• 'No indication of a breach or misuse' is in conflict with Twitter's own panic.

Passwords never enter secondary storage in the clear. They're sent over an encrypted SSL connection to the server, where they're not so much encrypted as 'digested', as in message digests are created around them. Fifty years ago, the standard was DES ('Data Encryption System') which was planned as 64-bit until the NSA got in the picture and demanded they be brought down to 56-bit, so the colossus machines at Ft Meade would have a chance at cracking them.

Today standards are much more stringent, SHA512 being about the lowest acceptable.

The password:

THISISMYPASSWORD

Becomes:

f66568cdb503c0255f706d90266d4cde1af130940b4269f44e69d5bced8c6ed0
4c076040b7bbcb4d48e99bc2ea607b998a2dde276f27372ce514163e14319ace

And the password:

abc

Becomes:

ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a
2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f

A message digest must be unique. So-called 'collisions' (two input values resulting in same digest) aren't allowed. Creating digest algorithms isn't easy.

Some digest forms prior to SHA512 are known to have collisions.

The other half of this is: you can't 'decrypt' a digest. It's only useful one way.

It is therefore impossible to derive a plain text password from an 'encrypted' one.

So it follows that the Twitter breach had to occur at the moment of login and only at the moment of login. Twitter can't know your password otherwise, at any other time. Your password is encrypted (really encrypted) in transit (so it can be decrypted on arrival). Once it's arrived, it's put through a message digest (eg SHA512, SHA1014, and so forth). After that, it can't be retrieved at all.

As for logins: your plain text password can't be compared to anything on Twitter's servers, they have nothing to compare it to, they're not supposed to ever store your password in plain text, not even for 'testing' purposes (and there's no reason they'd ever need to). Instead, Twitter runs your password through a message digest and compares the result with what they have on disk.

Twitter knows you gave the correct password if the message digests match - there is no other way.

The whole point of this system is to ensure user privacy - to protect the interests of the user. And these were blatantly stomped on by Twitter.

√ There was no 'bug'. You don't accidentally make a line of code to log plain text passwords to secondary storage unless you want to get sued or sacked. No one does this. There is no reason, even under supposed 'testing' circumstances. The plain text password is of no use to Twitter, none, not even for 'testing', unless their purpose is to let them, or someone they entrust, login to your account.

Can it be more plain and simple?

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.