I want to allow users of our website to restrict access to their account from devices they have explicitly authorized. This will be checked at the connection and each time the IP address changes.

To do this, I need to identify the device and I must avoid another device being able to pass for an authorized device.

I could, for example, save a UUID in a secure cookie (flags: httpOnly + secure) that the server (in HTTPS + HSTS) could check. However, via an MITM proxy, the attacker could potentially discover the token and use it as many times as he wants on several machines and even when the user is no longer connected to the infected proxy.

I think it is possible to reduce the risks by coupling this technique with a web push API call. This requires of course a browser that supports it (~ 80%) and the user agrees to receive our notifications. The idea would be that the server receiving the UUID of the cookie, sends a push notification containing a random token to the device, then the device forward the token to the server to prove that it is indeed the authorized device .

This method does not solve MITM proxy attacks, but once the person is no longer behind this infected network, the attacker can no longer spoof the device identify.

Push notifications are encrypted, but I can also encrypt[EDIT: obfuscate] the sent random token by a simple XOR operation with the UUID value of the cookie as the key.

Do you have more safest way to identify a device without requiring human action please?

[EDIT: I precise, the subscription to push notification is done only one time, and could be requested to be done from a secure network, like at home, to prevent MITM proxy while the subscription.]

  • If an attacker is able to MITM your HTTPS connection then no method is going to be secure, whatever identifier you use the attacker can just copy and spoof/replay. But you cannot MITM HTTPS without compromising the end-users device to install a malicious root CA certificate, and if the device is compromised you have lost anyway. Why is this something you are worried about? Oct 6, 2017 at 16:26
  • I known this not solve the moment where the user is connected to an MITM proxy. But this solve him when he's no more connected to the infected network, because the attacker couldn't spoof anymore the identity of the device.
    – lakano
    Oct 6, 2017 at 17:00
  • I realize this sounds like a nitpick, but to be clear what you have a misnomer here: "I can also encrypt the sent random token by a simple XOR operation with the UUID value of the cookie as the key." What you propose isn't encryption but simple obfuscation. Very big (and important) difference. Oct 6, 2017 at 17:59
  • @ConorMancone Sorry for my english, it's not always easy to use the good words.
    – lakano
    Oct 6, 2017 at 18:05

2 Answers 2


I'm not sure if your suggestion of push notification is really going to help. For that to work the client still has to "subscribe" itself to the push notifications. What would stop a MITM from intercepting the end-client's request to subscribe to push notifications and subscribe itself instead?

The internet is inherently built around the concept of "anonymous" clients initializing conversations with servers. It is possible for a client to uniquely identify a server via SSL certificate validation, but nothing about the internet is really designed to do the opposite.

What it really boils down to is that if doing what you wanted to do was easy and fool-proof, then every server everywhere would do it and stolen credentials would be a thing of the past. That obviously isn't the case though.

  • Hi Conor, thanks for your answer. Before user subscribe to push notification, we could ask him to be connected to a safe network. Web Push API is recent and not yet supported by all browsers, this surely explain why others experts don't yet use it like my suggestion. But if you have a safest way to suggest, I'm open :)
    – lakano
    Oct 6, 2017 at 16:50
  • Regarding doing the opposite, you can use TLS client auth, but that requires setting up a key and certificate for the user so can't work without human action Oct 6, 2017 at 17:08
  • @SeanBurton It's a good idea yes, this could be done when the user tell us which device need to be authorized. But, is the TLS cert could be intercepted by a MITM proxy and used later by the attacker ?
    – lakano
    Oct 6, 2017 at 17:26
  • 1
    @lakano To be frank, I don't think it is possible for your off-the-cuff client-authentication method to be more secure (or even as-secure) as actual client authentication designed by the experts. Not to say that we should defer to experts because they are experts, but when it comes to security and encryption it is very easy to get things wrong. Again, reiterating my question: if someone is vulnerable to MITM what will stop the MITM from intercepting your push notification-subscription request and subscribing themselves instead of the client? I don't think your plan is any more secure. Oct 6, 2017 at 17:58
  • 1
    @lakano What makes you think that a user knows whether or not they are connected to a safe network? You can't even trust a user to select a secure password, and there are plenty of MITM attacks that leave the victim completely unaware. For that matter, you would be better off asking them to connect to a "secure" network in order to complete the client-side SSL exchange via something like cloudflare. Oct 6, 2017 at 18:17

I answer to myself after some research.

Client TLS certificate can't be used while browsers will not permit to easily import the certificate. Currently, most browsers require complex human actions: download the cert file, go in settings, advanced, certificats management, import, select the file to import. It's a very bad experience for the user, we can't ask the user to do this after sign up on our website.

But, we can have something similar, with Web Crypto API (all functions aren't fully supported by all browsers, that require polyfill). We generate asymetric keys public/private when the user request the autorisation of the device.

Then, in the server-side, we can save the public key of the device and the associated hash (SHA256) of the public key as a « deviceID ». Each time the user make a request to the API, we add in the header the deviceID and a proof with a signature, the request hash signed by the private key of the device (we will add a nonce to prevent replay attack).

In the client-side, the keys are saved encrypted by the user password inside IndexedDB. Of course, if the user clear the indexedDB data of the site, the autorisation for this device is lost.

  • This is only mildly more secure than a standard session token. If the private key is stolen then a malicious actor can act as the authorized device and your system won't know the difference. The only reason this is even slightly more secure than normal device authentication is because you don't have to transmit the private key, which gives less points for failure. However, in the event of an XSS attack (which is one of the most relevant security concerns), your device authentication is completely vulnerable. This just makes you think you are more secure while giving you more code to manage. Jan 29, 2018 at 18:56

You must log in to answer this question.

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