New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PGP Keys gone after restart #349

Open
hermann88 opened this Issue Oct 10, 2014 · 61 comments

Comments

Projects
None yet
@hermann88
Copy link

hermann88 commented Oct 10, 2014

Hello,
when i restart my server all PGP Keys what have been saved before are gone, private as well as public, i need to copy the key each time again to be able to decrypt/encrypt/sign messages.

Please fix, its annoying!
Thanks!

@RainLoop

This comment has been minimized.

Copy link
Owner

RainLoop commented Oct 10, 2014

PGP Keys are not stored in the server. They are stored in your browser local storage.

@hermann88

This comment has been minimized.

Copy link
Author

hermann88 commented Oct 10, 2014

How can i store them in the server, browser local storage get cleared every day.
Server is in private network, doesnt make sense to me to store it in unsafe browser.
Need to copy it than always in clipboard (whats also not safe) to be able to encrypt/decrypt/sign messages.

@programacion-web

This comment has been minimized.

Copy link

programacion-web commented Feb 23, 2015

I think the same thing should be an option that let you store it on the server, and allows you to use more of a private key in the event that someone has different identities with the same e-mail account.

@ConnorMcF

This comment has been minimized.

Copy link

ConnorMcF commented Apr 2, 2015

Bump. I think this should be added too!

@cluelessperson

This comment has been minimized.

Copy link

cluelessperson commented May 12, 2015

Yup, I'm running into this too. My personal server is meant to be trusted with the keys. Honestly, I'd be very happy with server side key management and not Javascript.

@RainLoop RainLoop closed this Sep 18, 2015

@ConnorMcF

This comment has been minimized.

Copy link

ConnorMcF commented Sep 28, 2015

So you're not adding it then..

@cluelessperson

This comment has been minimized.

Copy link

cluelessperson commented Oct 13, 2015

Rainloop PGP is unusable then.

@hermann88

This comment has been minimized.

Copy link
Author

hermann88 commented Oct 15, 2015

true!

@janxb

This comment has been minimized.

Copy link

janxb commented Nov 5, 2015

Very unpolite behavior, just closing all requests while not giving an definite answer..

@hermann88

This comment has been minimized.

Copy link
Author

hermann88 commented Nov 26, 2015

true true

@My1

This comment has been minimized.

Copy link

My1 commented Nov 30, 2015

lol just closing without appropriate reason...

@RainLoop RainLoop reopened this Nov 30, 2015

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented Feb 8, 2016

This feature is really missing. Currently as it is implemented it is not in any way better than Mailvelope that does it in your browser as an addon, but Mailvelope at least has some good options to manage my keys at least. And it supports encrypted HTML mails as well, something Rainloop misses as well.

Anyway, if the key is password protected, then storing the keys on my own server would be in some way safe. That way I could use Rainloop for PGP encryption on different devices without screwing around with addons on every machine (maybe not even available) and copying around keys.

@sumptum

This comment has been minimized.

Copy link

sumptum commented Mar 10, 2016

Bump!
As others have said, I trust my own server with the keys (far more than another PC's clipboard). As it stands, I'm encrypting my public / private key pairs and carrying them round on a USB, or SSH-ing back to my home PC to check mail - server-side keys would give us a solution for easily sending / opening PGP email via any web browser or mobile device on the fly which would be very useful indeed

@My1

This comment has been minimized.

Copy link

My1 commented Mar 11, 2016

I agree with @sumptum on a self-managed server, server-side keys are a nice Idea, but the user needs to know whether the key is stored server or client side.

also a benefit of serverside keys is that you dont need some stupid javascript for encryption making this work better with bad connections, because if CSS breaks, it's ugly but it works, but if js breaks, it usually doesnt work and the user cannot even realize that beforehand (you dont even want to know how often I got a broken submit button in forums on my phone just because the js didnt load properly).

@maderluc

This comment has been minimized.

Copy link

maderluc commented May 4, 2016

im running a puplic mailserver with rainloop and im not sure if its a good solution to put the privat PGP key of every user onto the server ! what if the server gets hacked! well the private keys are encrypted but stil..... BUT there must be a better way ! i just lost my pgp key because (forgot to backup ) my PC crached!

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented May 24, 2016

Roundcube in its newest version has exactly this feature. Here is a link to it: https://kolabian.wordpress.com/2015/10/13/enigma-plugin-pgp-encryption/

@esroyo

This comment has been minimized.

Copy link
Contributor

esroyo commented May 24, 2016

I think server side encryption needs a lot of work and is very far from the client-side-js current take in RainLoop. However there could be a third way using remoteStorage.js (they already have a module for pgp).

In that way, the client side javascript would connect to the remote storage server and retrieve the keys to use in the front-end. If you only trust your own server, then you still could install a remoteStorage service in it alongside with RainLoop. It might seem a lot of overhead, but the truth is that it would require minimal changes in the current RainLoop source.

@RainLoop what do you think about this possibility? I'd be interested in coding it for myself.

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented May 24, 2016

I am running it inside Owncloud as a plugin and it already integrates some things, maybe this could be an approach?

Link here:

https://apps.owncloud.com/content/show.php/RainLoop+Webmail?content=165254

Anyway, the Roundcube plugin relies on GnuPG to do the encryption stuff, which is proven and reliable. If you trust a server to store your keys, you probably can install stuff on it as well. If somebody else manages it, client side encryption using Openpgp.js/Mailvelope is probably a better choice.

@esroyo

This comment has been minimized.

Copy link
Contributor

esroyo commented May 28, 2016

@e-alfred Seems ownCloud doesn't provide support for remoteStorage anymore. Installing as separate service is recommended instead. So it wouldn't make any diff to a regular RainLoop install.

I don't see any excitement around the remoteStorage idea, but still considering it for myself 😝

@dnut

This comment has been minimized.

Copy link

dnut commented Jun 25, 2016

This is the one big downside in my mind of rainloop compared to roundcube. I don't understand why this would be implemented client side. Private keys can be protected with symmetric encryption. Have all encryption and decryption happen on the client side and save encrypted private keys on the server. The server can never know your private key if it is only decrypted by the client. This is hardly a security risk and would make this feature actually useable, which it currently is not.

@DamienR

This comment has been minimized.

Copy link

DamienR commented Jul 19, 2016

@dnut has hit the nail on the head here, rather than store these keys on the browser there is absolutley no reason these keys can't be encrypted and stored on the server. As it stands, Roundcube now has a better PGP implementation and I'm almost tempted to go back - but its user interface is still stuck in 2006.

@zeigerpuppy

This comment has been minimized.

Copy link

zeigerpuppy commented Jul 25, 2016

I agree that for most users storing keys (password protected) on the server will be better than in the browser storage. The expected behaviour when you "import keys" is that they will persist between browsers. Also, it should be explicit that the current mechanism is a risk on a public computer (eg. internet cafe).

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented Dec 2, 2016

This is really important, although the issue should be renamed ^^

@PoGo606

This comment has been minimized.

Copy link

PoGo606 commented Jan 3, 2017

The keys should be stored on server side while keeping the operations on client side.
I don't wan't to keep importing them as I delete my cache or switch to a new computer/device.

@zeigerpuppy

This comment has been minimized.

Copy link

zeigerpuppy commented Jan 3, 2017

There are trade-offs here. If you store the keys server-side then you need to trust that the server is secure and that they won't hand over your keys to a third party. Really, I wouldn't call that end-to-end encryption any more (more like server-to-end encryption!).
But I agree that for a lot of users having the option of "trust the server" may make workflows easier and perhaps even more secure (is local key storage more secure for most users?). So I think the default behaviour is good but needs to be documented better and an option should be allowed for server-side storage too.
By the way, the main devs have been very quiet lately, do you think this project may be dead?

@dnut

This comment has been minimized.

Copy link

dnut commented Jan 3, 2017

@zeigerpuppy If keys are encrypted client side before being sent to the server, you don't have to trust the server any more than with the current behavior. Sure, you have to trust that the javascript being run locally doesn't expose your unencrypted key, but that's equally true for any key managing web app, including the current version of RainLoop.

@zeigerpuppy

This comment has been minimized.

Copy link

zeigerpuppy commented Jan 4, 2017

I see your point, I guess whenever keys cross the browser divide and are decrypted they could be exfiltrated by rogue javascript.
I agree storing the keys encrypted server-side would be a reasonable compromise as long as decryption happens client side.

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented Mar 29, 2017

@unic0rn I use 64 character alphanumeric passwords. That is 64^64 possible passwords. Even an adversary that is able to try out a billion of them per second would take up to a googol years, to try out all of those. Because of them probably finding it after half of the passwords or so, let's say half a googol years. that is still a 5 with 99 zeros after it, longer than the universe existed and probably longer than it will exist. Even for people with less secure passwords, if they are nerdy enough to use gpg, their passwords are probably safe enough, so that they are not cracked faster than the rsa keys they rely on will be by quantum computing.

@unic0rn

This comment has been minimized.

Copy link

unic0rn commented Mar 29, 2017

people are lazy, and if you haven't noticed - RainLoop makes it possible for people to start using PGP without knowing a single bit of technicalities, other than "others need my public key, i need theirs". they may be unaware of the existence of key signing, revokation and tons of other things, and you expect them to know the risk of attack on their private key depending on their password complexity?

for the average user the change you're proposing would be dangerous, because the average user of RainLoop probably knows far less about PGP than we do. do you want to sacrifice their security for your own convenience? if so, there's a fork button somewhere around here.

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented Mar 29, 2017

Well, then tell the average user that using a weak password makes the encryption less efficient and be done with it. The average user won't go through the trouble of externally saving their pgp key and importing it, should firefox screw up the local storage again or something (has happened a few times to me, with different browsers) either, so saving it on the server is still more convenient for them ;)

To be honest though, I couldn't care less, since I only use RainLoop for sieve anymore, since I've moved to using my yubikey for signing/decrypting mails, since RainLoop doesn't support that (yet), see #1257.

@sumptum

This comment has been minimized.

Copy link

sumptum commented Mar 29, 2017

@unic0rn I'd not really considered it from that perspective, and it's definitely good to think of general security for something like this since as you say security shouldn't be sacrificed for the majority for the convenience of a few of us.

The way I see it, a toggleable option in the PGP settings would mitigate any accidental or unwitting reduction in security as 'lazy users' wouldn't be poking around and it could be off by default. In fact that raises an interesting question - how does the average Rainloop user transfer their keys at the moment? They probably put them on a USB or cloud storage or... Something. I guess some people use encrypted containers and volatile browser sessions but for most, especially those who don't know as much about PGP but are starting to use it, I would expect there's already several vulnerabilities where private key management is concerned. I think that server side key storage would aid in reducing the number of points at which keys can be intercepted, especially if the keys are encrypted at rest and in transit, and the feature only available over SSL (like key generation is, if I remember correctly). Perhaps a password manager like LastPass is a good solution, but then it would need to be installed on every computer and mobile device, which sort of defeats the purpose of an available-anywhere webmail client.

You're right saying a password is easier to brute force, but a feature like this isn't intended to make private keys publicly accessible and brute force-able, quite the opposite. Unless the server hosts were evil... in which case fair enough, but maybe hide the switch behind a lot of warnings and advice on choosing a secure hosting solution :)

