91–97 of 97 posts
BCC every message is evil, as it can be misused as in this case. SendGrid should never allow that, or at least should flag such behavior. At the minimum, they should notified account owners of this change.
My first thought was to whois chunkhost.info, which returns a clear name, email address and phone number. Or is it that easy to register a domain with a fictitious persona?
Virtually every registrar allows instant update of whois records via a web interface. I can have Bill Gates be the technical contact on my personal domain in about a minute.
We use Sendgrid and have hundreds of thousands of customers that might be phished by this social engineering trick. It's absolutely unacceptable that such a crucial piece of infrastructure is vulnerable to such a simple trick. I'm going to bring this up with our team and see if there's another vendor that can more reliably protect our customers.
Your logic is a bit weird. Sendgrid just experienced this major embarrassment and are currently re-training their staff to avoid it again at all costs. And you're going to move away from them now ?
I mean, keep in mind that this is the same company that publicly crucified a female employee in order to stop a DDoS attack. Clearly there are some priorities out of whack there, and given the insecure nature of e-mail in the first place, I would never want to deal with a company that is so clearly unprofessional.
Use Amazon SES to generate your outbound emails; ensure proper IAM policies, and that you're using 2 factor auth to login to your AWS account.
Is AWS any less susceptible to Social Engineering attack of this type? Specifically--can AWS support staff grant access to AWS accounts, and if so: what are their criteria for doing so, and what are the policies in place to ensure those criteria are met, and how are those policies audited? As a TechStars alum, my company was granted $50k in AWS credits, which were tied to my AWS account[1]. When I left the Company, t…
What I found most interesting was they were targeted due to Bitcoin. Today most services would never store credit cards themselves but rather have them stored at a secure payment gateway. So they're unlikely to be attacked to get to those cards. T Trust me I know that CC's are getting sniffed in transit too often so I'm not saying they're 'safe'. I'm just wondering if there is something unique to Bitcoin that suddenl…
Earlier quoted context omitted.
I don't see how this was specific to ChunkHost, or how anybody else using SendGrid and supporting password resets through email wouldn't be vulnerable to the same attack... Since presumably password reset emails aren't outside SendGrid's target market, it seems reasonable to suggest that this is a problem SendGrid should try to fix.
Generally, an outsider doesn't care that you got owned because someone you relied upon got owned. They consider it part of your job that you make sure all the people you rely upon are reliable. I'm not saying this is fair.
So what's the answer? Here's two very legitimate scenarios: 1) You sign up, enable two-factor auth, then lock yourself out (lost password and your second-factor). How do you prove to the service provider that you are you? 2) You sign up, enable two-factor auth, then Mallory claims that they locked themselves out. How does the service provider prove that Mallory is not you?
1) You decide how valuable the account is, the probability that you will lose access to the account, and the probability that the account will be attacked. 2) You selected the required number of recovery actions, from one recovery action to completely unrecoverable. Possible recovery actions include (copied from NFSN):
* You provide a scanned copy of a government-issued photo ID. * You provide a scanned copy of a statement showing both the most recent deposit and a name and address matching one of your accounts. * You complete SMS verification. (SMS must be previously configured.) * You complete 2-factor verification. (2-factor auth must be previously configured.) * You correctly answer your security question. (Security question and answer must be previously configured, below.) * You use an ssh key to create a file with a specific name on one of your sites hosted here. (Must be previously configured, won’t work if account is empty.) * We try and fail to contact you via your currently configured email address. (This one may take a long time.)
As far as I'm concerned, this is the way it should be done. The public details are on their blog: https://blog.nearlyfreespeech.net/2014/02/28/price-cuts-more...