[fergyfresh]

Do you encrypt the Bluetooth signal at all or it is all out there? That is the only thing that scared me, you obscure user information with a unique-id-key, but if I'm close to your office I can just get your key and get in the building.

[sratner]

We use a one-time token for each interaction. We don't use Bluetooth encryption, but the tokens are signed and cannot be replayed/transferred, so intercepting one is near-useless.

[j4_james]

Would this not still be vulnerable to a kind of man-in-the-middle attack though? I don't know much about the workings of bluetooth, so maybe this just isn't possible, but I was envisioning a kind of relay device that could capture an incoming signal, forward it to another device, from which it would then be rebroadcast.

The idea being you have an attacker standing in front of the door, relaying the bluetooth transmissions to an associate, who in turn rebroadcasts those transmissions to an employee who he has followed out to lunch. That employee's phone then responds exactly as if he were standing in front of the door.

I can't see why this wouldn't work, but I'm sure I must be missing something.

Obviously if the user is forced to confirm an ID request before continuing with the transaction this wouldn't be a problem, but I got the impression from the article that that wasn't necessarily required.