[Question] Database Not Encrypted

[d9s3mKfY6QeZrcTQf97nkaLDMtnzpxJHQo4JkHM]

I was taking a look at SimpleLogin's Privacy Policy and Security page and there was something that caught my eye, so I would like to get some clarification on the matter as I think this is of concern for the entire community.

In regards to how data is stored on SL's database, it says on the Security page, I quote:

The database is using Postgresql, is encrypted at rest and backed up everyday

and it also says on the Privacy Policy:

The database backups are also encrypted. Most data are not encrypted while they live in our database (since it needs to be ready to send to you when you need it), but we go to great lengths to secure your data at rest.

My question is... What do you mean with "Most Data are NOT encrypted" and what is the data that IS in fact encrypted?

The reason of my concern is that it appears like the data is only encrypted at rest, which is great if an attacker were to take over the server where the database is in, but it also raises a Huge concern...

If the data is only encrypted at rest, it means that any Team Member that has access to the database can see, as you said, "Most Data"... So they could probably see everything that I'm able to see when I log in... They can see the emails associated to my account, they can see my domains, the people that has sent me emails and the people I have emailed to, etc etc...

In fact, it seems like staff has the ability to log into my account if they want:

If at any point we need to access your account to help you with a Support case, we will ask for your consent before proceeding.

I know you say you will ask for consent, but internally, when there are more team members, it will be impossible to trust and control everyone... This is a huge vulnerability as it can be exploited using Social Engineering very easily.

This is a Huge privacy concern even though you say that you promise not to look without permission... Simply put, it's like saying to a stranger "Leave your door always open while you are taking a shower, I'm standing here right in front of the door, but I promise not to look"

This is not a good practice and it defeats the privacy purpose of Simple Login.

If sensitive user data were encrypted, yes, you probably would have access to some things, but not to my private information... My private information should be encrypted in your servers using a key derivated from my account's password/email/etc. Not only encrypted at rest, but also on a field level so that even if someone logs into the database they won't be able to see it.

Anonaddy does this and I think it's the right thing to do... As SimpleLogin's team grows it is a huge point of failure to place all your trust in people thinking they won't access that data... Even if only 1 person has access to that data, it still doesn't make sense, as it defeats the whole purpose of using a Privacy Oriented service and it is not a good practice.

[nguyenkims]

My question is... What do you mean with "Most Data are NOT encrypted" and what is the data that IS in fact encrypted?

This is rather on the case by case basics. For example, the account password is encrypted (hashed and salted). We try to have more data encrypted and in the next versions, other data fields can be encrypted.

If the data is only encrypted at rest, it means that any Team Member that has access to the database can see, as you said, "Most Data"... So they could probably see everything that I'm able to see when I log in... They can see the emails associated to my account, they can see my domains, the people that has sent me emails and the people I have emailed to, etc etc...

Only a small number of developers with the right permission can have access to the database. This access is needed when we need to investigate an issue. Unfortunately there's no way around it, SimpleLogin isn't end to end encrypted.

[d9s3mKfY6QeZrcTQf97nkaLDMtnzpxJHQo4JkHM]

@nguyenkims

This is rather on the case by case basics. For example, the account password is encrypted (hashed and salted). We try to have more data encrypted and in the next versions, other data fields can be encrypted.

Is the account password the only thing that is encrypted? What are some of the other things that are encrypted. I think, as a user, it is important for me to know as that way I can choose what sort of information I would like to share or at least, I can be aware of what information is not encrypted in your servers.

Only a small number of developers with the right permission can have access to the database. This access is needed when we need to investigate an issue. Unfortunately there's no way around it, SimpleLogin isn't end to end encrypted.

As I understand, this isn't something that is done frequently. Then a good idea would be to have a way for us, the users, to, when creating a support ticket (or even in our settings page we could have a button for that), to optionally (or not) agree to decrypt our data within your servers temporarily so that our issue can be resolved more quickly and then when the ticket is closed (Or when we change that option again, if it's an option within our settings page), have our keys be locally derived again automatically and our sensitive data encrypted again as well.

Understanding that if we do not do that in a support situation, our ticket might take longer to be solved as, depending on the issue, you might actually need that data to be decrypted.

In such case, you could ask us if we want to do it and if we don't, then just close the ticket as nothing can be actually solved and the team would be wasting their time... I mean, you could even enforce decryption on a support ticket situation, but also, making it optional might be a good thing as well.

[d9s3mKfY6QeZrcTQf97nkaLDMtnzpxJHQo4JkHM]

@nguyenkims

I understand a full E2EE implementation would be a LOT of effort and would take time to properly implement, but I just wanted to put this out there as something that needs to be addressed and I think is of great importance to the community and could also potentially be a great feature for SL as ProtonMail is End-to-End Encrypted and SL is now working with Proton

Is it possible to add this full E2EE implementation to the Roadmap?

[salixh5]

I'm not working on SimpleLogin and don't belong to them nor to Proton, but just from a technical standpoint: Let's say an email comes in. The email handler somehow needs to lookup where to send it to. If that data would be encrypted with a key derived from someone's password, then that's just not possible. And other than that, the amount of data that SimpleLogin stores in the first place isn't actually that big. Maybe storing the descriptions for aliases in encrypted form might be reasonable to think about, but anything else? Not really, right?

The same goes for Proton: sure, the email content itself is encrypted. Many other things aren't, notably mail headers (including the subject), because that's impractical and not standardized. Then of course everything related to billing, which email addresses belong to you (because otherwise same problem as above would arise), mail filters, folders/labels, access logs if enabled, session information...

I don't see a huge difference between them and really, I also don't see a lot of information where encrypting would be feasible. Now, encryption at rest and encryption of backups is of course something else, and totally should be and is apparently done.

