23 ms·

Sharelock – Securely share data

87 points by woloski 12y ago

coderzach 12y ago
How are keys shared between users?
- sharvil 12y ago
  Keys live on Sharelock server [1] Secrets are signed with HMAC SHA256 and encrypted with AES 256 CTR using keys that live on the Sharelock server [1] https://sharelock.io/security https://sharelock.io/security
  - SpaceInvader 12y ago
    So one have to trust sharelock. That's not very convincing, unfortunately.
    - woloski 12y ago
      Read my response above.
    - woloski 12y ago
      Read my response above.
- woloski 12y ago
  The encryption keys are on the server. We encourage you to deploy your own sharelock instance. We made that super easy with Heroku for instance (https://dashboard.heroku.com/new?template=https%3A%2F%2Fgithub.com%2Fauth0%2Fsharelock https://dashboard.heroku.com/new?template=https%3A%2F%2Fgith...). There is no storage, just a node app. And then you can configure the apps to use the sharelock instance. More about it: https://github.com/auth0/sharelock#host-your-own-sharelock-server https://github.com/auth0/sharelock#host-your-own-sharelock-s...
daddykotex 12y ago
I tried it from my browser to my cellphone. I use a Nexus 5 and it worked very well. I didn't have to install the app making it even easier. Good job.
lilyball 12y ago
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 original. I hope that gets fixed) > Secrets are signed with HMAC SHA256 and encrypted with AES 256 CTR using keys that live on the Sharelock server So it seems that the server holds the keys, and doles them out to users that prove their identity. And the URL holds the secret. So we're pretty much taking it on faith that the server never logs the URL anywhere (not just in the actual backend, but in access logs for any middleware or load balancers or anything else). As for authentication, the animated slideshow on the front of the site says the user has to login with a Google, Facebook, Microsoft, or Twitter account (I assume that secrets shared with twitter handles must use the Twitter login, but for emails it presumably uses any of them). I'm a bit concerned about the identity verification angle. If someone manages to compromise any of those 4 accounts, then that means they can then decrypt any URLs shared with that user (if they manage to get at the URL). Twitter accounts being compromised is not that uncommon. And it would be especially bad if the sharelock URLs are then sent via Twitter (say, Twitter DMs) to that user, because then the attacker has both the URL and the keys. Or perhaps the user doesn't even realize they have an old Microsoft account, one with a pathetically weak password, and the attacker breaks into that. In fact, that may very well apply to me (I don't use anything that requires a Microsoft login, but I did once have a (rarely-used) Windows Live login, and if Microsoft converted those into whatever their current authentication setup is, then I probably have an account with a terribly weak password).
- woloski 12y ago
  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-server https://github.com/auth0/sharelock#host-your-own-sharelock-s...
psandersen 12y ago
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?
- tjanczuk17 12y ago
  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.
  - psandersen 12y ago
    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.