@unic0rn

This comment has been minimized.

Copy link

unic0rn commented Mar 29, 2017

from what i've noticed, devs here are against adding new options in general, unless unavoidable, probably to avoid confusion for end users. it's supposed to be simple.

so the most likely assumption is that end user won't understand a word from the explanation about server security, secret key security and so on. they may copy them to a text file - i suppose that's the most likely scenario. i'm not sure about things like chrome sync - if chrome syncs that local storage (depends on RainLoop, or at least it should), then that's a possible issue - depending how much you trust google and their sync data encryption, assuming you've used that.

also, i'm not saying storing keys on a RainLoop server is a bad idea - but it should be done in the most secure way possible. so the question should be, what's the best way to encrypt those keys so they'll be basically untouchable, without complicating things for the end user. some custom encryption linked to the 2FA and keys stored on the server with a timestamp? should be possible.

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented Mar 30, 2017

Also, just to be clear, if you don't trust the server, you can't trust rainloop anyway, since they could just send you malicious javascript that sends them the decrypted pgp key ;)

@unic0rn

This comment has been minimized.

Copy link

unic0rn commented Mar 30, 2017

if the admin screws up permissions, someone could get the keys without having write access to the RainLoop folder. not in the same ballpark.

secret keys are secret, period.

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented Mar 30, 2017

They could get read access to encrypted keys ;)
The secret keys are still secret, period.

@unic0rn

This comment has been minimized.

Copy link

unic0rn commented Mar 31, 2017

instead of trolling, focus on finding a reasonable solution to the problem - how should those keys be encrypted. you were the one talking about trusting the server, so i've pointed out it's not all black and white when it comes to server-side security. it's obvious that when you can't trust the admin, using the server is pointless - but there are other scenarios as the one i've shown.

