3

I have searched for related topics, but found other existing answers to not be satisfactory, because they require installing special tools.

This is a very common use case. For example, I want to share sensitive login credentials with other members of my team so that we can administer servers.

Plaintext must be encrypted, and then both the password and the ciphertext have to be transferred to the friendly party over the insecure channel that is the internet.

The catch? I don't want to have to guide my associate through (or burden myself with having to go through) installing PGP or generating a 2048bit RSA keypair and host an SFTP server or something like that.

That means the only option left is the web browser.

Here's my solution so far. Consider onetimesecret.com to be a generalized web-accessible service that actually does what it promises to do. My question is, can this be further improved?

  1. Alice runs cat /dev/urandom | base64, grabs some part of the stream, long enough to be a good password, and not too long for the next step
  2. Alice sends this string to Bob via https://onetimesecret.com/
  3. Alice waits for Bob to report that the string has been successfully retrieved. If we trust onetimesecret.com, this means that only Alice and Bob are in possession of the string. If Bob reports that the link is dead and has been accessed, Alice throws away and generates a new password.
  4. Alice encrypts plaintext with the password that Bob has successfully received. For example, AES encryption using a 7z or RAR archive.
  5. Alice sends Bob another https://onetimesecret.com/ link with the contents. There is a bit of a flaw here, which is that the actual onetimesecret.com service doesnt appear to support file attachments. A workaround may be to Base64-encode the encrypted payload and send that. Or, less desirably, Alice can simply email it -- In this case, an adversary can obtain a copy of the encrypted file but would still need to decrypt it. Step 1 takes care of making this sufficiently hard.

The weakest link in this is likely to be step #3. I believe the correct terminology here is "Authentication".

