Add Cryptee to Productivity section (worth mentioning) #629

2018-11-26T16:27:09Z

ghost commented

2018-11-26 16:27:09 +00:00

(Migrated from github.com)

Description

Adding crypt.ee to worth mentioning section. Resolves #502

HTML Preview

http://htmlpreview.github.io/?https://github.com/Avizini/privacytools.io/blob/master/index.html

## Description Adding crypt.ee to worth mentioning section. Resolves #502 ### HTML Preview http://htmlpreview.github.io/?https://github.com/Avizini/privacytools.io/blob/master/index.html

gjhklfdsa commented

2018-11-27 23:45:37 +00:00

(Migrated from github.com)

Relevant Information: https://github.com/cryptee/web-client/issues/10
Not sure if Cryptee is eligible.
Perhaps @privacytoolsIO can give more info?

Relevant Information: https://github.com/cryptee/web-client/issues/10 Not sure if Cryptee is eligible. Perhaps @privacytoolsIO can give more info?

johnozbay commented

2018-11-28 00:30:31 +00:00

(Migrated from github.com)

Hey @gjhklfdsa 👋🏻

As far as I was aware, having an open-source backend was not a requirement to be enlisted on privacytools. If so Protonmail and Tutanota wouldn't be qualified either, – two names off the top of my head that don't have their backend open source. I'm sure there's more examples, and I'd be happy to be corrected here –

With my heartfelt thanks, and deepest respect to this community 🙏🏻
You guys are fantastic! ✌🏻

All the best,
J

Hey @gjhklfdsa 👋🏻 As far as I was aware, having an open-source backend was not a requirement to be enlisted on privacytools. If so Protonmail and Tutanota wouldn't be qualified either, – two names off the top of my head that don't have their backend open source. I'm sure there's more examples, and I'd be happy to be corrected here – With my heartfelt thanks, and deepest respect to this community 🙏🏻 You guys are fantastic! ✌🏻 All the best, J

ghost commented

2018-12-15 16:49:15 +00:00

(Migrated from github.com)

Is the encryption done on the frontend?

ghost commented

2018-12-15 16:57:02 +00:00

(Migrated from github.com)

It is.

ghost commented

2018-12-15 16:58:04 +00:00

(Migrated from github.com)

@johnozbay Great job, I'll try crypt.ee now, it looks really nice.

BTW (re: open-source), if you ever want to implement some features for a paid plan instead of just more space, I guess keeping the frontend open source and simply permitting these features on the backend will work?

@johnozbay Great job, I'll try crypt.ee now, it looks really nice. BTW (re: open-source), if you ever want to implement some features for a paid plan instead of just more space, I guess keeping the frontend open source and simply permitting these features on the backend will work?

❤️ 1

johnozbay commented

2018-12-15 16:58:36 +00:00

(Migrated from github.com)

@Shifterovich it is.
Everything, from contents of the docs/photos/files to tags, from file-titles to photo thumbnails, (which are resized/generated client-side), encrypted and uploaded alongside encrypted originals.

@Shifterovich it is. Everything, from contents of the docs/photos/files to tags, from file-titles to photo thumbnails, (which are resized/generated client-side), encrypted and uploaded alongside encrypted originals.

ghost commented

2018-12-15 16:59:57 +00:00

(Migrated from github.com)

Do you plan on building something like an Electron app or will it always be a progressive web app?

ghost commented

2018-12-15 17:02:04 +00:00

(Migrated from github.com)

@gjhklfdsa We don't really care about the backend when the encryption is verifiably done on the frontend. Sure, it's a little problematic with web apps as the website can send you malicious JS (this is an argument against ProtonMail), which is why having the app (frontend) stored locally instead of fetching it from the server is ideal.

ghost commented

2018-12-15 17:06:21 +00:00

(Migrated from github.com)

Also, I have a question about the encryption design. It requires that the encryption password is different from the account password. While it's good to have different passwords, it shouldn't be mandatory. ProtonMail can ask you for one password or two passwords, depending on how you configure it.

Does it derive a key from the password using some PBKDF or does it generate a key encrypted with my password (or a key derived from my password) and use that for encrypting the data? Similar to how PM frontend uses your password to decrypt your PGP private key stored on their server.

Also, I have a question about the encryption design. It requires that the encryption password is different from the account password. While it's good to have different passwords, it shouldn't be mandatory. ProtonMail can ask you for one password or two passwords, depending on how you configure it. Does it derive a key from the password using some PBKDF or does it generate a key encrypted with my password (or a key derived from my password) and use that for encrypting the data? Similar to how PM frontend uses your password to decrypt your PGP private key stored on their server.

johnozbay commented

2018-12-15 17:07:35 +00:00

(Migrated from github.com)

@Shifterovich Many thanks! It is an honor to hear! 🙏🏻

