[denismars]

Very excited to get this off the ground - we've got some big ideas where this can go - ultimately we want to support many use cases, but before we get there we need to battle test it in the market - would love any feedback, and if you want to get involved reach out to me denis at proxy dot co

[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.

[alexandersingh]

Congratulations, mate! :)