voodoochilo 12y ago
...and then sign in via your fav nsa snitch. brilliant idea! excellent software. chapeau.
rakoo 12y ago
If it's text only, there's also zerobin (http://sebsauvage.net/wiki/doku.php?id=php:zerobin http://sebsauvage.net/wiki/doku.php?id=php:zerobin) that has a lot of features and the added bonus of not storing the key on the server (it's using the anchor part)
- alfg 12y ago
  Also created something similar a while back for fun, except for short text messages with the option for encryption in Javascript using an implementation of blowfish. It saves the data encoded (or encrypted) as part of the url. Source with demo: https://github.com/alfg/jot https://github.com/alfg/jot
politegoose 12y ago
Does anyone here have experience with Tresorit? [1] They claim to offer something similar in terms of secure sharing, but with zero-knowledge encryption, i.e. without storing keys on the server. [2] Trouble is that the service seems very new, so not many reviews exist. The client being closed-source doesn't help, and I'm not in a position to evaluate their bounty program. [1] https://tresorit.com/features https://tresorit.com/features [2] https://tresorit.com/files/encrypted-link-whitepaper.pdf https://tresorit.com/files/encrypted-link-whitepaper.pdf
didgeoridoo 12y ago
No comment on the underlying technology or security, but damned if that isn't one of the best "explainer" animations I've ever seen. I'm adding this to my personal "awesome onboarding" catalogue.
- aakash 12y ago
  Would you know any tool to quickly create such onboarding animations?
  - didgeoridoo 12y ago
    This one looks like it's done with GreenSock, but you could probably get away with using Abode Edge Animate (more WYSIWYG, Flash-like editing experience).
moe 12y ago
Since this is limited to about the length of a tweet and requires to fully trust a third party (Sharelock), why not just send the message directly on Google, Facebook or Twitter? What is Sharelock adding here other than a false sense of security? Are we supposed to trust Sharelock more than the aforementioned services?
avenpace 12y ago
Strange coincidence that we share same name with bit similar concept under different tld. Mine is http://sharelock.co http://sharelock.co Kudos for nice ui
- therealidiot 12y ago
  Starts asking for location on load, tab closed :(
EGreg 12y ago
Sign in with google? Facebook? So you have to trust them, since they can get your data. No? If anything, Apple's iMessage already lets you send secure data this way. Apple doesn't hold the keys, and messages are encrypted locally. The site doesn't scroll properly on iPhone 5. Probably was designed with iPhone 6 in mind. Otherwise - this is a cool concept! Just fix the auth.

87 points by woloski 12y ago

coderzach 12y ago

How are keys shared between users?

sharvil 12y ago
Keys live on Sharelock server [1] Secrets are signed with HMAC SHA256 and encrypted with AES 256 CTR using keys that live on the Sharelock server [1] https://sharelock.io/security https://sharelock.io/security
- SpaceInvader 12y ago
  So one have to trust sharelock. That's not very convincing, unfortunately.
  - woloski 12y ago
    Read my response above.
  - woloski 12y ago
    Read my response above.
woloski 12y ago
The encryption keys are on the server. We encourage you to deploy your own sharelock instance. We made that super easy with Heroku for instance (https://dashboard.heroku.com/new?template=https%3A%2F%2Fgithub.com%2Fauth0%2Fsharelock https://dashboard.heroku.com/new?template=https%3A%2F%2Fgith...). There is no storage, just a node app. And then you can configure the apps to use the sharelock instance. More about it: https://github.com/auth0/sharelock#host-your-own-sharelock-server https://github.com/auth0/sharelock#host-your-own-sharelock-s...

daddykotex 12y ago

I tried it from my browser to my cellphone. I use a Nexus 5 and it worked very well. I didn't have to install the app making it even easier. Good job.

lilyball 12y ago

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 original. I hope that gets fixed) > Secrets are signed with HMAC SHA256 and encrypted with AES 256 CTR using keys that live on the Sharelock server So it seems that the server holds the keys, and doles them out to users that prove their identity. And the URL holds the secret. So we're pretty much taking it on faith that the server never logs the URL anywhere (not just in the actual backend, but in access logs for any middleware or load balancers or anything else). As for authentication, the animated slideshow on the front of the site says the user has to login with a Google, Facebook, Microsoft, or Twitter account (I assume that secrets shared with twitter handles must use the Twitter login, but for emails it presumably uses any of them). I'm a bit concerned about the identity verification angle. If someone manages to compromise any of those 4 accounts, then that means they can then decrypt any URLs shared with that user (if they manage to get at the URL). Twitter accounts being compromised is not that uncommon. And it would be especially bad if the sharelock URLs are then sent via Twitter (say, Twitter DMs) to that user, because then the attacker has both the URL and the keys. Or perhaps the user doesn't even realize they have an old Microsoft account, one with a pathetically weak password, and the attacker breaks into that. In fact, that may very well apply to me (I don't use anything that requires a Microsoft login, but I did once have a (rarely-used) Windows Live login, and if Microsoft converted those into whatever their current authentication setup is, then I probably have an account with a terribly weak password).

woloski 12y ago
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-server https://github.com/auth0/sharelock#host-your-own-sharelock-s...

psandersen 12y ago

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?

tjanczuk17 12y ago
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.
- psandersen 12y ago
  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.

voodoochilo 12y ago

...and then sign in via your fav nsa snitch. brilliant idea! excellent software. chapeau.

rakoo 12y ago

If it's text only, there's also zerobin (http://sebsauvage.net/wiki/doku.php?id=php:zerobin http://sebsauvage.net/wiki/doku.php?id=php:zerobin) that has a lot of features and the added bonus of not storing the key on the server (it's using the anchor part)

alfg 12y ago
Also created something similar a while back for fun, except for short text messages with the option for encryption in Javascript using an implementation of blowfish. It saves the data encoded (or encrypted) as part of the url. Source with demo: https://github.com/alfg/jot https://github.com/alfg/jot

politegoose 12y ago

Does anyone here have experience with Tresorit? [1] They claim to offer something similar in terms of secure sharing, but with zero-knowledge encryption, i.e. without storing keys on the server. [2] Trouble is that the service seems very new, so not many reviews exist. The client being closed-source doesn't help, and I'm not in a position to evaluate their bounty program. [1] https://tresorit.com/features https://tresorit.com/features [2] https://tresorit.com/files/encrypted-link-whitepaper.pdf https://tresorit.com/files/encrypted-link-whitepaper.pdf

didgeoridoo 12y ago

No comment on the underlying technology or security, but damned if that isn't one of the best "explainer" animations I've ever seen. I'm adding this to my personal "awesome onboarding" catalogue.

aakash 12y ago
Would you know any tool to quickly create such onboarding animations?
- didgeoridoo 12y ago
  This one looks like it's done with GreenSock, but you could probably get away with using Abode Edge Animate (more WYSIWYG, Flash-like editing experience).

moe 12y ago

Since this is limited to about the length of a tweet and requires to fully trust a third party (Sharelock), why not just send the message directly on Google, Facebook or Twitter? What is Sharelock adding here other than a false sense of security? Are we supposed to trust Sharelock more than the aforementioned services?

avenpace 12y ago

Strange coincidence that we share same name with bit similar concept under different tld. Mine is http://sharelock.co http://sharelock.co Kudos for nice ui

therealidiot 12y ago
Starts asking for location on load, tab closed :(

EGreg 12y ago

Sign in with google? Facebook? So you have to trust them, since they can get your data. No? If anything, Apple's iMessage already lets you send secure data this way. Apple doesn't hold the keys, and messages are encrypted locally. The site doesn't scroll properly on iPhone 5. Probably was designed with iPhone 6 in mind. Otherwise - this is a cool concept! Just fix the auth.