4 ms·

The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?

remram 4y ago
Having to tell an ordinary user that their domain didn't configure DKIM properly so sign up didn't work and they now have to go through an alternate flow sounds like a nightmare. The article does not mention what to do with the many users who don't already have the mentioned security mechanisms, just that they are "commonly deployed".
throwaway892238 4y ago
Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password reset form, it has no bearing whatsoever on security.
- archi42 4y ago
  The same attacks can likely also be used to capture verification emails. E.g. for DNS if you can spoof TXT records for Gmail using some malicious server, chances are you can also spoof MX records. And I can't think of shenanigans with BGP that allow you sending spoofed emails that pass DKIM, SPF and DMARC (ultimately routing traffic to your malicious server again), but not allow capturing of mails. I think the suggested flow is a valid idea to discuss, even though at the end of the day it's still a bad idea (others have formulated a lot of valid criticism that I agree with). But I find your criticism to be unfair, as it also applies to the traditional flow and should rather be a reason not to use email at all (begging the question: What secure alternative should be used?).
- samtho 4y ago
  > or an attack on DNS or BGP, or any other novel spoofing attack Even though it’s be relevant form as systems-thinking point of view, it’s pretty unfair to dismiss a solution because it will be vulnerable to very important pieces of Internet network infrastructure. I think it’s safe to say that if we get a sufficiently bad vulnerability in DNS or BGP, account confirmation emails are going to be least of our worries. Additionally “any novel spoofing attack” is a very hand-wavy, low effort way to dismiss it as well.
  - throwaway892238 4y ago
    It's not unfair to point out a design as needlessly insecure. Regardless of the method, this design adds a new attack vector (email spoofing) that did not exist before. Even if it was very hard to do, it's an unnecessary added risk.
frenchman99 4y ago
Yes I do find them unsound. Now you need ordinary people to understand the pros and cons of DMARC (SPF + DKIM). Not every one has this configured. In fact it's shocking how many companies don't have DMARC set up given the benefits. If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be universally used.
- throwaway892238 4y ago
  As an example: AWS has no DMARC on its SES domain, and its SES domain is what sends SES emails from by default. Anyone who's not using a custom domain with SES, has no way for anyone to validate where that email came from. All CloudWatch alerts come via the generic SES domain, so there is literally no way to tell if a CloudWatch alert is spoofed or not. I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.

remram 4y ago

Having to tell an ordinary user that their domain didn't configure DKIM properly so sign up didn't work and they now have to go through an alternate flow sounds like a nightmare. The article does not mention what to do with the many users who don't already have the mentioned security mechanisms, just that they are "commonly deployed".

throwaway892238 4y ago

Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password reset form, it has no bearing whatsoever on security.

archi42 4y ago
The same attacks can likely also be used to capture verification emails. E.g. for DNS if you can spoof TXT records for Gmail using some malicious server, chances are you can also spoof MX records. And I can't think of shenanigans with BGP that allow you sending spoofed emails that pass DKIM, SPF and DMARC (ultimately routing traffic to your malicious server again), but not allow capturing of mails. I think the suggested flow is a valid idea to discuss, even though at the end of the day it's still a bad idea (others have formulated a lot of valid criticism that I agree with). But I find your criticism to be unfair, as it also applies to the traditional flow and should rather be a reason not to use email at all (begging the question: What secure alternative should be used?).
samtho 4y ago
> or an attack on DNS or BGP, or any other novel spoofing attack Even though it’s be relevant form as systems-thinking point of view, it’s pretty unfair to dismiss a solution because it will be vulnerable to very important pieces of Internet network infrastructure. I think it’s safe to say that if we get a sufficiently bad vulnerability in DNS or BGP, account confirmation emails are going to be least of our worries. Additionally “any novel spoofing attack” is a very hand-wavy, low effort way to dismiss it as well.
- throwaway892238 4y ago
  It's not unfair to point out a design as needlessly insecure. Regardless of the method, this design adds a new attack vector (email spoofing) that did not exist before. Even if it was very hard to do, it's an unnecessary added risk.

frenchman99 4y ago

Yes I do find them unsound. Now you need ordinary people to understand the pros and cons of DMARC (SPF + DKIM). Not every one has this configured. In fact it's shocking how many companies don't have DMARC set up given the benefits. If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be universally used.

throwaway892238 4y ago
As an example: AWS has no DMARC on its SES domain, and its SES domain is what sends SES emails from by default. Anyone who's not using a custom domain with SES, has no way for anyone to validate where that email came from. All CloudWatch alerts come via the generic SES domain, so there is literally no way to tell if a CloudWatch alert is spoofed or not. I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.