How We Protect Our Beacons / iBeacon Against Piggybacking and Hijacking

Update 2016: This article is out of date. We released Kontakt.io Secure, the world’s only complete suite of beacon security technology. Learn more about the new beacon security features here.
There are many exciting new uses for Beacons / iBeacon popping up on a weekly basis. This explosion of growth has understandably created some security concerns about how businesses and organizations can secure their Beacons. Today, we will address that concern.
The first thing you should know is that Beacons themselves don’t include any sensitive information. All they do is broadcast a continuous radio signal with their UUID, Major, and Minor values. The major concern with this is when a malicious party (or an over-zealous competitor) attempts to use these identifiers to send messages to customers as they interact with your Beacons.
Here are the security measures we use to ensure that this doesn't happen:

We use a 3-tier password system.
After ordering your Kontakt.io beacons, an account is automatically created for you to let you access our Content Management System (CMS). You will be asked to create a password (using our password reset function), so only you will be able to assign content to your Beacons.
In addition, each Beacon also has two passwords; a Master password for bigger changes like updating the firmware, and a Beacon password for changing properties of the individual Beacon. The hijacker / piggybacker needs all three to be able to send messages to your customers.

Download our guide to learn how to keep your infrastructure up and running.

For example: all changes to a beacon’s identifiers (like UUID) must be done using the Admin mode of our Kontakt.io (or other authorized) app, and this is only possible while that beacon is in proximity of the mobile device i.e. physical access is required.
Furthermore, the content you send to customers is triggered by the individual beacon’s advertisement package, which is managed in the password protected CMS. So even if someone was able to scan for the identifiers and try to clone your Beacon, they would still be unable to change the triggered content without also having access to the CMS.
Optional encryption is also included.
Some Beacon / iBeacon vendors choose to secure their hardware with encryption only. While encryption can be effective (as one of several security layers) it can also cause a lot of hassle for some use-cases, or due to strict import rules. We believe customers should have the option (rather than be forced) to use encryption, as is most suitable for their needs. Therefore this option is available, but not as a default.
Final thoughts.
All in all, as long as you take good care of your passwords; it is highly unlikely that someone will hijack or piggyback on your Beacons. While no security system is perfect, the key to best-practice security is to always make it as difficult as possible for someone to break in (think of it as an effort vs. reward ratio).
Even with all these security layers in place, we are still working hard on developing even more sophisticated tools for our customers. Our next generation of Beacons for example, will include some exciting new features that better secure your Beacons / iBeacon. Stay tuned.
Thoughts?
Share them on Twitter and Facebook.