[d9s3mKfY6QeZrcTQf97nkaLDMtnzpxJHQo4JkHM]

@jeifour

You're making a good point, and yes... While data will always need to be decrypted in order for it to be usable, what I'm talking about is when it's actually stored.

So, lets take that example, let's say that

... an email comes in. The email handler somehow needs to lookup where to send it to. If that data would be encrypted with a key derived from someone's password, then that's just not possible.

By all means, that is how it is, I 100% agree. But the problem is what happens After forwarding... After SL forwards your email, some information is then stored on SimpleLogin's Database on their servers.

In fact, for each one of my aliases, there is a log of all the email addresses (inbound and outbound) that I have communicated with through that alias, along with a timestamp.

Basically, if someone at SimpleLogin wants to see my communication history through an Alias, they can do it...

Same thing for my Domains. Same thing for my Alias Descriptions. Same thing for my Mailboxes. Same thing for my directories, though specifically for my directories, it makes sense for them to not be 100% encrypted as there is a feature to create aliases on the fly... But if I don't want that feature, it should still be an option for me as a user.

That's my point, at least, we should have sensitive data being encrypted.

They promise not to peek though and this might be true, I actually think the team means well and this is a great product... But it's not perfect and they are not perfect either, and this practice creates a huge risk of vulnerabilities through Social Engineering.

There are a lot of hackers right now and now that SimpleLogin is part of Proton, even though it's a great merger/acquisition they are also putting a big target on their backs, so it's important to start thinking ahead and not wait until there is an "unexpected" data breach.

Not preparing is preparing for failure.

SimpleLogin is a good service, but All of those things would make SL not very private by design... Hence, not a privacy oriented service... And potentially might allow for my aliases (Even random generated aliases) to be traceable back to me which, again, is not private by design... Heck in some cases it could be more of a problem than a solution as lots of data is being centralized in SL's servers.

Unless that data is encrypted... That's why I ask because I don't really know what is encrypted and what isn't... All I know is what they say:

Most data are not encrypted while they live in our database

But still, they not only need to be encrypted, they shouldn't have the ability to decrypt it themselves without my password. This way, if there was ever a data breach, we, the users don't really need to worry about much because as long as the hackers don't have my password, they have nothing.

Because, as SL say in their privacy policy, it is my data, not theirs.

But again... I don't know for sure how it's being handled, so that's why I ask to know what is being encrypted and what isn't.

[salixh5]

You make a lot of good points, I agree that certainly it'd good to think about every type of data that is recorded and evaluate if it could be potentially stored fully encrypted like that.

As I'm also privacy-conscious, I have taken to self-hosting SimpleLogin. I still maintain a Premium subscription to support the project's further development and of course I trust them to mean well, but ultimately to really make sure all the data is handled appropriately self-hosting is a very good option imo. Maybe something that you want to look into.

[nguyenkims]

As @jeifour mentions, email metadata are not encrypted even if the email content is protected with PGP. SimpleLogin needs to be able to read the metadata in order to forward emails to the right destination so end to end encryption wouldn't apply here. I'd suggest to self host SimpleLogin to have a total control over your data.

[d9s3mKfY6QeZrcTQf97nkaLDMtnzpxJHQo4JkHM]

@nguyenkims I feel like we're missing the point here...

Everybody knows PGP does not encrypt email headers, and also you need to be able to read the metadata in order to forward...

But that's never been the point. The point is what happens after that... When you save some of that data in your database to provide in-app reports. What is saved and how is it saved... So:

Question #1. What data is stored encrypted ? (And I don't mean at rest, but on a field level)

When I say End to End Encryption, I don't mean to encrypt email metadata the way you are describing. I described what I mean in my previous messages and it's not that.

Question #2. Some data Can be end to end encrypted, like for example:

• My Domains
• Alias Descriptions
• My Mailboxes
• Email Sender History per Alias

Is it possible to add this to the roadmap? Note: Perhaps Mailboxes and Domains are not E2EE'able but at least keep both encrypted in a database with a key SL knows but it's stored on a secrets manager and hashed on a separate field for easier hash-based queries then you find, you decrypt, you forward

Question #3. Can Associated Aliases (Random and UUID aliases) using your domain be traced back to my account?

And yes, I know self host is an option but all I'm asking is that you clarify your privacy policy and tell us what data is encrypted on a field level and if that data be End to End Encrypted... I'm also providing an idea of a solution for that case.

[mainrs]

I do think that you make a fair point about the message history, alias descriptions. If I understand it correctly it is not possible to e2ee mailboxes since they are used to know to which email to forward to. And domains cannot be encrypted as well since emails created under that domain need to be forwarded as well.

Someone already mentioned that it is possible to extend the fields that are encrypted in a future update. So that might be something that could be considered. I definitely would like to see this getting implemented.

[nguyenkims]

I think the field that can be E2EE in a near term is alias note as it isn't used in the email forwarding part. The current search is based on Postgres index that requires the note to be in plain text though so this can be a challenge to do that on the frontend. The rest needs to be readable by SimpleLogin code so we can properly forward the emails.

[Jayrgo]

I just read this issue and then readed https://simplelogin.io/privacy/. I stopped reading at

We also give you the option to add a name and profile picture that displays in our products, but we do not normally look at or access this information.

What does normally mean? Are these informations encrypted, if yes with what? When do you access this data, and why?

[nguyenkims]

We also give you the option to add a name and profile picture that displays in our products, but we do not normally look at or access this information.

@Jayrgo this info is just aesthetics so you can have your profile picture displayed on SL. This info isn't encrypted. You can also use the display name and profile picture the "sign in with SimpleLogin" service, more info on https://simplelogin.io/developer/.