Skip to content
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

Question about features : Client/Server side encryption #201

Closed
ovizii opened this issue Apr 13, 2017 · 3 comments
Closed

Question about features : Client/Server side encryption #201

ovizii opened this issue Apr 13, 2017 · 3 comments

Comments

@ovizii
Copy link

ovizii commented Apr 13, 2017

I'm looking for something like plik but am not sure it has the features I am looking for. Currently still comparing a few different projects.

I see Google and OVH are available for authentication but I'm not sure how I would use those two and still restrict access to a specific user base. Would it be possible to add IMAP as an authentication provider? That way I could easily give all existing users of an IMAP server access.

How are uploaded files treated, are they encrypted? If yes. client-side or server-side?

It looks like the file names of uploaded files are visible in the download URL, can that be changed?

@camathieu
Copy link
Member

Hi,

For now it's not really possible to restrict to a specific user base as there is no validation of the accounts. You can still restrict user creation per source IP address, for example users would have to create the account from your office and then could use it from everywhere. We are looking to improve that and make it very generic so it could be possible to add authentication methods easily.

Uploaded files receive no special treatments, but the plik cli has a -s option that pass the files to openssl. We did not implement anything in javascript because of the lack of stream stack to pipe the file through encryption and XHR request body. We do not believe much in server side encryption as if the server is compromised the protection could hold for already uploaded files but any new file could be hijacked easily.

The need of the name in the url is mainly for old browser and cli tools to get the right file name and to ensure the name is not changed on download. Nevertheless file id is sufficient for us to get the file out of the system.

@ovizii
Copy link
Author

ovizii commented Apr 18, 2017

Thanks for the feedback.

@ovizii ovizii closed this as completed Apr 18, 2017
@ovizii
Copy link
Author

ovizii commented Apr 18, 2017

oh, btw. I found this description in a similar project and that sounded like a nice implementation of server side encryption:

Data encryption can be activated in options. This feature makes the server encrypt data and send the decryt key to the user (inside download URL).
The decrypt key is not stored on the server so if you loose an url, you won't be able to retrieve file content.
In case of security troubles on the server, attacker won't be able to access files.

@ovizii ovizii reopened this Apr 18, 2017
@camathieu camathieu changed the title Question about features Question about features : Client/Server side encryption Jun 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants