> In other words, theoretically spoofing could occur, but there are compensating controls in place to minimize any damage. Given a very low likelihood of an attack in this direction, that felt like a reasonable compromise. Would love to get feedback on that though!
I don't have good recommendations right now[1], but I think not having a way to opt-out for those who are security conscious is a turn-off for some people. After all, having opt-out[2] doesn't impact the existing users who don't care (they won't even notice), while those who care can turn it off.
I mean, as a user I disagree with your assessment of the probability of an attack using this vector, but I don't want to argue with you about it, I just want to turn it off for my account.
After all, if I said something similar about an exploit in my product, I can expect to get roasted by the users. For example, if there is a well-known buffer-overflow in my product, and I said something like this:
"In other words, theoretically users could send a value for the 'email' field larger than 255 bytes and smash the stack, but there are compensating controls in place to minimize the damage from overwriting the return address. Given a very low likelihood of a user sending more than 255 bytes for an email address, it felt like a reasonable compromise."
With security you can't really tell in advance how an exploit might be escalated. The only damage you see from allowing spoofed emails is "attacker causes candidates to reject a position they don't want to reject". Could there be others?
Could a coworker who knows I am on the prowl send an email to no@ with my address set in the 'from:' field and his set in the "forwarded" email? At the very least this sounds like a leak of account email addresses.
Still, see my point [2] below - maybe the return on implementing controls for attack prevention won't help your product at this stage. It might make more business sense to rely on mitigating the damage than preventing it.
[1] Simple: Don't send anything, place it in an outbox that the user can review before hitting 'send all'. Complex: Require user to upload their public key and process messages signed with the private key. Neither of these are 'good' in the sense of frictionless management via email.
[2] It depends on how much time you have. If this is a thing that would take 4 hours to implement, test and document, maybe you product has more pressing issues that those 4 hours would be better spent on. You'll have to triage the feedback you get and determine which feedback would result in the most takeup. IME, people often don't care about security, so you might find that spending even 5m on this has less positive influence on the business than spending those 5m cold-calling customers.
FYI - I added an "opt out" option for email processing. Any incoming emails for the opted-out address will be silently ignored (same as incoming emails for non-existent addresses).
Just want to say I super appreciate your balanced perspective here. I'm not a security engineer by trade, so getting this sort of feedback is quite valuable.
The no@ scenario is an interesting one. The opt-out would certainly be one clean approach here. Going to give it some thought!
You could also consider a “personalized” no+uuid@ address that only the user knows. Slightly more work, but the user would just add it to their address book anyway.
I don't have good recommendations right now[1], but I think not having a way to opt-out for those who are security conscious is a turn-off for some people. After all, having opt-out[2] doesn't impact the existing users who don't care (they won't even notice), while those who care can turn it off.
I mean, as a user I disagree with your assessment of the probability of an attack using this vector, but I don't want to argue with you about it, I just want to turn it off for my account.
After all, if I said something similar about an exploit in my product, I can expect to get roasted by the users. For example, if there is a well-known buffer-overflow in my product, and I said something like this:
"In other words, theoretically users could send a value for the 'email' field larger than 255 bytes and smash the stack, but there are compensating controls in place to minimize the damage from overwriting the return address. Given a very low likelihood of a user sending more than 255 bytes for an email address, it felt like a reasonable compromise."
With security you can't really tell in advance how an exploit might be escalated. The only damage you see from allowing spoofed emails is "attacker causes candidates to reject a position they don't want to reject". Could there be others?
Could a coworker who knows I am on the prowl send an email to no@ with my address set in the 'from:' field and his set in the "forwarded" email? At the very least this sounds like a leak of account email addresses.
Still, see my point [2] below - maybe the return on implementing controls for attack prevention won't help your product at this stage. It might make more business sense to rely on mitigating the damage than preventing it.
[1] Simple: Don't send anything, place it in an outbox that the user can review before hitting 'send all'. Complex: Require user to upload their public key and process messages signed with the private key. Neither of these are 'good' in the sense of frictionless management via email.
[2] It depends on how much time you have. If this is a thing that would take 4 hours to implement, test and document, maybe you product has more pressing issues that those 4 hours would be better spent on. You'll have to triage the feedback you get and determine which feedback would result in the most takeup. IME, people often don't care about security, so you might find that spending even 5m on this has less positive influence on the business than spending those 5m cold-calling customers.