From: Twitter International Company

Twitter lied, so we don't use it much anymore.

Get It Try It

From: Twitter <info@twitter.com>
Date: Sat, 5 May 2018 at 03:50
Subject: An update on your account security

Hi @[XXXXXXX],

When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone.

There is no 'masking' involved, and it wasn't a 'bug'. Twitter lied.

'Masking' implies ability to remove said mask, implies something is covered and that the cover can be removed.

A system whereby you can remove a mask on a password and suddenly make it appear again would be a worthless and very dangerous system.

Already here, at the very beginning, Twitter lied to you.

About The Bug

We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter's system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.

Buzzwords, buzzwords... Industry standard? There are lots of industry standards.

Anyone can 'DDG' bcrypt to find out what it is. Of course we only have Twitter's word that they're actually using bcrypt (and nothing else) but let's roll with that for now.

And here you can learn how bcrypt is designed to thwart so-called 'dictionary attacks'.

https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

What is a 'dictionary attack'?

A 'dictionary attack' is an attack where you throw 'brute force' against an encryption. As you have no way to decipher, you throw the equivalent of an entire dictionary against it.

But there's something implied in there, do you see it?

If something is so strongly encrypted that it needs a 'brute force' 'dictionary attack' to crack it, then it can't be a matter of a simple 'mask' as Twitter told you.

Twitter lied.

The one-time industry standard Data Encryption Standard (DES) was intentionally whittled down from its original specification at the behest of the NSA so their server park at Ft Meade would have a chance of throwing brute force dictionary attacks at it.



... replaces the actual password with a random set of numbers and letters that are stored in Twitter's system.

They're not random and they're not just numbers and letters. This is typical PR gobbledegook.

The message digest, as it's technically called, is very determinative, as encrypting a second time, for example, must always yield the same result. Otherwise - think about it - they'd never know it was you. Otherwise no password validation process would ever function, would it?

And it can't be a mask because... The message digest is always of the same length, no matter the length of your submitted password. And it's always unique. (That's the point of the message digest. And no, finding those algorithms isn't easy.)

This allows our systems to validate your account credentials without revealing your password.

Another cute lie they sneak in. Reveal your password? To whom? To you? You already know your password. Presumably. To them? They're not supposed to know, right? Or are they?

Twitter here again implied that they'd be able to reveal your password if they wanted. That's a lie. That'd be a totally useless system, don't you see?

But here comes the big lie.

Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.

Bugs don't accidentally create new program routines that suddenly generate reams of data that no one notices for years. There was no error.

New code, unjustified and unethical scode, was inserted into the system. There is no reason Twitter or anyone would ever want to know your password. The system depends completely on your password being totally irrelevant.

What happens is this.

You login or set up a new account and in the latter case typically enter your proposed password twice. Your password at your end is not encrypted but commonly masked so you (or someone peeking over your shoulder) can't see it.

Your data is sent securely over the Internet to a Twitter server.

The Twitter code then encrypts (creates a message digest) of your password and either stores it for the first time if you're setting up a new account or compares the encrypted digest to what Twitter already stored on record when you opened your account (or last updated your password).

Password systems have no use for unencrypted passwords. That's the whole idea - that's the industry standard.

How many Twitter accounts are there? 330 million as of Q1 2019, according to WP. That's quite the log file. Count on at least a kilobyte or two for the message digest, then storage for the account name, then additional storage for actual logging info if it's really a log file as Twitter would have had you believe.

That's a whopper of a file that, according to Twitter, went undetected and was only there because of a 'bug'?

Although we have no reason to believe password information ever left Twitter's systems or was misused by anyone...

That's probably the truth, actually. There was no 'bug' magically inserting new code into a system. Source code control systems prevent things like that from happening.

The danger, as perceived by Twitter, was not that they were harvesting passwords, but that someone who wasn't supposed to know actually found out and would 'blow the whistle' on them.

The 'error' was not that Twitter found out that passwords were being harvested. The 'error' was that someone found out, someone who wasn't supposed to know, someone who couldn't be trusted with their dirty little secret.

Trust

Trust is a quirky thing. Trust is needed to initiate all interpersonal communication. To communicate with anyone in any way, we need to begin by assuming we can trust the other party.

That's why breaking that trust is so destructive. Should either party be proven to be untrustworthy, then the bond of trust is broken, then it will take a long time for it to be repaired.

If we trust a company to behave ethically when it comes to our personal data, then that bond of trust can never be broken.

Twitter lied egregiously. There is no justification for what they've done.

This op-ed is prompted by a sad reminder from an old letter from 'Twitter International Company'. The matter was discussed at the time by, amongst others, ourselves and Kim Dotcom.

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.