Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sigh. Same happened to me. A few months ago. Sendgrid account hacked, someone set up a campaign and sent a huge amount of spam mail. Big bill on my credit card. Contacted Sendgrid, they blamed it on me. I cancelled my account, never going back. Screw them


The same thing happened to my previous employer a few months ago.

Our SRE had used a very long novel password and access was very limited, but 2FA wasn't enabled because it lacked some features (I'm guessing it was the SMTP, as other poster mentioned).

We were able to catch it pretty fast and never asked for refunds or anything, but Sendgrid's support was very standoffish and combative when we asked for help with our "investigation" of how the account was compromised, to the point the company started seeking a competitor.


Don't forget to charge back.


Was it not your fault?


Right!? He should have known better than to go out by himself, late at night, dressed like that! /s


Not sure the analogy is fair. There is an onus on users to have some sensibilities in security such as password quality / non-reuse.


Is that sarcasm?


Users are at least partially responsible if they use a non unique password and then get hacked.


However, passwords are a shared secret, so you actually don't necessarily know who was responsible for the secret leaking, you or the other party.

Most proposed replacements or supplements are no better except (you can guess I'm about to say) WebAuthn. WebAuthn is built out of public key signatures, so a Relying Party has no idea how to present valid credentials even for their own system. Obviously you could just add a back door if you want one, but the WebAuthn credentials you're storing aren't like a password, or a password hash, or a TOTP seed. They're just an opaque ID and a public key.


Thats very true. But i think if sendgrid leaked their password db the level of spam would be mich higher.

Of course its always possible the password db leaked but it was using argon2 or something so only really weak passwords could be decoded.

I agree webauthn is great, and its the only option (other than TLS client certs which is a usability disaster, and maybe push notice 2fa depending on how its implemented) that protect against server side breach. However the vast majority of issues are password reuse, and to a much lesser extent dictionary attacks. TOTP effectively stops those. Then again so would choosing the users passwords for them.


All the "Push notice" 2FA systems I've used or looked at are already cheerfully bypassed by systems for phishing TOTP and SMS 2FA.

That's because they're relying on a human to make a security decision and humans are terrible at this job.

The human is at fake-site.example which they think is the real site because humans are lazy and incompetent. The fake site's backend automatically calls the real site, and the real site sends the human a push notice as 2FA. "Are you signing into Real Site®?". "Actually I wasn't sure until I got this reassuring message" thinks the human, "Yes". And now the bad guys have access to their account.

There are a lot of HN stories which are dubious about AI because they suspect it can't ever match a human in terms of vague things like intuition and learning. But you know what computers are unmistakably good at? Trivial symbol matching. fake-site.example is not real-site.example, those strings are different. That's why you just can't use your real-site.example WebAuthn credentials on fake-site.example




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: