Twitter: No big deal, but everyone needs to change their password Twitter is ringing in World Password Day by notifying its users, all 330 million of them, that their login credentials were left unencrypted in an internal log file and should be changed. Chief technology officer Parag Agrawal broke the news on Wednesday that its internal team had found that, while passwords are usually stored …
"This string is a password, right, and we have to be really careful with them. We salt and encrypt them and store them in a protected file. Ooh, look, a new iPhone is out. So, to be sure our code is working, we'll log all keystrokes for debugging purposes. Don't forget to... Wow, retina display, 10Mp camera... "
Is it a reasonable assumption? Or are we left to make it in the hope there's no further questions?
The github bug was relatively short-lived but the Twitter bug blog post says nothing about the time-frame and tells everyone to change their passwords (and add an extra phone-pinging to their logging-in, a monetisable opportunity made promotable by this crisis).
Conspiracies aside, until we see confirmation we should not take it as given that it is the same bug just because they happen to use the same function somewhere in the chain that might have no relevance to it.
Indeed, Twitter is apparently upfront about the issue and that is something that must be commended.
The fact that it is an internal gaffe and (allegedly) no data was actually leaked is a Good Thing (TM). The fact that Twitter still came out with the issue, and the possible hit to its reputation, marks a company that is definitely not like many others.
So good on Twitter for doing the Right Thing (TM).
I'm still not getting a Twitter account, though.
This is a good example of the new GDPR guideliness.
They didnt do this out of a misplaced sense of honour, they did it because they are obligated to report any infractions within 72 hours that could lead someone (even in house) to figuring out a persons identity.
Take the facebook employee recently sacked off for e-stalking women, he'd get access to their data then track them down through Tinder and other means.
Logging in to twitter gives location information, pictures, biographical info.
And note what else they have told us in the reassurances!
e.g. no indications of anyone outside the company being able to even view the file tells us nothing:
- as there was no indication of the logfile accidentally saving all these passwords completely by accident in the first place
- it could have been accessed by anyone inside the company any number of times
- how do they know, was access to the newly-discovered unknown file being logged somewhere?
Occasionally I get the urge to comment on articles that use twitter for the purpose, and try to create a new account. but I always get the:~ "There is a problem with your account" banner and when I try to verify my account they demand my mobile phone number.
Don't need two factor there.
Some little social tool like Twitter is not important enough for that piece of information.
so account creation fails.
So does Facebook. It let's you to create a new account without a phone number. But it forces you to add a phone number to login in on the second day. It basically holds your profile in hostage until you add your phone number. You can't continue without giving away your number.
A very shady UI pattern that should be regulated by the US, UK and EU laws maker.
Though old accounts are differently handled, a 2006 account just shows a nag screen that has to be clicked away every fucking time.
This is exactly the kind of foul up that can be found in code reviews. How about a simple source code search for the uses of variables with 'password' in the name? Uses in lines of code that also have the word 'log' in them ought to be worrisome.
Typical of today's coding ethos; write crap code, get away with it coz everyone else is writing crap code too. It's cheaper to apologise later than to do the job properly.
This is honestly ridiculous, this is one of the easiest things to do properly. It's a shame the public has such a low level of knowledge of basic programming techniques, because if they knew anything about this they're realize that this is like handing their personal information over to the Bozo the Clown of the web.
This is the sort of mistake that would cause a first year comp-sci student to fail an assignment, not the sort of thing you expect to see in a multi-million dollar corporation's flagship product.
I used to rail against the stupidity of this kind of statement. Over the years I have literally collected hundreds of registrations to different websites, services, etc. How can anyone sanely expect everyone in the world to be able to REMEMBER that many unique passwords?
But recently, I realized just how easy it actually is! The trick is not to generate that many fully unique passwords. Generate one part that you remember, and one unique part provided by the service. For example:
Twitter5ucks!
Github5ucks!
Facebook5ucks!
Apple5ucks!
Google5ucks!
With this simple technique you can have a safe (assuming they stored your password correctly) and unique password for every single one of your hundreds of accounts.
My only problem was at El Reg, where I had to actually invent a new password, because they don't suck. One out of hundreds. Not so bad.
I’d always naively thought that passwords are hashed at moment of creation, leaving no opportunity for them to be stored on a website or database unhashed. I thought that hashing & salting was a one-way process and the result is only usable for matching. Where was my naive assumption wrong?
Or: Due to a coding bug, a logfile was being written in plaintext of all passwords being created. And this logfile had been left running for years and years, long enough to acquire millions of plaintext passwords? Colour me skeptical.
The hashing runs on the server. You have to pass the password to the server for hashing. The alternative is to trust all the external devices to hash for you. You can't trust all the external devices.
That's about the size of it, afaik.
@nifty when a user logs in, their plain text password is symmetrically encrypted in transit (i.e. using HTTPS), then at the other end it is decrypted and then hashed to compare against the password database. any logging that takes place during this window after decryption and before hashing would have access to the plain text password.
the password is transmitted to the server and encrypted on that side. Which means there is the possibility of it being logged by lots of things, before the active code on the webserver passes it to the hash function:
TCP log anywhere in chain (sure, the front end is https, is that a proxy or load balancer you've got there?)
HTTPS library (writing code is hard, look there is a easy two liner I can use, just need this extra thing off GitDump)
etc etc
only once that information has passed through an obstacle course does the code get to say:
hash (salt, pass)
So forget on creation, we don't even need to worry about databases at this stage of the process.
Edit: I see I'm late to the knowledge transfer party, but I'll just add: it's not even trusting all external devices, as what they submit would just be another password so you can repeat ad infinitum without improving your situation.
Why the fuck could you "not trust" any device to "hash for you"...? Which device able to render your web 2.0 site cannot be expected to be able to do a stupid hash? What perverted things could they do to that hash that they cannot possibly do to the plaintext you are apparently more than willing to accept from them instead? And what the hell would it matter by what means you obtained a client-side hash when all you need it for is just to compare it your copy on the server anyway? Bullshit.
Client side hashing isn't secure because the client can be modified. Let's say an attacker has a log containing client side hashed passwords; In order to login he just has to modify the client to remove the hashing function and pass a hash straight through, with no need to know the plaintext password that would generate said hash.
All you are doing when you hash on the client side is transforming the password from one set of characters in to another. Sure, the attacker can't recover the plaintext from it, but the plaintext is only useful in generating the client side hash, which he already has. As far as the server is concerned, the string it receives is the password, whether it has been hashed on the client or not.
A “bug” my arse!
Anyone else here read about the early days of Twitter? Ashton Kutcher and Demi Moore would break it every time they tweeted each other. So Twitter had to have a dedicated laptop looping a script, just to keep up with those two accounts.
Then you see how Twitter allows any depravity if it’s from the left, while censoring conservatives.
Twitter is a confidence trick, just like Netflix.
Twitter plays politics. Take your head out of the sand.
The left can threaten violence and death without consequence.
Meanwhile, anyone on the other side gets suspended for breathing too loud.
My main point was that Twitter is a confidence trick. And the one-sided politics they play is a big part of that trick, because you probably still believe it's a "Free Speech Platform". It isn't.
Ages ago to chat to someone, but deleted it when they would not stop spamming.
Turned off all spamming then got a sponsored spam one from someone supposedly well known I do not give a shit about so deleted the account.
I only followed a couple of game devs and have no interest in Z level "celebrities".
Agrawal says that using bcrypt hashes means that "This allows our systems to validate your account credentials without revealing your password". It goes further than that of course: it allows your credentials to be validated without the system knowing what your password is at all, by storing only the hashes. If someone hacked the system and stole the password database they still would not know your password (although they could then run multiple attacks at their leisure, so we don't want people just exposing password databases willy-nilly). So that is why logging the plaintext password is such an enormous error: it undermines one of the main security advantages of the (industry-standard) crypt / hash approach to password management. And that really implies that the coder(s) who logged the plaintext - even temporarily! - did not understand the system they are working on, which must be a concern.
But there's is another whole class of poor password management out there. When I log into my bank's online banking I am asked to supply 3 (randomly selected) characters from my password, not the whole password. This probably looks even more secure to naive users, but clearly the bank is not hashing the password and is storing it in plaintext (or at least in a reversibly encrypted, and hence vulnerable, form). So that looks suspiciously like some 'smart' people looking at the industry-standard approach and going 'nah, we know better' - but completely missing the point. And they are not alone.
Yes, I am changing to another bank!
clearly the bank is not hashing the password and is storing it in plaintext (or at least in a reversibly encrypted, and hence vulnerable, form).
Would that not depend upon the hashing function?
Whilst far from as secure as it should be, each individual character could be hashed and the final password hash created by concatenating them, thus allowing individual character comparison without needing to know the plaintext.
Yes, that particular approach would be ludicrously insecure but it was by way of outlining a general principle rather than a specific approach. In reality, I'd expect that final hash to hashed itself and for the hash of all three inputs to be one of a set of keys that open the final hash, enabling the comparison of each individual hash, for instance; again a rough and ready outline of an approach, not a real method, but you get my drift - the point being that it needn't be the case (even if it probably is) that it's stored in plaintext/reversibly encrypted for the method to work, just not as secure as it really should be.
How many companies are using Twitter for the entry to their own systems? The knock-on affect will be big.
What about the others using Facebook (or facefarce), or google, etc. if, more likely when, they are compromised the ripple will grow to a tsunami.
Why does this sound like twitter this time finally will get things right for their 3rd party investors ? I have never had any troubles with twitter and passwords. There have never been such problems reported at twitter. So how far off does it sound that the claim "On Thursday, Twitter revealed that a bug caused the platform to store user passwords in unmasked form." is only meant for prominent people on Twitter, like Donald Trump, who are getting setup by this "engineering trouble" ?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