The adversary's options are, as far as I can tell,

  • be onetimesecret.com or have internal access to it (we handwave this and say it's fine, they're secure)
  • break TLS or HTTPS. (we also handwave this and say it's fine, our OS is patched, our browser is patched)
  • impersonate Bob until Alice performs step 5. (Alice demands Bob stay on the phone to verify step 3)

And I might be stating the obvious here but just to clarify, the need for all these 5 steps is to add a sort of "manual" handshake step independently, in an effort to prevent data leakage -- this still means we have to trust the onetimesecret.com webservice to actually destroy the messages that we send to it that it promises are delivered only once.

The third item in the second list is the one relevant to the authentication part of our custom handshake. Traditional/standard secure authentication is not possible without the involvement of having extra steps to generate secure keys. I'm trying to streamline things to the point where they become practical. Which means not requiring users to be generating keys.

Community
  • 1
Steven Lu
  • 977
  • 2
  • 12
  • 13
  • If you need a secure channel for Bob and Alice to mutually authenticate and share a secret, you might as well use that one. In other words I have the feeling you're just displacing the problem rather than solving it. – Steve Dodier-Lazaro May 27 '15 at 16:26
  • Well, I take it you mean Alice stands up an HTTPS/SFTP webserver so that the transfer can happen over TLS. Yes, but I want to do it without installing such a webserver anywhere. Isn't it true that Alice would have to obtain an SSL cert? – Steven Lu May 27 '15 at 16:27
  • 1
    I haven't mentioned HTTPS. What I meant was that "3. Alice waits for Bob to report that the string has been successfully retrieved." requires Alice to know that it is Bob talking, and some method for Bob to convince Alice that it was the right string being received. It would help to have a threat model to answer that question: who's attacking? Does it include people likely to break a CA or an ISP? How motivated are they (targeted vs indiscriminate attacks)? What's the lifetime and sensitivity of the secret? – Steve Dodier-Lazaro May 27 '15 at 16:30
  • Well, those are great questions but their answers are not well-defined. If I had the expertise, I would approach answering the question along those lines! Obviously if CA or ISP breakage happens then all bets are off considering the approach that I proposed. As for how motivated, well, I'm basically looking for a practical solution that resists the maximum amount of "motivation", if that makes sense. And let's just say that lifetime is pretty long (see example of server login credentials -- i suppose it's months at minimum given reasonable IT practices). Just pick reasonable values. – Steven Lu May 27 '15 at 16:38
  • Ok, so you'd be interested in protecting yourself against opportunistic hackers rather than a government doing mass collection of Internet traffic? I don't know the service at all so I don't know how it works, but an arbitrary private repository should be fine, yes. You could even share an email account and just write the temporary encryption key in the drafts, then have it deleted by the other party for what it's worth. – Steve Dodier-Lazaro May 27 '15 at 16:41
  • onetimesecret.com might delete the link after first viewing, yes. But how does Alice transmit data to onetimesecret.com the very first time? On their webpage that looks like a text box. Is there a way for your adversary to intercept that? – curious_cat May 27 '15 at 16:42
  • Well as I understand the security model of the modern web browser, the text box's contents are transferred to onetimesecret.com's webservers using a POST over HTTPS. Presumably the contents are kept on their server for up to 7 days. It will be wiped clean either at 7 days or when the one time URL is first accessed (which is intended for Bob, who will receive the contents also over HTTPS, with a GET request). – Steven Lu May 27 '15 at 16:43
  • @SteveDL It would be very interesting to me to discuss how mass collection of traffic could compromise this approach. It should still require breaking HTTPS/TLS. – Steven Lu May 27 '15 at 16:47
  • @StevenLu: Maybe I'm naive but why not use an off channel means to transmit the key? Say a text message. I'm sure that could be hacked / intercepted too but the chance of your adversary monitoring that stream too must be small? – curious_cat May 27 '15 at 16:49
  • @curious_cat I think your point is quite valid, but I guess I am trying to mitigate that risk as much as possible. The point of using the service is that it's a secure web channel, and in theory it's exactly as hard to peep that key as it is to break the HTTPS stream, and the assumption here is that the HTTPS stream is more resilient than (insert off channel method here). For example, mass data collection does completely open up the text message... But to break #3, suppose Alice and Bob do a Skype chat, that's hard to social-engineer because Alice can visually verify Bob is not under duress – Steven Lu May 27 '15 at 16:53
  • Yes, all attacks would require a compromised device or a compromise of HTTPS. – Steve Dodier-Lazaro May 27 '15 at 16:57
  • @StevenLu: Is it an option to just read out the whole key over the phone (say)? e.g. How long would it take to read out a 1024 bit key by voice? Bit tedious I admit, but is that a possibility? Or are we worrying about voice taps and mass surveillance storing voice conversations etc? To combat voice taps use a GSM network I guess. Those encrypt the voice traffic I think, at least in the latest network generations. – curious_cat May 27 '15 at 17:00
  • At the point we worry about a HTTPS compromise one also has to worry about the pristine-ness of the source machine? Why if it had a keylogger installed? – curious_cat May 27 '15 at 17:01
  • Yep. I was attempting to draw the line where the assumption is that HTTPS is secure (and now that you mention it, probably also to assume the machines are clean). The actual process can be resilient to actually typing the password, but in that case the password will exist in the OS pastebuffer for some time (as well as the memory space of the client program used to unzip the encrypted archive file). – Steven Lu May 27 '15 at 17:04
  • @curious_cat I missed your other comment, basically I think that it is a solid assumption to make that HTTPS >> voice comms, be it tin-can-and-string or GSM. For our purposes, the adversary can listen in on the call easier than he can break HTTPS. – Steven Lu May 27 '15 at 17:10
  • The service you describe isn't hard to implement. The main problem with such an encrypted file exchange service is that a few people will start to abuse it to distribute illegal material. Even when you secure yourself legally so you can not be held liable, your local law enforcement will still pester you with demands to make your service less secure. – Philipp May 27 '15 at 17:48

0 Answers0