> 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).
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.
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...
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.
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.
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.
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?
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.
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.
lilyball|11 years ago
> 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).
chinathrow|11 years ago
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.
eridius|11 years ago
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.
woloski|11 years ago
IanCal|11 years ago
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.
rolodato|11 years ago
daddykotex|11 years ago
Good job.
psandersen|11 years ago
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|11 years ago
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.
jonttaylor|11 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/
higherpurpose|11 years ago
rakoo|11 years ago
alfg|11 years ago
Source with demo: https://github.com/alfg/jot
moe|11 years ago
What is Sharelock adding here other than a false sense of security? Are we supposed to trust Sharelock more than the aforementioned services?
politegoose|11 years ago
[1] https://tresorit.com/features
[2] https://tresorit.com/files/encrypted-link-whitepaper.pdf
didgeoridoo|11 years ago
aakash|11 years ago
EGreg|11 years ago
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.
avenpace|11 years ago
therealidiot|11 years ago
coderzach|11 years ago
woloski|11 years ago
sharvil|11 years ago
voodoochilo|11 years ago
[deleted]