3 ms·

Why isn’t it actually possible to just encrypt saved emails on server? So that government does not have access. Couldn’t one use a hash of the password as key f

Why isn’t it actually possible to just encrypt saved emails on server? So that government does not have access. Couldn’t one use a hash of the password as key for the data for the data and not save that hash to check password but another one. This way (practically), at least if the password is not eavesdropped and saved by the mail provider, it would be much harder to give away emails.

ashelmire 8y ago
Without saving a hashed password, you can’t authenticate users. End to end encryption like what you really want requires the data to be decrypted by the recipient (using a key or password).
geofft 8y ago
Because the service provider receives the unencrypted email and can choose to save a copy, encrypt it to a different key, etc. This was the scam Lavabit pulled, and the government called them on their bluff and asked for a copy of the key and Lavabit had no legal ability to refuse. If the threat model does not include a government with the ability to use legal process, it needs to be defined more precisely. In general the US government can use legal process in the US and just straight-up hack into things elsewhere (who's going to raise a diplomatic incident over it? Russia is literally poisoning people, nobody cares, and their military is less powerful than the US's). If your threat model is other governments or just unrelated attackers like advertisers, there are more straightforward approaches.
- SturgeonsLaw 8y ago
  Calling Lavabit a scam is a bit of a stretch. They, by all appearances, genuinely tried to offer email as secure as it could be, given the limitations of the protocol, and when pressured to give up the keys chose instead to inform their users and fold the business.
  - geofft 8y ago
    They made promises that they should have known were impossible to keep. In my books, that's a scam. Sure, they tried very hard to keep them, but that doesn't change the fact that they could not deliver on their promises and anyone could have told them that. Also, no, they did not inform their users. They handed over the key and waited for users to notice court documents. See my previous comment: https://news.ycombinator.com/item?id=13447340#13448609 https://news.ycombinator.com/item?id=13447340#13448609
brongondwana 8y ago
Apart from the "users lose their passwords all the fricking time" problem (seriously, before we implemented https://fastmail.blog/2017/12/06/security-account-recovery/ https://fastmail.blog/2017/12/06/security-account-recovery/, lost password was always in the top 3 most common support requests of the week report) Impementing per-message-encryption would turn us into a dumb blob store. The whole point of FastMail is the value add - fast search, ability to deal with a lot of email quickly, etc. That and people's devices are basically always on these days, and fetch new email immediately on a push when messages arrive. So if your provider get a subpoena or gets hacked, then a push request will make your device connect with the password, and boom - access granted. Finally, we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices, so we require people to create app passwords. This would be in direct opposition to many of the other safety things that are done. (extra finally: phishing protections and antispam solutions are in pretty much direct opposition to the idea of the server not being able to see the content of emails)
- bachmeier 8y ago
  > we require people to create app passwords I like that, because it at least feels more secure to have a password that can only be used once, combined with the ability to go into the settings and shut off any device if it gets lost.
  - brongondwana 8y ago
    Yeah, it's by far the best of the options that use standard username/password authentication support. Basically make the password be another server-provided factor rather than user-chosen.
- deleted 8y ago
  [deleted]
- forapurpose 8y ago
  Thanks; it's very helpful to know the ins and outs from a practitioner. I am confused by a couple of them: > if your provider get a subpoena or gets hacked, then a push request will make your device connect with the password, and boom - access granted If the message is decrypted only on my device, then that wouldn't matter. I'm guessing endpoint decryption is not what you (or maybe the GP) are talking about, but I don't know what you mean. > we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices, so we require people to create app passwords. This would be in direct opposition to many of the other safety things that are done What is an "app password"? If it's just a password stored in an app (and then what is a non-app password? one in a text file?), why wouldn't it be as vulnerable to device hacking? ..... Also, a couple of genuine questions about what's possible: > Impementing per-message-encryption would turn us into a dumb blob store. The whole point of FastMail is the value add - fast search, ability to deal with a lot of email quickly, etc. Email messages arrive in the clear, unavoidably; new messages are always vulnerable. Why not do the processing then - spam filtering, build a search index of hash values, etc.? Then permanently (from the server's perspective) encrypt the old, stored messages, and give endpoint/user the only means of decryption. > users lose their passwords all the fricking time > we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices How do the end-to-end secure messaging applications, such as Signal, handle those issues, if anyone knows?

