Some computers on my university block the keepass application which I use as a password manager. I'm thinking of building a small web application + Android app which lets me securely copy a string from my phone to my computer. Since more people will have this problem, I'd like both the web application as the app to be available to everyone. That's why I will need to establish some kind of link between a session on the web application and an instance of the Android app. I thought of the following, inspired by Firefox Sync's system:

  1. User goes to the web app and gets a unique pin code NA which is linked to his session id
  2. User enters NA in the app and gets a new random pin code NB (the app sends NA to the server and receives NB)
  3. User enters NB in the web application
  4. The server verifies that the NB inputted in the web application is the nonce that was sent to the app that sent NA. I'm also thinking about checking that the web app and the app are using the same IP address, although this may give issues with cellular networks.

Both the app and the web app are uniquely identified by a session id which is sent together with every request.

After this authentication scheme, a link is established which is valid for so-long time. Of course also the nonces used in the scheme are kept track of by the server and have a deadline. Naturally, all communication (app - server, server - web app) is done over an encrypted channel.

Now, the app can send a string to the server, which then communicates it to the web app to which it is linked. The web app would not show the string of course, but merely copy it to the clipboard when the user asks for that. This reduces the risk of people looking over your shoulder.

Is this scheme secure? What I'm mainly worried/wondering about:

  • Session stealing: this would of course be more difficult when IP is checked as well, but still, it could occur. When using HTTPS, am I correct that the only way the session could be stolen would be using a man in the browser or man in the phone? This would be acceptable.

  • How do I choose a bit length for the nonces? It always occurred to me that Firefox uses incredibly short pin codes. Is the necessary bit length dependent on how many users the application would have (for example, with 10,000 open nonces at a time in the database, I could imagine the bit length would need to be greater than with 10 open nonces, to make brute force attacks harder).

  • Would using a web app on the phone as well (either making a sending and a receiving version of the web app, or making this two-way communication) introduce any additional security vulnerabilities (except for man in the browser on the phone)?

  • Things I didn't see, obviously.

  • Am I reinventing the wheel?
    Note the requirement to not have to install anything on the computer; it should run in the browser. Also, I'd prefer to not have my passwords in the cloud as with LastPass. The strings that are communicated with my app would be deleted after the web app received them.

  • 1
    Why not export the text string to a file, and connect your phone via a USB cable then copy/paste from there?
    – schroeder
    Feb 3, 2015 at 18:32
  • @schroeder that is a good idea, but I'd prefer something that I don't have to remember to take my cable with me.
    – user21287
    Feb 3, 2015 at 18:40
  • 2
    What about posting an encrypted form of the text to Twitter via the phone, then recovering the text on the PC? Twitter API FTW
    – schroeder
    Feb 3, 2015 at 18:52
  • 1
    @schroeder, I can see it now #secureUser says "YSrW0UUMTIsc7pGMI23g6kv+ONfCPAv9SQt6H+dwOFc=" and pretty soon #botnet is now following #secureUser. Nothing wrong with that per ce just funny... Feb 3, 2015 at 20:08
  • 1
    Lesson #1 about security protocols: don't roll your own. :) If you use a basic symmetric encryption, and use private tweets, all your concerns you list above are solved. The reason I have not turned my comments into an answer is because it is not really what you wanted to hear, but I wanted to toss it into the mix to think about.
    – schroeder
    Feb 3, 2015 at 21:37

2 Answers 2


I know this isn't a direct answer, but per your request in comments, I am submitting it.

Instead of rolling your own protocol, take advantage of existing protocols to do what you need. Your spec describes a web-based protocol with encryption and limited access to data passed from phone to PC. This web service needs high availability and uptime.

Twitter can fit your bill. Set up a separate Twitter account for this purpose and compose protected tweets that contain the password that you want to pass from your phone to the end point. The only thing you need to introduce (maybe!**) is a simple symmetric encryption of the password. So, your operational task is simple:

  1. copy the password from your phone's Keepass
  2. process the password through encryption
  3. send the cypher text as a protected tweet to yourself
  4. on the PC, capture the cypher text and decrypt it
  5. paste into final application as the password

With the Twitter API publicly available, you could accomplish all this in a few lines of Python code.

**All of this complexity depends on your need for the password to be transmitted encrypted. If you use Twitter, the channel is encrypted (TLS), and if you use protected tweets, no one else can see the text. You could simply send the password as plaintext IF you determine the risk is acceptable. If you go the unencrypted route, I might suggest that your password be as random as possible so that if the plaintext did leak, it would not be obvious that you were sending yourself passwords (e.g. not "thisIsMyBankPassword1!").


This is how I would do it. Have the web app generate a public/private pair (say DH). Show the public key on the screen as QR code, the user then scans it with the phone. From this point onward, the phone can send anything to the web app securely.

  • What does DH have to do with it?
    – user21287
    May 3, 2016 at 8:50
  • Just "for example" May 3, 2016 at 14:53
  • The point is that with DH you agree on a key for a symmetric cipher. You seem to be suggesting to use it to generate a public/private key pair.
    – user21287
    May 3, 2016 at 18:58
  • Sorry for the confusion. I was suggesting DH can be used to agree on a key between the phone and the web app and the exchange happens through the use of QR code. May 3, 2016 at 22:56
  • Then I assume with 'public key' you mean g^a, where a is the web app's secret. You don't describe how the phone can communicate g^b (where b is the phone's secret). Also, the terminology is confusing. In DH, there is no public/private pair, nor a public key.
    – user21287
    May 4, 2016 at 7:41

You must log in to answer this question.