Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sharelock – Securely share data

sharelock.io

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Sharelock – Securely share data

#11

Post by eridius »

lilyball wrote: post #9

From the "Security" page: > Urls are ephemeral, they are NOT stored anywhere (neither your secrets). The content you share lives encrypted in the URL. > The decrypted content can ONLY be accessed by the people that you shared shared the data with by means of login and email verification (as opposed to, let's say, Dropbox links which can be accessed by anyone who has the link). (note: "shared shared" is present in the…

Regarding the access logs angle, the image shown on the front page shows a URL that starts with "https://sharelock.io/1/cuwcRv64IR5ivYP...". Presumably that garbage text is the start of the secret.

It would probably be a really good idea to move the secret into the fragment of the URL instead. Fragments aren't sent to servers, so they can't possibly show up in access logs. But the client can still access the fragment, and since the decryption presumably happens client-side, there's no reason for the server to ever even see the secret.

Re: Sharelock – Securely share data

#12

Post by eridius »

woloski wrote: post #10
lilyball wrote: post #9

From the "Security" page: > Urls are ephemeral, they are NOT stored anywhere (neither your secrets). The content you share lives encrypted in the URL. > The decrypted content can ONLY be accessed by the people that you shared shared the data with by means of login and email verification (as opposed to, let's say, Dropbox links which can be accessed by anyone who has the link). (note: "shared shared" is present in the…

Yep, you got it right. Re: holding the keys, response below. The encryption keys are on the server. We encourage you to deploy your own sharelock instance. We made that super easy with Herok. There is no storage, just a node app. And then you can configure the apps to use that Sharelock instance. More about it: https://github.com/auth0/sharelock#host-your-own-sharelock-s...

I saw that, but it seems the whole point of this thing is to make it easy to share secrets, and everybody hosting their own instance is about as far from "easy" as I can think of. Some people will surely do it, but the number of people who will is going to be extremely low.

Re: Sharelock – Securely share data

#13

Post by tjanczuk17 »

eridius wrote: post #11
lilyball wrote: post #9

From the "Security" page: > Urls are ephemeral, they are NOT stored anywhere (neither your secrets). The content you share lives encrypted in the URL. > The decrypted content can ONLY be accessed by the people that you shared shared the data with by means of login and email verification (as opposed to, let's say, Dropbox links which can be accessed by anyone who has the link). (note: "shared shared" is present in the…

Regarding the access logs angle, the image shown on the front page shows a URL that starts with " https://sharelock.io/1/cuwcRv64IR5ivYP..." . Presumably that garbage text is the start of the secret. It would probably be a really good idea to move the secret into the fragment of the URL instead. Fragments aren't sent to servers, so they can't possibly show up in access logs. But the client can still access the fragme…

The decryption happens server-side - the server is the sole holder of encryption keys. Besides, it is the server that generated that ciphertext in the first place, so it already had access to the secret at that point.

Re: Sharelock – Securely share data

#14

Post by rolodato »

lilyball wrote: post #9

From the "Security" page: > Urls are ephemeral, they are NOT stored anywhere (neither your secrets). The content you share lives encrypted in the URL. > The decrypted content can ONLY be accessed by the people that you shared shared the data with by means of login and email verification (as opposed to, let's say, Dropbox links which can be accessed by anyone who has the link). (note: "shared shared" is present in the…

Typo has been fixed, thanks for reporting.

Re: Sharelock – Securely share data

#15

Post by psandersen »

As others have point out this just means you have to trust Sharelock. While its slightly less user friendly, and it has its own security issues would the following be viable:

1) Sender clicks 'share a file' and no file is uploaded yet. 2) Email is sent to recipient, explaining that they have an encrypted file waiting for them, and takes them through creating a public key done in their browser via JavaScript (biggest vulnerability....) 3) Original user receives email/notification with senders public key, and uploads a file that is encrypted with that public key. 4) Recipient receives notification that the file is now ready, and decrypt it with their client side JavaScript.

That way Sharelock or another service will never store the unencrypted files, and this service can be made more secure with open source uploader/key generation (e.g. for people more security conscious they dont use the webapp, but they use an API with their local app). Sharelock should commit to never holding backups of user data, and deleting all files after they have been 'received'.

It makes sending encrypted files as convenient as is possible, and be useful for many projects where the client doesnt want to share the plaintext data but it needs to be easy to use.

Thoughts?

Re: Sharelock – Securely share data

#17

Post by tjanczuk17 »

psandersen wrote: post #15

As others have point out this just means you have to trust Sharelock. While its slightly less user friendly, and it has its own security issues would the following be viable: 1) Sender clicks 'share a file' and no file is uploaded yet. 2) Email is sent to recipient, explaining that they have an encrypted file waiting for them, and takes them through creating a public key done in their browser via JavaScript (biggest…

You are right in your observation that the exchange of secrets through Sharelock.io is only secure if you trust the integrity of the service and the people behind it. To mitigate this concern we offer Sharelock as an open source project on GitHub, which allows anyone to create their own island of trust by hosting an instance and controlling cryptographic keys.

There are many ways to organize a secure exchange of secrets, each of them with different trade offs between usability and allocation of trust. With Sharelock we aspired to create a system that is maximally usable by leveraging existing social identity providers and remaining agnostic to the mechanism used to transfer ciphertext. We believe this approach makes Sharelock.io more widely applicable to a broad range of scenarios.

Re: Sharelock – Securely share data

#18

Post by higherpurpose »

psandersen wrote: post #15

As others have point out this just means you have to trust Sharelock. While its slightly less user friendly, and it has its own security issues would the following be viable: 1) Sender clicks 'share a file' and no file is uploaded yet. 2) Email is sent to recipient, explaining that they have an encrypted file waiting for them, and takes them through creating a public key done in their browser via JavaScript (biggest…

That's disappointing. I hoped this would be done using WebRTC or something end-to-end.

Re: Sharelock – Securely share data

#19

Post by psandersen »

tjanczuk17 wrote: post #17
psandersen wrote: post #15

As others have point out this just means you have to trust Sharelock. While its slightly less user friendly, and it has its own security issues would the following be viable: 1) Sender clicks 'share a file' and no file is uploaded yet. 2) Email is sent to recipient, explaining that they have an encrypted file waiting for them, and takes them through creating a public key done in their browser via JavaScript (biggest…

You are right in your observation that the exchange of secrets through Sharelock.io is only secure if you trust the integrity of the service and the people behind it. To mitigate this concern we offer Sharelock as an open source project on GitHub, which allows anyone to create their own island of trust by hosting an instance and controlling cryptographic keys. There are many ways to organize a secure exchange of secr…

Then how is your service any more secure than any file upload service with ssl? It just seems misleading, whats the point of a safe when the key is glued to the door.

An encryption service that requires people trust its owners just isnt secure. You could be perfect with the utmost of integrity even under insurmountable legal pressure, but even then, if your system has a way of knowing the keys its leaving the door open.

Post reply on HN