in the end, it's a matter of "how secure are my keys" - you're not supposed to put them in places that aren't under your own control, so to do so, they have to be encrypted.

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented Mar 31, 2017

Damn, I was sure it was you who is trolling 🤣

The thing is, as long as you use reasonably secure password, storing the key on the server is perfectly fine. And the question, how the keys should be encrypted, is already solved by pgp, because the keys already are encrypted when putting a passphrase on them. Preventing people from using weak passwords would be possible by analyzing the password they entered before sending the key to the server, and requiring them to enter a stronger password.

Just as a question, do you now keybase.io? Their model for easy crypto using pgp involves storing the private key on their server ;)

@sumptum

This comment has been minimized.

Copy link

sumptum commented Mar 31, 2017

It couldn't hurt to encrypt them again, although they are already encrypted. Two strong unique passwords would help protect everything. I think ultimately a password is the best kind of security you can have in this scenario, but increasing the number of them (one for a key container, one on the private key already) and the cost for the function (I don't mind waiting 20s or so to decrypt it) would keep things secure. Even considering Moore's Law and the top500 computers working together, a 30+ character alphanumeric password with symbols and both cases would take over a century to crack. Tag on a second equally strong password and you're looking at nearly three centuries

@madpsy

This comment has been minimized.

Copy link

madpsy commented Mar 31, 2017

Another option is to use something like Mailvelope (https://www.mailvelope.com/en/) therefore keeping the key on the client but in a more persistent state than browser cache.

For server side, as has been discussed over and over again, a passphrase should suffice. If a user is choosing to use PGP they should have the common sense to realise a strong passphrase is important. If they don't then unlucky for them.

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented Mar 31, 2017

About keeping it client side, but persistent, using the installed gpg binary, if available not only enables yubikeys and such, but also protects the user from rogue javascript and keeps the keys more persistent than in the browser cache.

@jeaye

This comment has been minimized.

Copy link

jeaye commented Apr 22, 2017

I'd put my vote in for passphrase-protected server-side keys, please! I had just setup RainLoop up, for my wife (who uses it on mobile and desktop), and I'm awfully bummed that I can't have her easily use PGP in a portable manner.

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented Apr 26, 2017

To make it more secure access to the keys on the server could be secured with 2FA, for example. That would make it harder for if an attacker only knows the password.

Additionally, a notification could be shown if somebody tried to access the keys from a previously unknown location with detailed information like IP, country, browser UA and so on.

@soxhi8

This comment has been minimized.

Copy link

soxhi8 commented May 5, 2017

Anything new to this? I have got a server with not many users and would like to use it as a portable pgp-solution, to not store my secret keys on my vulnerable minor devices. Storing them in one, well secured place is much safer than spreading the keys across all my devices.

@jcgruenhage

This comment has been minimized.

Copy link

jcgruenhage commented May 5, 2017

Well, they will need to be cached on your devices..

@soxhi8

This comment has been minimized.

Copy link

soxhi8 commented May 5, 2017

Well, you name the problem right there.

@Jaxom99

This comment has been minimized.

Copy link

Jaxom99 commented Oct 10, 2017

Have you guys seen this plugin ? https://github.com/chtixof/pgpback_ynh
It might be a working solution for this use-case, so I reference it just in case.

@janemba

This comment has been minimized.

Copy link

janemba commented Oct 16, 2017

Hi,

Well, I'm using multiple browsers on multiple machines so PGP is a problem. The fact is developers are right. Private keys should be private and not stored at server-side. But, that functionality exists and it is named HSM. But that's not what we want.

I think the main issue is the use of a webmail with a component that can't be shared. You can use a webmail anywhere at any time with any devices connected to internet. So to make it easy to use PGP, people tend to think to online stuff. Solution like Enigmail plugin for Thunderbird is ideal as usually that mail client is installed on your main workstations/laptops so you can store your keys at client-side.

So, what kind of solution respect the usage of PGP (private storage for private key) and allow an easy use of it with all connected devices ?

  • For people owning a private cloud, we can easily think of a storage using HTTP(S) protocol (so it can be used with a web server) so the private key is accessible through a link. I'm thinking of this setting as per-user only. I mean each user as its own link.
  • Using an external device like a USB key. However, we can say bye bye to mobile.
  • Reading the private keys through a QR-Code. This means you have to copy that QR-code in all your devices. Well, a file is a file so why not copy the private key directly ? Well, ...

That's the only idea I got and maybe they are all wrong but finding a solution for storing stuff at client-side and make it accessible for multiple devices is not an easy task.

Jaxom99
Have you guys seen this plugin ? https://github.com/chtixof/pgpback_ynh
It might be a working solution for this use-case, so I reference it just in case.

There is no explanation about how it works. And it seems we need to install their YunoHost stuff.

Cheers

@qirtaiba

This comment has been minimized.

Copy link

qirtaiba commented Oct 16, 2017

You don't need to say bye bye to mobile if you use a Yubikey to store the key. Besides its USB interface Yubikey has RFC and works with mobile. This is supported by OpenKeychain on Android.

@soxhi8

This comment has been minimized.

Copy link

soxhi8 commented Oct 16, 2017

As much as I would like to, most of my users don't even know the term Yubikey.
​​​​​​​They need a simple, yet encrypted, better than nothing solution, not an industrial standard. Would use different software, if that standard was needed.

@DamienR

This comment has been minimized.

Copy link

DamienR commented Oct 16, 2017

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented Oct 16, 2017

@Luticus

This comment has been minimized.

Copy link

Luticus commented Jan 2, 2018

Why don't we just use encrypted private keys with a password unlock? This way the key can be stored on the server and cannot be used until the password is entered by the user. I think that's a better idea than people using unencrypted email because it is way too aggravating to have different email messages only able to be opened on certain devices! Or worse, users start emailing their private keys to themselves to try and get their keys installed on all their devices. This is literally why I don't use PGP in my email, which is completely frustrating because I absolutely want to. The whole idea behind a web client is that it can be used no matter what device you're on! Why then would we limit that by making it frustratingly difficult to use it on more than one device? This is the single "must fix" feature in Rainloop. Also it would be super nice if the client finally supported S/MIME and MIME attachment style PGP.

@Leopere

This comment has been minimized.

Copy link

Leopere commented Mar 6, 2018

@RainLoop You can use PBKDF2 to store the keys encrypted by the user's password at login. It's what most cloud-based password managers use to save your passwords in the cloud so why not use it to store your GPG keys. This way RainLoop can assert that only the person who owns that account has rights to the GPG keys.

You might have to do some fan-dangling if the endpoint account associated with the RainLoop account has changed its password upstream but you could just add a function to log into the PBKDF2 container and update the password.

Part of the only reason I was interested in RainLoop was the fact that I could have a webmail that I didn't have to worry about having to carry my GPG keys everywhere. If I'd have known this isn't something supported by RainLoop I probably wouldn't have gone into this whole endeavor. This thing basically being completely incompatible with Incognito mode is kind of a pain.

Hell even with PBKDF2 you could technically mimic the functionality of ProtonMail wherein you could encrypt emails that are outgoing to other people in a way where they could grab the email's contents from RainLoop maybe somehow using a pre-shared password.

@Rudi9719

This comment has been minimized.

Copy link

Rudi9719 commented Feb 4, 2019

Just found out about this (I'm gonna call it a bug) bug today. My job was trying to implement Rainloop as our webmail, and we use PGP. Public PGP keys are just that, public. They should be safe to store server-side. Private PGP keys, I understand. However as they're armoured I no longer understand why they shouldn't/aren't stored server side. Has there been any updates on this bug now, in 2019?

@Leopere

This comment has been minimized.

Copy link

Leopere commented Feb 4, 2019

@Rudi9719

The last time I brought this up with anyone they said, GPG keys shouldn't be stored serverside. However, Protonmail does this just fine they just use zero-knowledge encrypted containers. The place this gets complex is when the user wants to change their GPG passwords you'd have to create a client-side method for changing not only the GPG key security but also change the PBKDF2 container to reflect the password changes.

https://en.wikipedia.org/wiki/List_of_PBKDF2_implementations

@Rudi9719

This comment has been minimized.

Copy link

Rudi9719 commented Feb 4, 2019

@Leopere is Protonmail available within nextcloud? We use a Univention Domain, and chose Rainloop as we are able to install it right inside of our NextCloud container.

@Leopere

This comment has been minimized.

Copy link

Leopere commented Feb 5, 2019

Sorry @Rudi9719 I wasn't suggesting Protonmail is something you can self host unfortunately its entirely a closed source gmail alternative where they host everything however they do support GPG etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment