10 ms·

>Citrix said in a later update on April 4 that the attack was likely a result of password spraying, which attackers use to breach accounts by brute-forcing from

• Godel_unicode 7y ago
  I was with you up until the last paragraph, but no. That's not 2fa, that's switching one factor for another. People should use a password manager with an rng to generate and store passwords. IT departments should run password spraying attacks themselves as well as blacklisting known-compromised passwords. There's really good tooling for this (likely the same tooling this adversary used!) Separately from this, people should use hardware 2fa tokens whose weakest link isn't the cell phone company support. Edited for clarity.
  • inapis 7y ago
    Probably my wording was wrong. I was thinking more of a system where the password itself was generated and stored on a hardware device. The user need not interact with any application, whatsoever, like 1Password or Lastpass to generate or store a password at all. Everything happens behind the scenes on the device. The user would be responsible only for keeping the hardware device safe. This probably makes 2FA moot for some scenerios. For scenarios where losing the token is a real risk, you would implement 2FA.
    • Godel_unicode 7y ago
      I understood you, my point is that you are sacrificing significant security with a one-factor approach, especially if that one factor is a password! You're open to attacks where the password is exposed in between the keyboard and the requestor, attacks on the distant end system, as well as attacks on the password device itself. Passwords make it tricky to audit if they've been duplicated. Use 2fa everywhere. It's cheap, easy, and significantly more effective. Consider the following attacks which your suggestion provides no coverage for: - Http downgrade (both SSLstrip and export-grade downgrade) - Spear-phish - Key-logger - Spear-phish - Shoulder-surf - Spear-phish - Evil maid (borrows device and compromises passwords) And last but not least, spear-phish
      • inapis 7y ago
        I do not believe that spearphishing would not be prevented by a hardware token. The device would be responsible for authenticating the identity of the service being accessed. If the user can be fooled into handing over their hardware token, I do not see it far fetched that they will not be influenced to not hand over their 2FA token. Again, if a hardware 2FA token can deal with key-loggers, so can a password token. Why would someone be able to shoulder-surf a display-less password token? You log on to the website, insert the device and the website proceeds to authentication without revealing anything. Evil maid is the only legitimate attack I can agree with. >attacks on the distant end system, as well as attacks on the password device itself. This is not something that a hardware 2FA token is also foolproof against. >Passwords make it tricky to audit if they've been duplicated. This is a valid point. My point may not be applicable for super sensitive systems but for a lot of services it should be sufficient enough. I'm saying so because I'm having a hard time getting my family/friends to use a password manager (specifically 1Password). They do not see the need, find it additionally complex and are turned off by the subscription pricing (I'm paying for my family though!). Syncing is also hard. I was hoping that a pure hardware token would make it more convenient and a one time 20-40 USD price is more palatable than 60 USD every year.
        • deleted 7y ago
          [deleted]
        • Godel_unicode 7y ago
          You're almost there, keep going a little farther, and you'll have eliminated passwords and invented FIDO. https://fidoalliance.org https://fidoalliance.org
          • inapis 7y ago
            Ha. Perfect. That is exactly what I was imagining. Apologies for the long conversation. Do you have any idea why this is not popular? Is it too hard to implement or is it just that business's do not see security as something to invest a lot in?
  • u801e 7y ago
    > People should use a password manager with an rng to generate and store passwords. [...] > Separately from this, people should use hardware 2fa tokens whose weakest link isn't the cell phone company support. What would be better is to support certificate based authentication in combination with a username and password. Then you have 2FA without having to share the private key. You can even get 3FA if the private key requires a passphrase to decrypt it. Using SMS or email based 2FA is not secure (or is only as secure as the email or cell phone account as you already pointed out). Using TOTP requires sharing a secret between the device and the server.
    • IncRnd 7y ago
      A passphrase doesn't make it 3FA, since that is an already used factor class, what you know. 3FA is one from each category of what you know, what you have, and what you are. Depending on the implementation, what you describe may only be 1.5 factor auth.
      • u801e 7y ago
        I believe we can agree that just using a username/password for authentication is 1FA (single factor authentication). If we add a one-time token sent via SMS or email, or generated via TOTP, that's generally considered 2FA (with the username/password considered what you know and the one time token being what you have, I believe). What I proposed was using a client-side TLS certificate in combination with the username/password for authentication. If the private key corresponding to that certificate requires a passphrase to decrypt, then it should be more than 2FA. What you know is the username/password, what you have is the private key. Whether the passphrase for that private key is considered what you know vs what you are is debatable (since, unlike the username/password or one-time token, the secret isn't shared by transmitting it over the network).
        • Godel_unicode 7y ago
          As I have said other places in this thread, you're slowly reinventing Fido/u2f/(as was expanded by others)WebAuthn.