ashelmire 8y ago

Without saving a hashed password, you can’t authenticate users. End to end encryption like what you really want requires the data to be decrypted by the recipient (using a key or password).

geofft 8y ago

Because the service provider receives the unencrypted email and can choose to save a copy, encrypt it to a different key, etc. This was the scam Lavabit pulled, and the government called them on their bluff and asked for a copy of the key and Lavabit had no legal ability to refuse. If the threat model does not include a government with the ability to use legal process, it needs to be defined more precisely. In general the US government can use legal process in the US and just straight-up hack into things elsewhere (who's going to raise a diplomatic incident over it? Russia is literally poisoning people, nobody cares, and their military is less powerful than the US's). If your threat model is other governments or just unrelated attackers like advertisers, there are more straightforward approaches.

SturgeonsLaw 8y ago
Calling Lavabit a scam is a bit of a stretch. They, by all appearances, genuinely tried to offer email as secure as it could be, given the limitations of the protocol, and when pressured to give up the keys chose instead to inform their users and fold the business.
- geofft 8y ago
  They made promises that they should have known were impossible to keep. In my books, that's a scam. Sure, they tried very hard to keep them, but that doesn't change the fact that they could not deliver on their promises and anyone could have told them that. Also, no, they did not inform their users. They handed over the key and waited for users to notice court documents. See my previous comment: https://news.ycombinator.com/item?id=13447340#13448609 https://news.ycombinator.com/item?id=13447340#13448609

brongondwana 8y ago

Apart from the "users lose their passwords all the fricking time" problem (seriously, before we implemented https://fastmail.blog/2017/12/06/security-account-recovery/ https://fastmail.blog/2017/12/06/security-account-recovery/, lost password was always in the top 3 most common support requests of the week report) Impementing per-message-encryption would turn us into a dumb blob store. The whole point of FastMail is the value add - fast search, ability to deal with a lot of email quickly, etc. That and people's devices are basically always on these days, and fetch new email immediately on a push when messages arrive. So if your provider get a subpoena or gets hacked, then a push request will make your device connect with the password, and boom - access granted. Finally, we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices, so we require people to create app passwords. This would be in direct opposition to many of the other safety things that are done. (extra finally: phishing protections and antispam solutions are in pretty much direct opposition to the idea of the server not being able to see the content of emails)

bachmeier 8y ago
> we require people to create app passwords I like that, because it at least feels more secure to have a password that can only be used once, combined with the ability to go into the settings and shut off any device if it gets lost.
- brongondwana 8y ago
  Yeah, it's by far the best of the options that use standard username/password authentication support. Basically make the password be another server-provided factor rather than user-chosen.
deleted 8y ago
[deleted]
forapurpose 8y ago
Thanks; it's very helpful to know the ins and outs from a practitioner. I am confused by a couple of them: > if your provider get a subpoena or gets hacked, then a push request will make your device connect with the password, and boom - access granted If the message is decrypted only on my device, then that wouldn't matter. I'm guessing endpoint decryption is not what you (or maybe the GP) are talking about, but I don't know what you mean. > we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices, so we require people to create app passwords. This would be in direct opposition to many of the other safety things that are done What is an "app password"? If it's just a password stored in an app (and then what is a non-app password? one in a text file?), why wouldn't it be as vulnerable to device hacking? ..... Also, a couple of genuine questions about what's possible: > Impementing per-message-encryption would turn us into a dumb blob store. The whole point of FastMail is the value add - fast search, ability to deal with a lot of email quickly, etc. Email messages arrive in the clear, unavoidably; new messages are always vulnerable. Why not do the processing then - spam filtering, build a search index of hash values, etc.? Then permanently (from the server's perspective) encrypt the old, stored messages, and give endpoint/user the only means of decryption. > users lose their passwords all the fricking time > we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices How do the end-to-end secure messaging applications, such as Signal, handle those issues, if anyone knows?