Hacker News Reader

Comment by iamleppert | Hacker News Reader

They should require hardware security devices (dongles). Really Twitter should be ashamed of their poor internal security.

View on HN

It depends on the attack.

For example if a Twitter user was logged in with a dongle but the attacker had access via social engeneered remote desktop access a dongle still could mean access to private data.

But yes. As far as I know Google and Facebook require them. Also Google sometimes require permission of an other co-worker to access data.

>if a Twitter user was logged in with a dongle but the attacker had access via social engeneered remote desktop access a dongle still could mean access to private data

It depends on the dongle. YubiKeys and similar devices require the user to physically touch/tap it to enable U2F auth, and it automatically powers down after a timeout to prevent remote desktop attacks.

I would hope Twitter already had this kind of setup, but their blog posts about this are all targeted at a more general audience, so I doubt we'll get that kind of detail anytime soon.

>It depends on the dongle. YubiKeys and similar devices require the user to physically touch/tap it to enable U2F auth, and it automatically powers down after a timeout to prevent remote desktop attacks.

How often is the tap needed? Is it needed on every action or 1/day or 1/month? It would stay valid via browser cookies valid for that period. If it's 1/day the employee might have tapped it in the morning, then went to lunch, then the attackers hit with the remote desktop attack.

Every time you login with a Yubikey you must tap it. It does not maintain its own session on the key or anything like that.

If the app maintains a session, then that depends on how long the app allows sessions/tokens to live for at that point. The Yubikey won't come into play until login is required again. So, I think you're getting at a different part of the security model at that point.

My point is that essentially all apps maintain a session and a remote desktop attack can make use of that session. So Yubikey doesn't really protect from remote desktop attacks.

Fair enough! I didn't comprehend the context well enough. Seems right though, the Yubikey won't protect sessions. At least I don't see any reason it would.

Note that not all hardware security devices are safe. U2F security devices are safe against phishing; OTP security devices are not safe against phishing.

what about a phishing attack that involves the attacker talking the target through a login, which also involves the u2f part? and then obtaining the session token from memory/disk instead of username/password

How would the attacker get something from memory or disk? Malware? If there's malware involved I don't consider that credential phishing. It's a matter of debate whether malware can be considered a form of phishing. Maybe I should be been more clear that U2F stops credential phishing, not malware phishing (if that even exists).

I guess one option would be to ask the victim to read out the token from memory or disk. That seems pretty hard though. It's debatable whether that would be considered credential phishing.

A more likely method would be to trick someone into going into devtools and copy and pasting something from there, possibly a curl command, like in this epic "bug report"[1]. That's also debatable whether it would be credential phishing.

[1] https://hackerone.com/reports/745324

U2F are safe against simple phishing, but sophisticated attacks can include 2-factor input.

U2F protects against that because the signature is tied to the hostname. The browser reads the hostname. The browser is infallible when it reads the hostname, unlike a human.

In most scenarios a FIDO authenticator (for U2F/ WebAuthn) won't even sign your login attempt for the wrong site at all, because of how it works. We'll look at the original FIDO (second factor only) scenario because that's cheapest and apparently Twitter was very budget conscious on security?

This FIDO authenticator has absolutely no idea what your per-site keys are. Instead, the random-looking ID provided to the site when you register and then given back by the site when logging back in actually is your private key for that site... encrypted using AEAD with symmetric keys only the FIDO authenticator knows.

One of the ingredients for decrypting the key is rpIdHash which is SHA256(dnsName) where dnsName is the FQDN of the site you're looking at or some suffix of that FQDN chosen by the site. So here it could be news.ycombinator.com or ycombinator.com (Public Suffixes like com or co.uk are prohibited). The browser is responsible for calculating rpIdHash.

Thus on a phishing attempt usually the AEAD fails, the authenticator not only doesn't give the phishing site a signature that can be used to sign in on a different site, it will ignore this ID and act as though the user doesn't have a FIDO authenticator plugged in at all.

Oops, I didn’t realise U2F was different to 2FA.

I guess you would need to ring someone up pretending to be tech support and convince them to disclose the private key.

The private key is embedded in the hardware key, there's no way to extract it without an advanced attack involving tearing apart the key.

But a practical attack along the lines of what you mentioned would be to ring someone up and convince them to disclose their cookie. Check out[1] in which the victim disclosed their cookie without the attacker even asking for it.

[1] https://hackerone.com/reports/745324

Dongles are rare here in the US. But I know that bloomberg uses them. I was shocked when I learned that retail banks in Singapore give everyone dongles to log in. In the US that's tyranny Lol

I work for a crypto currency company and it was the first time in my career that I was issued a YubiKey (I once had an RSA 2fa token for vpn access). It took some getting used to but now I just keep in on my keychain and I always have it with me. I need it for SSO, git, VPN, and basically all internal services.

They aren't sufficient by themselves however, they don't protect from is malicious internal employees.

Preparing for malicious internal employees seems to me like preparing for "the big one," in the northwest.

Do a cursory amount of preparation. Outside of basic measures, you're probably doing more harm to the business than good. The likelihood of internal malicious attackers is very low in the grand scheme of things, and the attack surface is huge.

Most companies are going to be compromised by outside attackers—its there that you should focus your energy. If internal attackers are your biggest threat, you've done a fantastic job.

Well Twitter did indeed have malicious internal employees.

https://www.washingtonpost.com/national-security/former-twit...

If you're hit by a paywall:

https://web.archive.org/web/20200717083254/https://www.washi...

The annual DBIR, which collects incident reports, has ~1/3rd marked as insider ;-)

From a defense-in-depth perspective, agreed: most attacks involve privelege escalation on the inside as soon as they switch from attack vector to breach, even if just host-level, so teams should absolutely "assume breach". Attackers will phish folks, get on their devices, get root, and then have fun there and potentially elsewhere. Ransomware is a more common goal than what Twitter got hit with as it is easily profitable, and it means a takeover. Controls on what most users can do and the ability to scope & report is part of growing up (in the US). It's good Twitter was able to map the attack - I bet many popular social networks couldn't, esp outside of the US or non-top-10.

Shameless plug: A lot of folks use our tool for mapping network logs, and I always encourage to also map out host / app / cloud logs as well, such as logins and the oftentimes black hole that is winlogs.

We're talking about companies, not users. Competent companies can and absolutely do require dongles (or equivalently trustable corporate hardware) to log in to their systems.

And as a Norwegian it boggles my mind that banks in the US only require username and password to access their bank. We have moved on to a authenticator living on a phone sim card, and you use either that or a "real" hardware dongle for all logins and (most) transactions to confirm your identity.

US banks do commonly use SMS messages as a second factor, for what it's worth.

> SMS messages as a second factor, for what it's worth

Almost nothing :(

rare? I worked at Facebook and every employee needs one.

Rare for employees or rare for consumers? Companies can push much higher security onto employees than onto consumers.

How do they deal with lost dongles?

Same as other computer equipment, get another one from tech support and revoke the old one. Or at least, that's how it worked when people still went to the office.

Employees can revoke access for any of their keys/dongles once they realize they are missing. The company can also send an automated warning and auto-expire a key that's not been used for a while.

When I worked at MSFT in 2006, remote access required a smart card plus credentials.

Reply on news.ycombinator.com