3 ms·

- They could have used HIBP to prevent people using exposed passwords - They could have detected elevated authorizations - They could have forced 2FA - They

- They could have used HIBP to prevent people using exposed passwords - They could have detected elevated authorizations - They could have forced 2FA - They could have implemented password stuffing protection Any security assessment would have pointed that out. In fact, when I had my own site pentested the very first time, this was exactly what was pointed out and I promptly fixed it. But it's all moot, since the attacker used a feature of 23andme to access data on other people whose account info they did not have. And that is squarely on 23andme.

Aachen 3y ago
- The password may not be exposed at the time it is registered - That doesn't work, see my sibling comment where I did the math on what authentication rate you'd need to trigger at https://news.ycombinator.com/item?id=39116531 https://news.ycombinator.com/item?id=39116531 - 2FA sounds like a good suggestion, but is bad for business so they'll never do it voluntarily (maybe now that they need to save their reputation) - Isn't that the three above points combined? Or what does "credential stuffing protection" amount to? --- > Any security assessment would have pointed that out. I don't think you're familiar with security assessments That's what I do for a living and we'd have recommended only the first one because it's a simple thing you can implement on the server. About 1 in 10 customers actually follows through on that hardening advice to some extent (e.g. by downloading a top 10k passwords list or adding zxcvbn), even fewer use a huge database like HIBP even though we recommend that. We don't recommend 2FA for all users (only for administrative accounts) because clients never implement it. Adding suggestions that are seen as unrealistically paranoid makes the rest not being taken seriously anymore We also don't buy a botnet and simulate credential stuffing attacks. Maybe we should, but then we'd need the customer to deploy not one staging system with two test accounts per permission level but thousands of accounts, and some way to simulate having thousands of residential IP addresses. These things are not standard procedure and I haven't heard of any other pentest company requesting such a test setup (based on working together with other companies on one scope, chats at conferences, or looking at public pentest reports to see their setup or if they ever reported this finding)
- Sander_Marechal 3y ago
  > - Isn't that the three above points combined? Or what does "credential stuffing protection" amount to? In our case, we track authentication attempts by IP, even successful authentications. If too many authentications come from the same IP in a short time, even over multiple accounts, we start throttling them first, then denying them. I'm in the B2B SaaS space. We know our customers, our typical load, and we have carved out exceptions for certain large clients with known IPs.
  - Aachen 3y ago
    Thanks, that's actually valuable to hear from someone who actually implements this!

Aachen 3y ago

- The password may not be exposed at the time it is registered - That doesn't work, see my sibling comment where I did the math on what authentication rate you'd need to trigger at https://news.ycombinator.com/item?id=39116531 https://news.ycombinator.com/item?id=39116531 - 2FA sounds like a good suggestion, but is bad for business so they'll never do it voluntarily (maybe now that they need to save their reputation) - Isn't that the three above points combined? Or what does "credential stuffing protection" amount to? --- > Any security assessment would have pointed that out. I don't think you're familiar with security assessments That's what I do for a living and we'd have recommended only the first one because it's a simple thing you can implement on the server. About 1 in 10 customers actually follows through on that hardening advice to some extent (e.g. by downloading a top 10k passwords list or adding zxcvbn), even fewer use a huge database like HIBP even though we recommend that. We don't recommend 2FA for all users (only for administrative accounts) because clients never implement it. Adding suggestions that are seen as unrealistically paranoid makes the rest not being taken seriously anymore We also don't buy a botnet and simulate credential stuffing attacks. Maybe we should, but then we'd need the customer to deploy not one staging system with two test accounts per permission level but thousands of accounts, and some way to simulate having thousands of residential IP addresses. These things are not standard procedure and I haven't heard of any other pentest company requesting such a test setup (based on working together with other companies on one scope, chats at conferences, or looking at public pentest reports to see their setup or if they ever reported this finding)

Sander_Marechal 3y ago
> - Isn't that the three above points combined? Or what does "credential stuffing protection" amount to? In our case, we track authentication attempts by IP, even successful authentications. If too many authentications come from the same IP in a short time, even over multiple accounts, we start throttling them first, then denying them. I'm in the B2B SaaS space. We know our customers, our typical load, and we have carved out exceptions for certain large clients with known IPs.
- Aachen 3y ago
  Thanks, that's actually valuable to hear from someone who actually implements this!