> 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.
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.
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.
> 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).