7 ms·

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

sushshshsh 6y ago
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
- Thorrez 6y ago
  Rare for employees or rare for consumers? Companies can push much higher security onto employees than onto consumers.
  - PopeDotNinja 6y ago
    How do they deal with lost dongles?
    - marcianx 6y ago
      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.
    - skybrian 6y ago
      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.
- TwoBit 6y ago
  rare? I worked at Facebook and every employee needs one.
- marcan_42 6y ago
  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.
  - Ueland 6y ago
    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.
    - skybrian 6y ago
      US banks do commonly use SMS messages as a second factor, for what it's worth.
      - owenmarshall 6y ago
        > SMS messages as a second factor, for what it's worth Almost nothing :(
- Osiris 6y ago
  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.
  - MAGZine 6y ago
    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.
    - Thorrez 6y ago
      Well Twitter did indeed have malicious internal employees. https://www.washingtonpost.com/national-security/former-twitter-employees-charged-with-spying-for-saudi-arabia-by-digging-into-the-accounts-of-kingdom-critics/2019/11/06/2e9593da-00a0-11ea-8bab-0fc209e065a8_story.html https://www.washingtonpost.com/national-security/former-twit... If you're hit by a paywall: https://web.archive.org/web/20200717083254/https://www.washingtonpost.com/national-security/former-twitter-employees-charged-with-spying-for-saudi-arabia-by-digging-into-the-accounts-of-kingdom-critics/2019/11/06/2e9593da-00a0-11ea-8bab-0fc209e065a8_story.html https://web.archive.org/web/20200717083254/https://www.washi...
    - lmeyerov 6y ago
      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.
- FireBeyond 6y ago
  When I worked at MSFT in 2006, remote access required a smart card plus credentials.
Thorrez 6y ago
Note that not all hardware security devices are safe. U2F security devices are safe against phishing; OTP security devices are not safe against phishing.
- Closi 6y ago
  U2F are safe against simple phishing, but sophisticated attacks can include 2-factor input.
  - Thorrez 6y ago
    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.
    - tialaramex 6y ago
      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.
    - Closi 6y ago
      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.
thdrdt 6y ago
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.
- ngomez 6y ago
  >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.
  - Thorrez 6y ago
    >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.
    - pseudoramble 6y ago
      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.

sushshshsh 6y ago

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

Thorrez 6y ago
Rare for employees or rare for consumers? Companies can push much higher security onto employees than onto consumers.
- PopeDotNinja 6y ago
  How do they deal with lost dongles?
  - marcianx 6y ago
    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.
  - skybrian 6y ago
    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.
TwoBit 6y ago
rare? I worked at Facebook and every employee needs one.
marcan_42 6y ago
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.
- Ueland 6y ago
  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.
  - skybrian 6y ago
    US banks do commonly use SMS messages as a second factor, for what it's worth.
    - owenmarshall 6y ago
      > SMS messages as a second factor, for what it's worth Almost nothing :(
Osiris 6y ago
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.
- MAGZine 6y ago
  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.
  - Thorrez 6y ago
    Well Twitter did indeed have malicious internal employees. https://www.washingtonpost.com/national-security/former-twitter-employees-charged-with-spying-for-saudi-arabia-by-digging-into-the-accounts-of-kingdom-critics/2019/11/06/2e9593da-00a0-11ea-8bab-0fc209e065a8_story.html https://www.washingtonpost.com/national-security/former-twit... If you're hit by a paywall: https://web.archive.org/web/20200717083254/https://www.washingtonpost.com/national-security/former-twitter-employees-charged-with-spying-for-saudi-arabia-by-digging-into-the-accounts-of-kingdom-critics/2019/11/06/2e9593da-00a0-11ea-8bab-0fc209e065a8_story.html https://web.archive.org/web/20200717083254/https://www.washi...
  - lmeyerov 6y ago
    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.
FireBeyond 6y ago
When I worked at MSFT in 2006, remote access required a smart card plus credentials.

Thorrez 6y ago

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

Closi 6y ago
U2F are safe against simple phishing, but sophisticated attacks can include 2-factor input.
- Thorrez 6y ago
  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.
  - tialaramex 6y ago
    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.
  - Closi 6y ago
    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.

thdrdt 6y ago

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.

ngomez 6y ago
>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.
- Thorrez 6y ago
  >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.
  - pseudoramble 6y ago
    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.