We're trying to create a digital ID to replace UK Passport/driving licences for entry into licensed premises, but need to ensure it cannot be faked (or failing that, the barrier to faking it needs to be very high).

Here are the restraints we need to deal with:

  • We need to be able to implement it on Android and iOS
  • Door supervisors don't like to use technology on their side, so mobile to mobile communication solutions are not possible, and anything that requires more than a minor effort on their side is likely not an option either
  • To show the ID, the users will scan a static QR code around the neck of the door supervisors, which will display the ID on the user's phone until dismissed.

Assume sufficient authentication is a prerequisite, and that we can make use of users facebook data if necessary.

Traditional IDs use a hologram to prevent forgery, and despite this being relatively easy to fake in many cases, it's considered a sufficient level of security for many physical ID cards. We could use gyroscope and accelerometer data to create something that looks and moves like a hologram, but our fear is this could be faked, either in a web app in the browser or on an app on a rooted iphone/sideloaded onto android.

We've also considered using physical security tokens as a solution, whereby the door staff have a physical security token with the QR code. The user would scan the QR code which tells the app which venue they are at as well as what the ID of the security token is. The app could then speak to the security token digital authentication server and display the matching token code for that ID - which would should match and prevent forgeries. However due to token drift over time would need regular manual synchronisation, and so is not a perfect solution.

Any ideas?

  • 2
    If you're not syncing something, it can be faked. For example, if you have a group trying to enter, one of whom has a valid ID. They could have software on their phone to mirror whatever it displays to other specific devices, such as those belonging to the other members of the group. If it's running on a device controlled by the potential "attacker" in the scenario, you're quite limited in what you can trust...
    – Matthew
    Jan 26, 2017 at 12:25
  • Mirroring others valid ID may not be such an issue as there will still have to be a physical appearance check by door supervisors, comparing the user photos on the ID to the person holding the phone, so we're more concerned about a scenario where attackers could input their own photos of themselves to a fake version of the app which matches the apps format exactly
    – Taro
    Jan 26, 2017 at 12:29
  • 2
    That's trivial though - it's running on the user's device. They control what it outputs. You can always copy the appearance of something, given sufficient effort. The difficult bit is showing a number which matches one generated using an unknown key, which is where you need some communication between the systems.
    – Matthew
    Jan 26, 2017 at 12:37
  • @Matthew - any suggestions for how this could be done without requiring a smartphone on the doorstaff side also? Are you aware of any other smaller devices that would solve the problem?
    – Taro
    Feb 27, 2017 at 13:32

2 Answers 2


the users will scan a static QR code around the neck of the door supervisors, which will display the ID on the user's phone until dismissed.

If "the user" is the subject of verification then you cannot create a system with any level of accuracy/trust based around this constraint. The subject controls both the identity data and its processing. Even if the door supervisors were technologically literate, they cannot trust information displayed on someone else's device.

Assuming that you have a database of customers and verified ages (or more correctly dates of birth) then the only way I could see this working would be for the customer to direct the door supervisor to the record (e.g. by presenting a QR code) which the door supervisor could resolve on their own device. This still needs a mechanism for tying the record back to the person standing in front of them - the most obvious and least intrusive way to do that would be to present a picture of the customer on the door supervisors device (there are lots of different ways to resolve this last part). But this is going the route of solving an impossible problem by changing the constraints.


Why not move the verification server side?

Assuming you have a method of verifying the users identity, all that needs to be done is the scanning of a QR code around the door supervisors neck. What then happens is the users app will contact the server, with which it has already authenticated, and provide the server with the ID code of the door supervisor.

The supervisor would only need a tablet mounted at their desk, which would receive the profiles of people who are trying to access the building, allowing the supervisor to glance over the data before opening the door. You can set it up so that the supervisor doesn't need to interact with the device, it simply automatically pops up the next request.

This is secure because the user information would already be verified and stored safely on your servers. It also requires minimal effort on both parties as all the user needs to do is scan the code and the supervisor choosing to allow them in.

You could also expand this later on to include logs of who entered at what time.

Other than that, you don't have many options. As stated in the comments, any user side verification can be faked.

  • I've since left the company I that was trying to solve this problem, but yes this was a solution we considered. Issue is in the "tablet mounted at their desk" part - they would have to provide a tablet to every venue (expensive!) and also many doormen are standing at the door of a venue where there is no desk for a tablet, and so I think a phone around the neck was probably the better option here as theyre cheap and portable.
    – Taro
    Jul 20, 2017 at 12:10

You must log in to answer this question.

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