I would like to build a web application which has a trusted device feature.

  • What is required to store for recognizing the machine securely?
  • Can I safely store an encryption key (private) on the machine, so the user, doesn't need to input it when uploading data etc.?

What I've thought is storing a cookie on the users machine containing a 64 digit hash, which is matches an entry in the database stored with the user.

Is a cookie safe enough to store this hash or a private key?
Is there other security measures that should be taken?

The application will be built in PHP.

2 Answers 2


What is required to store for recognizing the machine securely?

I assume you meant reasonably uniquely and reliably - in which case, this is a hard problem. Made harder by the fact that any web application does not have access to the underlying hardware - just transient information such as browser version and IP address. Yes - you can get a lot of information about a system, e.g. as panopticlick does, but that information is changeable on demand.

Moreover, any of these metrics can change. Using CPUID? What happens if the end-user upgrades their processor? Your "trusted device" status disappears. That might be acceptable, or it might not - think Windows Activation.

In any case, in order to protect against token interception, MITM, replay and all other nasties of this sort, you absolutely must use SSL for this channel which brings me to:

He will still have to log in using password + username, however, he can ONLY log in from given machine.

This sounds like a use case for SSL client certificates, in my mind. The usual logic looks like this:

  1. Ask the browser for a client certificate.
  2. If you get one, check that cert, find the user DB etc and log the user in.
  3. Otherwise display the user login page.

I think what you're asking for, however, is a variation, in which if you find the certificate you present a login form and otherwise you display a 403.

That deals with the authentication side of things quite nicely. It also alleviates the need to store unique machine IDs and all the problems of generating them - although you could do so alongside this if you wished - and allows the user to designate trusted devices just by installing the certificate.

Can I safely store an encryption key (private) on the machine, so the user, doesn't need to input it when uploading data etc.?

Well, you've never got any guarantee of client side security on the web. You simply have to trust users are looking after their credentials.

The same goes for cookies. Remember, users may do all sorts of things to cookies, including clean them up unexpectedly. If you're building a web app and intend to do client-side crypto in JS, and you lose that key, the user is going to lose their data.

The alternatives are:

  • Encrypt the data on the server. As you've probably guessed, this means anyone with access to the server can get at that data - and no protection you put in place will help.
  • Encrypt the data on the client outside the browser, where storage is more reliable. When I say "outside the browser", I mean via a mechanism with proper persistent storage that is not cookies.
  • Wait for homomorphic encryption.
  • Design a way of extracting the key from the cookie and ensure your users can re-input it again as necessary.

Generally speaking, the standard advice for cookies (this includes your session cookies) over https is to use secure and httponly flags so that XSS does not work and the cookie does not leak.

  • Thank you for this. Your post got me thinking, and I think I've found a way to make it all happend, safely. :)
    – Kao
    Sep 27, 2012 at 6:49

General Rule: don't build your own auth. system. Instead use existing and proven solutions. You'll most likely fail otherwise, if you consider that stoneage-old experts keep failing when building such things. What you describe (Hardware auth + storing auth data in cookies) sounds like you're looking for some kind of claims based solution. Take a look at the SAML protocol and technologies which implement it like Microsofts Windows Identity Foundation. Make sure you're aware of the known weaknesses of the implementations.

  • I think you're overcomplicating what I asked. "Trusted device" doesn't mean he doesn't have to log in. He will still have to log in using password + username, however, he can ONLY log in from given machine.
    – Kao
    Sep 26, 2012 at 11:13
  • Still: don't do it on your own. It most probably won't be safe. Use standards. It's that simple. For "can only login from a given machine" sound's like cert based machine auth in combination wtih username+pw. Kerberos can do this for you. Storing private keys in cookies can easily be exploited as any domain matching the cookie domain can read the cookie content which opens all ways for MITM. What you want to do is let the client(!) gen. a priv. key with a given JS you send over to him and then only answer to your challange requests. Where to store it? In the users cert store, NOT the cookie.
    – omni
    Aug 8, 2015 at 10:19
  • This is an old question, however I will respond. You're quite far off track I'm afraid. It has nothing to do with cert based machine auth. The browser will already protect me using HTTPS. The only thing I need to store is a fingerprint of the user, so I can recognise him. It's not about building my own Auth system. IE. a hash in the browsers cookie store would suffice.
    – Kao
    Aug 9, 2015 at 22:23
  • So you're talking about a session cookie. If you want that just use a random number, remember it - e.g. in your db (make the field unique) and save it with the users cookie. no need to hash: it's a random number, not a secret. It's as safe as cookies can be (not very) - but common practise. Keept in mind that systems that use cookies will always require the user to re-auth (by pw) if the user tries to change any critical setting.
    – omni
    Aug 10, 2015 at 6:35

You must log in to answer this question.

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