It would be cool if they stored a hash of the recovery email, then you type it out during the recovery process and they can send if the hash matches what they got.
Sure, but that’s essentially a weaker recovery password (which also is an option in Proton).
Also that poses quite some challenges for email verification (say, you make a typo when you first write your address), let alone the fact that you won’t see what emails you have configured essentially, which is also bad UX.
I think it’s much simpler to have recovery email as it is and -if one doesn’t want to associate proton account with any other account- offer other recovery methods, which are available (phrase and phone number).
I disagree it would be the same as a password. They do use only the hash to validate the entry, that is the same. But then they send recovery to the email instead of proceeding in place. An attacker would have to both know the email and be able to access its inbox. (Or, less likely, generate a hash collision with an address they do control.)
I think they could do verification if they kept the plaintext address just long enough to send something out.
The UX of only being able to show hashes would be pretty unfortunate, sure. Maybe that’s a potential compromise if they kept just a first letter, likex***@example.com? Same number of stars in the interface regardless of the real length of email, to attempt to leak less info.
But the question is “why”?
Email addresses are personal but not secrets, there is no reason to add complexity and worsen the UX for such a feature imo. If anybody is not comfortable with this particular piece of data being associated with their account, they can just use a recovery phrase. It is by no means a necessary feature. What would be the advantage of having a recovery email “obscured”?
The advantage of the functionality as-is is that it’s trivial to see what you have configured, it’s trivial to change address etc.
All of this to add an ineffective amount of privacy. If someone is under investigation, having the hash of the recovery email is in many case sufficient. Asking Apple/Gmail/Microsoft if the hash matches any of their customers covers probably 98% of the population. Billions of emails are also available through breaches, so there is very very high chance that if someone used their personal email, it’s either with one of the big providers, or it has been leaked before. If it’s not, and you used a private provider with no data, then there is no problem even if the address is obtained, as that cannot be further used to de-anonymize you.
You’re incorrect. If they salt the hash and use bcrypt it is computationally infeasible for Microsoft to match it against a customer. Or at least expensive enough that Microsoft would insist on warrants and subpoenas.
It would be cool if they stored a hash of the recovery email, then you type it out during the recovery process and they can send if the hash matches what they got.
Sure, but that’s essentially a weaker recovery password (which also is an option in Proton).
Also that poses quite some challenges for email verification (say, you make a typo when you first write your address), let alone the fact that you won’t see what emails you have configured essentially, which is also bad UX.
I think it’s much simpler to have recovery email as it is and -if one doesn’t want to associate proton account with any other account- offer other recovery methods, which are available (phrase and phone number).
I disagree it would be the same as a password. They do use only the hash to validate the entry, that is the same. But then they send recovery to the email instead of proceeding in place. An attacker would have to both know the email and be able to access its inbox. (Or, less likely, generate a hash collision with an address they do control.)
I think they could do verification if they kept the plaintext address just long enough to send something out.
The UX of only being able to show hashes would be pretty unfortunate, sure. Maybe that’s a potential compromise if they kept just a first letter, like
x***@example.com? Same number of stars in the interface regardless of the real length of email, to attempt to leak less info.But the question is “why”? Email addresses are personal but not secrets, there is no reason to add complexity and worsen the UX for such a feature imo. If anybody is not comfortable with this particular piece of data being associated with their account, they can just use a recovery phrase. It is by no means a necessary feature. What would be the advantage of having a recovery email “obscured”? The advantage of the functionality as-is is that it’s trivial to see what you have configured, it’s trivial to change address etc.
All of this to add an ineffective amount of privacy. If someone is under investigation, having the hash of the recovery email is in many case sufficient. Asking Apple/Gmail/Microsoft if the hash matches any of their customers covers probably 98% of the population. Billions of emails are also available through breaches, so there is very very high chance that if someone used their personal email, it’s either with one of the big providers, or it has been leaked before. If it’s not, and you used a private provider with no data, then there is no problem even if the address is obtained, as that cannot be further used to de-anonymize you.
You’re incorrect. If they salt the hash and use bcrypt it is computationally infeasible for Microsoft to match it against a customer. Or at least expensive enough that Microsoft would insist on warrants and subpoenas.