Sharelock – Securely share data(sharelock.io)
sharelock.io
Sharelock – Securely share data
https://sharelock.io
36 comments
And at least on the web page, Google Web Fonts included.
Yes, they track usage. Yes, they log URLs.
Same goes for jquery CDN and CloudFlare. And 0Auth.com
Every. URL. Tracked.
Oh, and it utterly fails with non FB, Gmail, Twitter, MSFT linked address.
Yes, they track usage. Yes, they log URLs.
Same goes for jquery CDN and CloudFlare. And 0Auth.com
Every. URL. Tracked.
Oh, and it utterly fails with non FB, Gmail, Twitter, MSFT linked address.
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.
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.
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.
Oh geeze, I didn't realize the server also did the encryption/decryption. The bit about the secret only being in the URL and not on the server made me think it was done client-side.
If it's happening server-side then it seems like this is only appropriate to use when you're hosting your own instance. Using anybody else's instance (for anything that actually needs to be encrypted) means handing your plaintext to the server operator.
If it's happening server-side then it seems like this is only appropriate to use when you're hosting your own instance. Using anybody else's instance (for anything that actually needs to be encrypted) means handing your plaintext to the server operator.
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.
> The content you share lives encrypted in the URL.
I'm a little confused.
If the encrypted data is "in the url" and you need to share the url, then why not just share the encrypted data itself?
This seems like it adds a lot of problems to solve key distribution.
Edit - it doesn't do key distribution, the encryption and decryption are done on the server.
I'm a little confused.
If the encrypted data is "in the url" and you need to share the url, then why not just share the encrypted data itself?
This seems like it adds a lot of problems to solve key distribution.
Edit - it doesn't do key distribution, the encryption and decryption are done on the server.
Typo has been fixed, thanks for reporting.
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.
Good job.
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?
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?
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.
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.
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.
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.
We aspired to create a service that is similarly secure to a file upload service with SSL, but more usable at the same time by not tying the user to a partcular data exchange mechanism (you can sent the sharelock URL via e-mail, Tweet it, or publish in a New York Times).
Having said that, exposure of the user of sharelock.io can be argued to be lower than in case of a service which durably stores user's data. While sharelock.io keeps the cryptographic credentials, it does not durably store users' secrets or ciphertext.
Having said that, exposure of the user of sharelock.io can be argued to be lower than in case of a service which durably stores user's data. While sharelock.io keeps the cryptographic credentials, it does not durably store users' secrets or ciphertext.
Then to put it bluntly your service is misleading, and is the encryption equivalent of selling a leather jacket as a bullet proof vest.
What kind of adversary would be defeated by Sharelock but could overcome TLS?
Thoughts? I built it a couple years ago! :)
Works almost exactly as you said, although you quickly run into problems with how much data you can store in javascript before the page blows up.
http://www.senditonthenet.com/
Works almost exactly as you said, although you quickly run into problems with how much data you can store in javascript before the page blows up.
http://www.senditonthenet.com/
Looks useful, thanks for sharing. Could probably get some good traction if the UI was as polished as Sharelock, its a real pain point working with confidential files and non tech savvy clients.
Have any of the improvements in javascript engines/web standards made javascript based public key encryption more viable?
Have any of the improvements in javascript engines/web standards made javascript based public key encryption more viable?
That's disappointing. I hoped this would be done using WebRTC or something end-to-end.
If it's text only, there's also 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)
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
Source with demo: https://github.com/alfg/jot
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?
What is Sharelock adding here other than a false sense of security? Are we supposed to trust Sharelock more than the aforementioned services?
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
[2] https://tresorit.com/files/encrypted-link-whitepaper.pdf
[1] https://tresorit.com/features
[2] https://tresorit.com/files/encrypted-link-whitepaper.pdf
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.
Would you know any tool to quickly create such onboarding animations?
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).
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.
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.
Strange coincidence that we share same name with bit similar concept under different tld. Mine is http://sharelock.co
Kudos for nice ui
Starts asking for location on load, tab closed :(
How are keys shared between users?
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%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-s...
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
So one have to trust sharelock. That's not very convincing, unfortunately.
> 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).