
Sharelock – Securely share data - woloski
https://sharelock.io
======
eridius
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).

~~~
eridius
Regarding the access logs angle, the image shown on the front page shows a URL
that starts with
"[https://sharelock.io/1/cuwcRv64IR5ivYP..."](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.

~~~
tjanczuk17
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.

~~~
eridius
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.

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

------
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?

~~~
tjanczuk17
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
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.

~~~
tjanczuk17
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.

~~~
psandersen
Then to put it bluntly your service is misleading, and is the encryption
equivalent of selling a leather jacket as a bullet proof vest.

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

------
moe
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?

------
politegoose
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
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
Would you know any tool to quickly create such onboarding animations?

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

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

------
avenpace
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
Starts asking for location on load, tab closed :(

------
coderzach
How are keys shared between users?

~~~
sharvil
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
So one have to trust sharelock. That's not very convincing, unfortunately.

~~~
woloski
Read my response above.

