Improved Authentication for Email Encryption and Security
protonmail.com
protonmail.com
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 VPNs. With also using ProtonMail, I would expect to be on a government list of some sort. Given the general anti-privacy and anti-encryption rhetoric from public government officials this is a concern.
What our government should do is a moon-shot level of effort to promote strong encryption and very robust digital infrastructure. While this might unfortunately make law enforcement's job a little more difficult, the advantages in fighting computer crime and generally saving businesses, citizens and the government money would be worth it. I think it would also increase our level of national security, with all of our systems less hackable.
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.
Perhaps you misunderstood me?
They did. It was called the Computer Security Initiative. It was the culmination of efforts starting with Anderson Report that collectively invented INFOSEC and deployed high-assurance versions. Early releases were secure messaging, the BLACKER VPN, MLS endpoints, private databases, and so on. Industry ignored it in favor of cheapest, fanciest products with features moving at explosive pace. Congress's (or DOD's) COTS mandate and NSA's MISSI initiative finished it off by reducing government contracts for high-security product.
So, it's been done here before. It would work again. Just no will to do it on top esp with Microsoft and IBM's lobbying. ;) At least the papers on requirements and methods for achieving that were all published. Some still use the methods in commercial sector and CompSci. The first, secure systems are still available comnercially on not-so-secure hardware (i.e. Intel). Just almost no uptake in FOSS for such methods despite a labor advantage.
Hi there! Ive seen you post on these before; do you have a collection of links or references to papers an infosec engineer interested in this should read? Ty
our (brilliant) designer http://www.felixvonlooz.com/
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.
Considering how emails can stay in service storage for decades , (even longer if archived by spies, etc), their security is now reaching the requirements of data on Hard Drives.
If we're to push end-to-end encryption to the masses, then we ought to try to get forward secrecy in it, and it should be quite invisible to the user.
That's not to say that ProtonMail is getting it right, but it's at least one of the few that are striving to move in that direction.
Relevant post from Moxie from Open Whisper Systems:
If you have a replacement for GPG and E-Mail please tell me what it is.
But adoption is even worse than pgp
Moxie writes from a personal perspective and you'll notice he never claims to have something better in hand. His Signal still lacks utterly basic functionality provided by PGP, most important among them the ability to transmit arbitrary attachments (Signal only supports an undisclosed list of media attachments) but also including the ability to retain your messages long term in a particular location. Meanwhile, many of the tradeoffs made to make Signal easy could be made using PGP: Automatic generation of keys; centralized key repo; centralized mapping of keys to contact points (email/phone); trust by default.
Today's messaging services (Signal, Wire, Telegram, etc...) outpace email by a significant margin.
"In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash. The input to this hash includes a salt provided by the server on login but not stored in the client. In this way, compromise of the mailbox password does not automatically lead to compromise of the login password."
This means, if my password is "123hello" then the mailbox password is hash(derived("123hello"),secret_salt) where, hash is an hash algorithm (which one?), the secret_salt is a value stored in the server and never sent to the client, and the derived("123hello") is a password computed using the SRP protocol, which should be the session key explained here https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco..., correct? the part of the SRP and on how to genreate the password in SRP is a bit obscure to me, just trying to understand.
I wonder what the password change procedure will be when you have several gigabytes of mail in your mailbox? Would you have to download every message, re-encrypt it in your browser and send back?
> I suppose org-agenda could substitute but the way Inbox organizes all my travel is worth the fact that Google knows i'm flying to London.
Well.. at some point you have to choose something over the other.
In general, I should say I am pretty happy with protonmail. I've been using it for over a year now, however, in general I'm still pretty dependent on google for calendar, android, etc.
When it comes to spam, my feeling is that I do get more now. But as long as it is properly categorized -- which it is -- I don't really mind getting it.
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 maintain a zero inbox – important stuff gets archived, and everything else is deleted. This means that I don't miss Gmail's search feature as hardly keep any emails. Obviously your mileage may vary here. They also support CalDAV and CardDAV – so all of my notes, contacts, calendar items etc. are synced across my devices.
I've moved from Google completely, and for the most part, I don't really miss them all that much.
- Search -> DuckDuckGo (I do miss Google here – DDG's search results pale in comparison)
- Gmail -> Fastmail
- Maps -> Citymapper and Apple Maps
- Chrome -> Safari on macOS, Firefox on everything else (my experience with FF is a bit 'meh' – it was incredibly laggy on my work laptop, but runs great on my desktop)
While I use Fastmail with my own domain, it is not self-hosted. My MX records point to Fastmail's servers.
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!
Google does derive real revenue from me, but not so much via their advertising business.
Edit: FastMail is a very good email service, BTW.
Honestly, DDG surpassed google search years ago. I've preferred Firefox for a long time, and Fastmail's UI and service is incredibly superior to GMail. I guess the cost might be the only downside.
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.
I found the tool to be fast, comprehensive, and the partial migration was very effective.
One the search front, I've been finding https://www.startpage.com/ to be a really nice alternative to DDG.
One could probably automate a browser to log in, iterate mailbox and dump contents, but that certainly won't be fun.
(Also, no way to use your own pre-existing key, only somehow generating a new one somewhere - not sure how exactly it's implemented and whenever I can trust it all...)
https://protonmail.com/support/knowledge-base/transitioning-...
What may give you a push is that Google seems to be trying to make Gmail a more proprietary and less of an interoperable standardized email service. Eventually it may not be as easy to get out of that "lock-in" as it is now (even though it seems hard, but it's mostly a matter of habit and will to change to a new service).
I've realized that I don't really care about Google having access to my transactional mail (things knowable from third parties anyways), but do want personal communications properly encrypted. Basically, I've only moved over my "priority inbox," and keep using Gmail for junk.
Very satisfied with Protonmail though. Especially knowing they are working on fixing their lock-in issues.
Why is this any different, and why am I wrong to dismiss it out-of-hand as (in)secure as simply sending unencrypted data to the server? Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server).
> we choose our own primes rather than those used by TLS
Does TLS specify any primes? You can use your own DH primes, SRP primes, and your key is your own prime. Those RFCs recommend primes, but allow the server to use different ones. TLS, SRP, or DH doesn't "use" a single prime, any prime satisfying the requirements in the RFC is acceptable. know it's nitpicking but something about how it was said rubbed me the wrong way.
I would love to know how they communicate between their TLS-SRP layer and their authentication layer. Most implementations are file-based. Did they write a plugin for gnutls or openssl? Did they write their own TLS layer?
I would love for TLS-SRP to be more wide-spread, but this is always the biggest hurdle to adoption in my case.
Nobody says it's different
>Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server).
OK, let's suppose you're using a native app. One day vendor issues an update with some critical vulnerability patched. Unfortunately, another vulnerability (or even backdoor) sneaks into this update for whatever reasons. How is this any different?
In a web app, they can send a backdoored copy of the code just to you and just a single time, which is much harder to detect.
They why do all the extra work for no gain in security?
I think the sibling comment address your next comment well.
A unique solution might be to use service workers to handle content "updates". The assets could be cached locally, and a single network request could be fired to check for updates. If one exists, the user is prompted to update. This would at least alert you to review the code being sent to your browser if you're so inclined.
Ultimately though it comes down to yet another tradeoff of security vs convenience. Such a feature might be better off as an opt-in extra security feature.