Business Plan / Paid Features
The long term plan is to make it free for individuals, and paid for businesses.
There's some fantastic business-only collab features in the pipeline.
This way I can provide a free privacy service for everyone. (fingers crossed)
But backup plan is to still only charge for storage, and keep adding more apps/features.
Perhaps I'm being an idealist, but I want to price things fairly, and not per-feature.
This way it's not as big of a problem to keep things on the client-side, and the community can benefit from the learnings & the code.

Desktop
I've been thoroughly exploring how I can make a native desktop client to reduce browser dependencies / incompatibilities. Biggest issue right now is that most users have canvas-blocker extensions blocking access to canvas (which prevents generation of photo thumbnails on client-side before encryption & upload) and things like DOMRect, which Cryptee utilizes to add photo thumbnails to virtual dom, and decrypt thumbnails before they enter the viewport to achieve 60fps scroll + decryption. It works great with browsers that allows access to canvas, and some features fail if these are blocked.

While electron is the ideal candidate, its Chromium updates are behind, and it could one day cause security problems. Exploring how I can overcome some of these, or if I should just create my own native-ish wrappers for platforms.

So currently PWA, but hoping to have a solution to this in the very near future.

Thanks again 🙏🏻

@Shifterovich Many thanks! It is an honor to hear! 🙏🏻 **Business Plan / Paid Features** The long term plan is to make it free for individuals, and paid for businesses. There's some fantastic business-only collab features in the pipeline. This way I can provide a free privacy service for everyone. (fingers crossed) But backup plan is to still only charge for storage, and keep adding more apps/features. Perhaps I'm being an idealist, but I want to price things fairly, and not per-feature. This way it's not as big of a problem to keep things on the client-side, and the community can benefit from the learnings & the code. **Desktop** I've been thoroughly exploring how I can make a native desktop client to reduce browser dependencies / incompatibilities. Biggest issue right now is that most users have canvas-blocker extensions blocking access to canvas (which prevents generation of photo thumbnails on client-side before encryption & upload) and things like DOMRect, which Cryptee utilizes to add photo thumbnails to virtual dom, and decrypt thumbnails before they enter the viewport to achieve 60fps scroll + decryption. It works great with browsers that allows access to canvas, and some features fail if these are blocked. While electron is the ideal candidate, its Chromium updates are behind, and it could one day cause security problems. Exploring how I can overcome some of these, or if I should just create my own native-ish wrappers for platforms. So currently PWA, but hoping to have a solution to this in the very near future. Thanks again 🙏🏻

ghost commented

2018-12-15 17:11:59 +00:00

(Migrated from github.com)

Also, do you encrypt the password and the encryption key on the frontend before sending it to the server?

As I was signing up I thought that all data should encrypted on the frontend -- including the password.

This isn't a huge security feature, but if the backend is compromised, it at least can't see the user's password (and encryption key) in plaintext.

Also, do you encrypt the password and the encryption key on the frontend before sending it to the server? As I was signing up I thought that all data should encrypted on the frontend -- **including the password**. This isn't a huge security feature, but if the backend is compromised, it at least can't see the user's password (and encryption key) in plaintext.

johnozbay commented

2018-12-15 18:03:38 +00:00

(Migrated from github.com)

@Shifterovich

Single Password
Part of the reason why I haven't looked into implementing the single-password mechanism PM-and-alikes are using is that my aim is to make Cryptee a simple service even my mom can use, without having to stop using her gmail. 😅

You can log in to Cryptee using your google account + a separate encryption key. And while I did receive a some criticism for allowing this, numbers tell an interesting story. Currently ~65% of all users are signing up with their gmail accounts + a separate encryption key. Based on user feedback, I can confidently say that current users love that this exists, since this flow allows them to keep their gmail (for whatever reason they may wish/need to keep it) and only memorize an encryption key for Cryptee.
(an example I commonly hear is that they have a corporate G-suite account, and they wish to have a private corner for themselves on the internet with it)

That being said, there's nothing stopping me from implementing a SRP / single-key system for logins like PM does. It's more so a business decision to launch fast, add new features fast, then slowly dive into these features. I am planning on adding SRP + Hardware FIDO 2FA like yubico in the near future.

