Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update on our security incident

blog.twitter.com

Post reply on HN
Print view View original

301–308 of 308 posts

Re: An update on our security incident

#301

Post by ethanwillis »

actuator wrote: post #250
SyneRyder wrote: post #97

Earlier quoted context omitted.

In an interview with the hacker by Vice Motherboard, they claimed they had an employee on the inside doing all the work, and they just paid the employee to do it: https://www.vice.com/en_us/article/jgxd3d/twitter-insider-ac...

Like the other commenter, I am also skeptical of this. This has to be a big amount and in some untraceable account otherwise why would a well paid Twitter employee put his career in jeopardy over something like this. You can look at audit trail and pretty much nail the person who did this, and then after that good luck with the criminal charges and making yourself unemployable.

You're assuming that all Twitter employees are paid well.

Re: An update on our security incident

#302

Post by Can_Not »

fmajid wrote: post #188
FlorianRappl wrote: post #36

I remember that answer to "What keeps you up at night?" of a major security advisor to be "Our employees! They click everything!". Fitting video: https://www.youtube.com/watch?v=bLXW2JQ0TZk Training to prevent these social engineering leaks is definitely critical.

Training is not the answer to security problems, as empirically it has no effect. The only measures that work are technological, like U2F keys.

I dunno, this sounds like "you don't need vitamin D if you have enough vitamin C".

Re: An update on our security incident

#303

Post by Can_Not »

javchz wrote: post #33

I will use this as an ugly reminder that it's better to assume that any DMs could be public at any moment. I don't subscribe to the "nothing to fear, if you have nothing to hide", I had conversations that are not illegal, lewd or even non-politically correct jokes, but would still hate to made public by a 3rd entity; from secrets that were shared by friends, to sensitive data like addresses, or information with clien…

Just "DM" is my ugly reminder, we collectively called them PM (private messages) a decade ago.

Re: An update on our security incident

#304

Post by Spivak »

rsanheim wrote: post #289
sabas123 wrote: post #276

Earlier quoted context omitted.

is two hours really that long?

When you have heads of state making insane executive proclamations via your platform, and you know that your weak sauce security is compromised — yes, it’s way too long.

I feel like we’re elevating Twitter to something way more meaningful and official than what it really is as a large scale public community bulletin board.

Like take down the forged messages, fix the hole that let them post them, issue an apology, and compensate the people who had their data stolen. No need to blow this up into something huge.

Re: An update on our security incident

#305

Post by tialaramex »

manjalyc wrote: post #277
fmajid wrote: post #190

Earlier quoted context omitted.

Hashed and salted is insufficient, as GPUs are extremely fast at crunching through hashes. Unless they use a memory-intensive (for GPU/FPGA résistance) algorithm like argon2 or scrypt, I would assume those credentials compromised.

Doesn't matter how fast GPUs are, they only get linearly faster. Passwords are exponential in terms of difficulty so assuming your password isn't password123 no GPU in the world is going to crack a 'decent' password in a decade on any modern algorithm memory-intensive or not.

It is unfortunate that manjalyc has been downvoted here :(

If you use unique strong random passwords like those typically chosen by a password store (e.g. 24 alphanumerics) it doesn't matter what password hash is used, it doesn't even matter whether salt was used, because there's no chance anybody else has the same one.

For example here is simple MD5() of a password I use every day, you have no idea what it is, and even very powerful MD5 "reversing" tools won't help you change that.

f72ffd77701fba433394548eedca5fd0

Good password hashes somewhat protect people who chose bad passwords. They're a mitigation. Your users will choose bad passwords so you need to use a password hash in software you build, but if you never use bad passwords you needn't care whether this or that site used a good hash since it has no impact on your security.

Re: An update on our security incident

#306

Post by alexfromapex »

harshreality wrote: post #67
sidcool wrote: post #4

I wish they mentioned what kind of social engineering attack it was. It could be a case study for any such incidents in the future. P.S. I feel bad for the employees who were manipulated to give away the info.

I want to know how they social engineered an employee at a 2FA-enabled company into bypassing 2FA. Was the employee able to disable 2FA for their own account? Was the employee social engineered into adding someone else's 2FA key to their account? Did the employee read a 2FA code to the attacker, and that somehow enabled all the evil things the attacker did, without any additional checks or 2FA codes? Did the attacker…

They probably got the reps to disclose the phone numbers by saying is this the right phone number? And then they made a SIM card for that number to get the 2FA text

Re: An update on our security incident

#307

Post by _____-___ »

amw-zero wrote: post #204
jacquesm wrote: post #194

To me the really irresponsible bit is that they kept the service up knowing full well there was a live attack in progress and they had not yet found a way to stop it. The Big Red Button has a place and the time to use it was last week. Given the prominence of the accounts that were compromised there isn't a shadow of doubt that shutting it down was the only responsible course of action. The world will continue to spi…

They disabled the account that were identified to be compromised. That isn’t enough?

Eventually. Those accounts were alive and spamming for hours before Twitter was able to effectively stop them.

Re: An update on our security incident

#308

Post by Thorrez »

raverbashing wrote: post #151
Thorrez wrote: post #122

Earlier quoted context omitted.

That's why you need a phishing-resistant method of 2FA. U2F is phishing resistant. Any type of OTP, or anything that doesn't bind the user action to the url bar is susceptible to phishing. U2F has the computer verify the url bar so it's phishing-resistant.

I just find it ironic that the same people pushing for 2FA and arbitrary password rules are now saying "oh I guess 2FA is phishable" The best defense against Phishing seems to be to hire competent people and to train them on that and to establish "No You-Know-Who-You're-Talking-To" policies, as if something gets failed to do by whomever that didn't follow security procedures (example: "CEO" asking for "urgent" favour…

Arbitrary password rules don't make phishing any easier or harder.

For phishing involving malicious websites the answer is not training, it's U2F. For other phishing, yes, training is useful.

Post reply on HN