| ▲ | prmph 2 days ago | |||||||||||||||||||||||||||||||||||||||||||
I fail to see how preventing email changes solves the issues you listed, or how allowing it necessarily makes them worse. | ||||||||||||||||||||||||||||||||||||||||||||
| ▲ | blitzegg 2 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||
That's pretty obvious to anyone who had to maintain a high traffic site. Just the tip of the iceberg (I haven't included additional legal issues and other): 1.1 Strong protection against account takeover Email change is one of the most abused recovery vectors in account takeover (ATO). Eliminating email changes removes: Social-engineering attacks on support SIM-swap → email-change chains Phished session → email swap → lockout of real user Attacker must compromise the original inbox permanently, which is much harder. 1.2 No “high-risk” flows Email change flows are among the highest-risk product flows: Dual confirmation emails Cooldown periods Rollback windows Manual reviews Fixed email removes an entire class of security-critical code paths. 1.3 Fewer recovery attack surfaces No need for: “I lost access to my email” flows Identity verification uploads Support-driven ownership disputes Every recovery mechanism is an attack surface; removing them reduces risk. | ||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||