As for passwords / key handling on frontend
Passwords are encrypted using scrypt, a key derivation function that was originally developed for use in the Tarsnap online backup system and is designed to be far more secure against hardware brute-force attacks than alternative functions such as PBKDF2 or bcrypt. (according to the project's authors) And Cryptee uses both hashes and salt.

As for the encryption key,

A strong content encryption key (contentKey) is generated client side using browsers' own crypto module on signup. Which is what all the user data will be encrypted/decrypted with.

This contentKey is then encrypted using the hashed user-chosen encryption key (userKey), finally the resulting encrypted contentKey is sent to server.

So when users login, they receive the encrypted contentKey from the server, decrypt this with their key (userKey) in browser memory, and the contentKey is then used to decrypt their files / data etc.

This also allows for users to be able to change their encryption keys if needed, without having to download, decrypt and re-encrypt all their data.

So on the server side, even in case of a compromise, there is no way to get the plaintext passwords nor encryption keys.

Happy to dive into deeper detail and even link to relevant sections of the source code if you wish ✌🏻

@Shifterovich **Single Password** Part of the reason why I haven't looked into implementing the single-password mechanism PM-and-alikes are using is that my aim is to make Cryptee a simple service even my mom can use, without having to stop using her gmail. 😅 You can log in to Cryptee using your google account + a separate encryption key. And while I did receive a some criticism for allowing this, numbers tell an interesting story. Currently ~65% of all users are signing up with their gmail accounts + a separate encryption key. Based on user feedback, I can confidently say that current users love that this exists, since this flow allows them to keep their gmail (for whatever reason they may wish/need to keep it) and only memorize an encryption key for Cryptee. (an example I commonly hear is that they have a corporate G-suite account, and they wish to have a private corner for themselves on the internet with it) That being said, there's nothing stopping me from implementing a [SRP](https://www.ietf.org/rfc/rfc2945.txt) / single-key system for logins like PM does. It's more so a business decision to launch fast, add new features fast, then slowly dive into these features. I am planning on adding SRP + Hardware FIDO 2FA like yubico in the near future. **As for passwords / key handling on frontend** Passwords are encrypted using `scrypt`, a key derivation function that was originally developed for use in the [Tarsnap](https://www.tarsnap.com/scrypt.html) online backup system and is designed to be far more secure against hardware brute-force attacks than alternative functions such as PBKDF2 or bcrypt. (according to the project's authors) And Cryptee uses both hashes and salt. As for the encryption key, A strong content encryption key (`contentKey`) is generated client side using browsers' own crypto module on signup. Which is what all the user data will be encrypted/decrypted with. This `contentKey` is then encrypted using the hashed user-chosen encryption key (`userKey`), finally the resulting encrypted `contentKey` is sent to server. So when users login, they receive the encrypted `contentKey` from the server, decrypt this with their key (`userKey`) in browser memory, and the `contentKey` is then used to decrypt their files / data etc. This also allows for users to be able to change their encryption keys if needed, without having to download, decrypt and re-encrypt all their data. So on the server side, even in case of a compromise, there is no way to get the plaintext passwords nor encryption keys. Happy to dive into deeper detail and even link to relevant sections of the source code if you wish ✌🏻

ghost commented

2018-12-15 18:49:07 +00:00

(Migrated from github.com)

You can log in to Cryptee using your google account + a separate encryption key. And while I did receive a some criticism for allowing this, numbers tell an interesting story. Currently ~65% of all users are signing up with their gmail accounts + a separate encryption key.

What I meant is that when I sign up using a nick/email, having "two passwords" (one for login and one for decryption) can be annoying sometimes.

Regarding encryption, great! Generating and encrypting the key on the client side, as well as hashing the password upon login/signup on the client side are great things.

> You can log in to Cryptee using your google account + a separate encryption key. And while I did receive a some criticism for allowing this, numbers tell an interesting story. Currently ~65% of all users are signing up with their gmail accounts + a separate encryption key. What I meant is that when I sign up using a nick/email, having "two passwords" (one for login and one for decryption) can be annoying sometimes. Regarding encryption, great! Generating and encrypting the key on the client side, as well as hashing the password upon login/signup on the client side are great things.

johnozbay commented

2018-12-15 18:54:21 +00:00

(Migrated from github.com)

What I meant is that when I sign up using a nick/email, having "two passwords" (one for login and one for decryption) can be annoying sometimes.

100% Agreed.

What I failed to express earlier is that this 2-pass system is currently in place, due to a consolidated login system which also includes Google Auth (and that naturally requires having a separate encryption key) –

So it's either
username/email & pass for auth + encryption key for security
or
google login for auth + encryption key for security.

and in the interest of launching Cryptee quickly I didn't create a separate SRP login flow for user/email pass yet. But an SRP single-pass login + yubikey fido 2fa is on the near-future todo list, as well as short pin-codes for mobile devices to make login faster on mobile devices ☕️

> What I meant is that when I sign up using a nick/email, having "two passwords" (one for login and one for decryption) can be annoying sometimes. 100% Agreed. What I failed to express earlier is that this 2-pass system is currently in place, due to a consolidated login system which also includes Google Auth (and that naturally requires having a separate encryption key) – So it's either username/email & pass for auth + encryption key for security or google login for auth + encryption key for security. and in the interest of launching Cryptee quickly I didn't create a separate SRP login flow for user/email pass yet. But an SRP single-pass login + yubikey fido 2fa is on the near-future todo list, as well as short pin-codes for mobile devices to make login faster on mobile devices ☕️

This repo is archived. You cannot comment on pull requests.

No reviewers