Live data from Hacker News

Improved Authentication for Email Encryption and Security

protonmail.com

41–50 of 77 posts

Re: Improved Authentication for Email Encryption and Security

#41

Earlier quoted context omitted.

I didn't miss anything when I left Gmail, but I imagine it depends a lot on how you use email. I switched to Fastmail on my own domain and actually prefer the webmail interface over Gmail. I mainly use IMAP via Mail.app on my laptop and phone, Pantheon Mail (formerly Geary) on my desktop. I use PGP wherever I can. I haven't received any spam at all yet, so I can't comment on how their spam filters compare to Gmail. I…

Right now, I also try to keep Google as far away from me as I can. Unfortunately, I don't own a domain myself. Have you tried out ProtonMail yourself? If so, do you think that it is a good alternative to a self-hosted server like Fastmail?

I have not used ProtonMail myself so I can't help you there I'm afraid.

While I use Fastmail with my own domain, it is not self-hosted. My MX records point to Fastmail's servers.

Re: Improved Authentication for Email Encryption and Security

#42

Earlier quoted context omitted.

I didn't miss anything when I left Gmail, but I imagine it depends a lot on how you use email. I switched to Fastmail on my own domain and actually prefer the webmail interface over Gmail. I mainly use IMAP via Mail.app on my laptop and phone, Pantheon Mail (formerly Geary) on my desktop. I use PGP wherever I can. I haven't received any spam at all yet, so I can't comment on how their spam filters compare to Gmail. I…

Does Pantheon-Mail support PGP?

It does not. I really hope they add the feature soon – in the meantime I use gpg on the commandline.

I've been tempted to add the support in myself, however I do not have any experience with the elementary codebase or Vala, so a cryptographic system would be a very poor choice for a first project!

Re: Improved Authentication for Email Encryption and Security

#43
post #40

"In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash." I wondered why they didn't do this. As a customer, this is a welcome change. One thing that is of general concern to me: I tend to use a lot of encrypted traffic because much of my work is done on SSH shells to servers, and some of my customers request encrypting work files and use V…

> With also using ProtonMail, I would expect to be on a government list of some sort. Are you aware what kind of idea you are circulating here? It's the kind of idea citizens in totalitarian states would circulate, probably even in the hope to score points from their dictator, for participating in instilling "order". Dude, wake up. This is sick .

In a world where both large Internet companies and governments collect meta data, possible collect more than meta data, set up fake cell towers, etc., I think it is naive to not think that they are also collecting statistics on the use of encryption.

Perhaps you misunderstood me?

Re: Improved Authentication for Email Encryption and Security

#44
post #3

how practical is it to drop GMail for these guys? I'm tied fairly heavily to the Google ecosystem (Chome, Play, Finance, etc etc). They already have a mountain of data on me, but I really want to start taking encryption and privacy more seriously.

I didn't miss anything when I left Gmail, but I imagine it depends a lot on how you use email. I switched to Fastmail on my own domain and actually prefer the webmail interface over Gmail. I mainly use IMAP via Mail.app on my laptop and phone, Pantheon Mail (formerly Geary) on my desktop. I use PGP wherever I can. I haven't received any spam at all yet, so I can't comment on how their spam filters compare to Gmail. I…

I haven't received any spam at all yet, so I can't comment on how their spam filters compare to Gmail.

I receive more spam in my inbox than in Google Mail (I used Google Apps), but it's not extreme. Typically two or three spam mails per week.

Of course, you get a lot back. As you say, I better web interface and standards-conforming IMAP.

Re: Improved Authentication for Email Encryption and Security

#46

"In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash." I wondered why they didn't do this. As a customer, this is a welcome change. One thing that is of general concern to me: I tend to use a lot of encrypted traffic because much of my work is done on SSH shells to servers, and some of my customers request encrypting work files and use V…

Our government already cares very deeply about this sort of thing. It is important to read more than just the headlines involving something absurd stated by tech-illiterate politicians.

http://csrc.nist.gov/publications/PubsSPs.html

https://www.iad.gov/iad/index.cfm

Re: Improved Authentication for Email Encryption and Security

#47
post #37
post #33

We had this at Lavaboom (German encrypted email, bankrupt) 2 years ago. Our designer came up with this idea, I initially wanted to implement the classic 2 password design. The tricky bits are (1) explaining to the users that they can't reset their password and (2) supporting users who opt for manual key management (e.g. I own name@mydomain.com and I want to move from Google Apps + GPGtools to Lavaboom/Protonmail/etc)…

>The tricky bits are (1) explaining to the users that they can't reset their password So that's interesting, because as I understand it ProntonMail does allow users to reset their password using a recovery email, although the feature can be disabled in the settings.

If a user resets their single password or encryption password, they lose access to their previous e-mail. This is because what essentially happens is that a new PGP keypair is generated and the Secret Key is encrypted with the new password. Since we do not have their old, lost, password we cannot access their secret key to decrypt the e-mails (and subsequently re-encrypt them with the new Public Key).

Re: Improved Authentication for Email Encryption and Security

#48
post #37
post #33

We had this at Lavaboom (German encrypted email, bankrupt) 2 years ago. Our designer came up with this idea, I initially wanted to implement the classic 2 password design. The tricky bits are (1) explaining to the users that they can't reset their password and (2) supporting users who opt for manual key management (e.g. I own name@mydomain.com and I want to move from Google Apps + GPGtools to Lavaboom/Protonmail/etc)…

>The tricky bits are (1) explaining to the users that they can't reset their password So that's interesting, because as I understand it ProntonMail does allow users to reset their password using a recovery email, although the feature can be disabled in the settings.

An alternative is to generate a bunch of recovery keys, encrypt the PGP key pair with each of them, and store the result (but not the recovery keys). If you go for the 1 password solution this should be a no brainer, but still way too complicated for the utterly non-technical user (so most of them).

Re: Improved Authentication for Email Encryption and Security

#49

This all seems to be a web-based application ( https://github.com/ProtonMail/WebClient ). How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code? The arguments against server-supplied, js-in-the-browser crypto have been done to death. Why is this any different, and why am I wrong to dismiss it out-of-hand as (in)secure as simpl…

Sorry for any confusion. We don't use TLS-SRP, we use certificate TLS, and SRP on top of it. The short discussion on TLS-SRP was trying to address any potential questions about different choices we made with respect to TLS-SRP.

Re: Improved Authentication for Email Encryption and Security

#50

This all seems to be a web-based application ( https://github.com/ProtonMail/WebClient ). How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code? The arguments against server-supplied, js-in-the-browser crypto have been done to death. Why is this any different, and why am I wrong to dismiss it out-of-hand as (in)secure as simpl…

Also, yes, the application is web-based, but we also have native mobile clients which use the same API, and are working on two more native options for desktop.
Post reply on HN