4 ms·

> You can't rely on people not falling for phishing 100% of the time 1. I genuinely don't understand why. 2. If it is true that people are the failing factor,

> You can't rely on people not falling for phishing 100% of the time 1. I genuinely don't understand why. 2. If it is true that people are the failing factor, then nothing is going to help. Hardware keys? No problem, a human will use the hardware key to sign a malicious action.

MitPitt 1y ago
Removing humans will help
- egorfine 1y ago
  I sense a startup opportunity here
elric 1y ago
> 1. I genuinely don't understand why. It's a war of attrition. You can keep bombarding developers with new and clever ways of trying to obtain their credentials or get them to click on some link while signed in. It only has to succeed once. No one is 100% vigilant all the time. If you think you're the exception, you're probably deluding yourself. There's something broken in a system where one moment of inattention by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken.
- egorfine 1y ago
  Then see #2: there is no way to prevent humans from actually performing detrimental actions, hardware keys or not.
  - vel0city 1y ago
    This specific attack (and many others like it) would have absoultey been foiled by U2F or passkeys. These authors would have been incapable of giving the adversary any useful credential to impersonate them by the very nature of how these systems work.
    - egorfine 1y ago
      Fair.
- kentm 1y ago
  > where one moment of inattention by one person I'll get a lot of pushback for this, but the main problem are ecosystems that encourage using packages published by one person. I call these "some person with a github" packages, and I typically go through codebases to try to remove these dependencies specifically because of this threat vector. Packages that are developed by a team with code multiple code reviewers and a process are still at risk, don't get me wrong. But the risk is much less if one person does not have the power to unilaterally merge a PR, and more-so if its backed by an organization that has multiple active devs and processes for reviews. If you do need to depend on these one-person packages, I'd recommend forking and carefully merging in changes, or pinning versions and manually reviewing all commits before upgrading versions. Thats probably intractable for a lot of projects, but thats honestly something that we as developers need to fix by raising the bar for what dependencies we include.
tgv 1y ago
> 1. I genuinely don't understand why. You never make a mistake? Never ever? It's a question of numbers. If the likelihood of making a mistake is 1 in 10000 emails, send out links to 10.000 package maintainers, and you've got a 63% chance of someone making that mistake.
- chrisweekly 1y ago
  Your point is completely valid. Tangent: in your example, what calculation led to "63%"?
  - theanonymousone 1y ago
    1-(.9999)^10000 I trust the user did this calculation. I didn't.
    - tgv 1y ago
      That's indeed the formula. The .9999 is (1 - 1/10000), 1/10000 being the likelihood. It would perhaps have been clearer if I had chosen two different numbers...
- egorfine 1y ago
  Then hardware 2FA won't help.
  - tuckerman 1y ago
    Hardware 2FA, with something like passkeys (or even passkeys with software tokens), _would_ prevent this as they are unique to the domain by construction so cannot be accidentally phished (unlike TOTP 2FA).
  - smw 1y ago
    This seems to be a common misunderstanding. The major difference between passkeys and hardware 2fa (FIDO2/yubikeys) and TOTP/SMS/Email solutions is that the passkey/yubikey _also_ securely validates the site it's communicating with before sending validation, making traditional phishing attacks all but impossible.
InsideOutSanta 1y ago
> If it is true that people are the failing factor, then nothing is going to help Nothing will reduce incidents to 0, but many things can move us closer to 0.

MitPitt 1y ago

Removing humans will help

egorfine 1y ago
I sense a startup opportunity here

elric 1y ago

> 1. I genuinely don't understand why. It's a war of attrition. You can keep bombarding developers with new and clever ways of trying to obtain their credentials or get them to click on some link while signed in. It only has to succeed once. No one is 100% vigilant all the time. If you think you're the exception, you're probably deluding yourself. There's something broken in a system where one moment of inattention by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken.

egorfine 1y ago
Then see #2: there is no way to prevent humans from actually performing detrimental actions, hardware keys or not.
- vel0city 1y ago
  This specific attack (and many others like it) would have absoultey been foiled by U2F or passkeys. These authors would have been incapable of giving the adversary any useful credential to impersonate them by the very nature of how these systems work.
  - egorfine 1y ago
    Fair.
kentm 1y ago
> where one moment of inattention by one person I'll get a lot of pushback for this, but the main problem are ecosystems that encourage using packages published by one person. I call these "some person with a github" packages, and I typically go through codebases to try to remove these dependencies specifically because of this threat vector. Packages that are developed by a team with code multiple code reviewers and a process are still at risk, don't get me wrong. But the risk is much less if one person does not have the power to unilaterally merge a PR, and more-so if its backed by an organization that has multiple active devs and processes for reviews. If you do need to depend on these one-person packages, I'd recommend forking and carefully merging in changes, or pinning versions and manually reviewing all commits before upgrading versions. Thats probably intractable for a lot of projects, but thats honestly something that we as developers need to fix by raising the bar for what dependencies we include.

tgv 1y ago

> 1. I genuinely don't understand why. You never make a mistake? Never ever? It's a question of numbers. If the likelihood of making a mistake is 1 in 10000 emails, send out links to 10.000 package maintainers, and you've got a 63% chance of someone making that mistake.

chrisweekly 1y ago
Your point is completely valid. Tangent: in your example, what calculation led to "63%"?
- theanonymousone 1y ago
  1-(.9999)^10000 I trust the user did this calculation. I didn't.
  - tgv 1y ago
    That's indeed the formula. The .9999 is (1 - 1/10000), 1/10000 being the likelihood. It would perhaps have been clearer if I had chosen two different numbers...
egorfine 1y ago
Then hardware 2FA won't help.
- tuckerman 1y ago
  Hardware 2FA, with something like passkeys (or even passkeys with software tokens), _would_ prevent this as they are unique to the domain by construction so cannot be accidentally phished (unlike TOTP 2FA).
- smw 1y ago
  This seems to be a common misunderstanding. The major difference between passkeys and hardware 2fa (FIDO2/yubikeys) and TOTP/SMS/Email solutions is that the passkey/yubikey _also_ securely validates the site it's communicating with before sending validation, making traditional phishing attacks all but impossible.

InsideOutSanta 1y ago

> If it is true that people are the failing factor, then nothing is going to help Nothing will reduce incidents to 0, but many things can move us closer to 0.