I'm working on an app that will run on a users TV and has a companion mobile app.

I wanted to present a QR code to my users from the the TV app, which is then scanned by the companion mobile app's camera. I was originally thinking of encoding a v4 UUID in the QR code and use it as a shared secret between the two apps. This value would uniquely identify that particular TV device.

Once the shared secrets have been exchanged, the apps would connect to my server via web sockets and listen/emit events for that UUID. There would be no other passwords or usernames. This web socket communication would be done using WSS/TLS.

This service is a very simple message transport system between the mobile app and the TV app. There is no database, no users, etc. All messages are straight passthrough.

How bad of an idea is this? If the shared secret is nearly impossible to guess, it seems pretty secure to me at first glance. Is there anyway I could make it more secure?

One idea I had was to use some form of TOTP. That system is based on a shared secret as well, but it uses a time based component to modify the secret before exchanging/comparing. This would prevent the exposure of my real secret and prevent replay attacks. However, for my application, I would need a time window much larger than traditional TOPT as I would like this key to be valid for more than a few seconds.

  • You rely on noone knowing/guessing the UUID. If I understand correctly, you use the UUID for identification, so it is more or less "public", just like a username. You could generate a second shared UUID in your QR Code, and use that as a key for AES encryption and encrypt/decrypt the messages with that. As the second UUID will never be sent out, this should be alot more secure.
    – Flo
    Commented Sep 25, 2015 at 14:29
  • @Flo, that is an interesting idea. That would prevent any communication from being monitored. If I'm already using TLS/WSS between TV->Server and from Phone App->Server, is this necessary? If someone where to sniff my traffic, it would already be encrypted.
    – mmcdole
    Commented Sep 25, 2015 at 19:58
  • @Flo, you are correct about the UUID being used for identification. It is considered a secret, because I'd prefer random people not be able to guess a particular TV's UUID and send messages to it. They should only be able to send messages with it if they have 'paired' with it (ie, scanning the TVs UUID). Can you think of any way I can make this identification more secure?
    – mmcdole
    Commented Sep 25, 2015 at 20:00
  • Do not use UUIDs for as secrets. The UUID specification allows for predictable value generation. Use a properly seeded cryptographically secure PRNG instead.
    – atk
    Commented May 23, 2016 at 1:19
  • Also, consider using your randomly generated key as a preshared TLS key (the PSK cipher suites)
    – atk
    Commented May 23, 2016 at 1:21

2 Answers 2


This is a problem that has been solved by OAuth 2 and Open ID Connect (OIDC). I would strongly suggest building on it rather than inventing your own protocol. Take a look at the OAuth 2 device workflow (Google has an excellent description).

First off, it helps to split authentication from authorization. Authorization is what you want to achieve (i.e. authorizing the TV). Whether the authentication workflow requires login or not, or involves multiple factors is something that should be considered separate from the authorization workflow and may be something you want to be configurable.

Diagram below outlines the OAuth 2 device workflow.

TV app                                    Server
   |                                        |
   |----------- request code -------------->|
   |<------- url & auth code (QR) ----------|
   |                                        |
   |   code             mobile     user     |
   |-- & url --> user --> app --> login? -->|
   |                                        |
   |---------------- poll ----------------->|
   |<-------------- token ------------------|
   |------- use token to register --------->|

The auth code can be in QR form that the user scans with the mobile app, or it can simply be a code that the user will have to manually type into their mobile app.

In the aforementioned Google link, what they describe as device ID may be the UUID you mentioned, but it could also be a securely generated random string associated with your app.

There are guidelines in OAuth 2 and OIDC for utilizing shared secrets, which are only necessary for protecting credentials. In the workflow above since the mobile app is responsible for authentication, it has the option of using a shared secret with the Server (also known as a confidential client) or not (also known as a public client).

The question of whether you need authentication depends on where your Server resides. If it is on the internet, authentication is recommended - many OAuth 2 server libraries/applications let you integrate with various social media accounts so this may not be as painful as you'd think. On the other hand if the Server resides in the user's local home network then perhaps authentication is not necessary.

There plenty of client and server OAuth 2/OIDC libraries that will make your life easier. For the server side you can even make use of server applications (e.g. Keycloak) sporting features such as TOTP to improve security.


As stated, your approach would use the same key(since you do not use a key directory) for all apps. Thus getting the key from one device using the app would allow for decryption of the messages encrypted messages sent by all devices using that app. You should answer the following questions:

  • How are the keys being generated?
  • What is the intended security parameter(key length in bits)?
  • How easy is it to recover the key from the app?

Embedding the key in a qr code is definitely not a good idea as it can be easily recovered from its encoded form. The key should be kept secret.

Instead of a home grown encryption/authentication algorithm, it is far more recommended to use a security proven approach such as TLS.

  • No encryption will be done using the value of the QR code. As I stated in my question, I am using TLS/WSS for all communication between the TV app and the server, and the mobile app and the server. The UUID is strictly used to associate a TV device with the mobile apps that may connect to it. Any mobile app that knows the TVs UUID can send messages to the TV. The encoding in the QR code is simply for easily passing the UUID from the TV app to the mobile app (out of band, not over the network).
    – mmcdole
    Commented Sep 25, 2015 at 19:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .