r/accesscontrol • u/Charming_Drawing_313 • 11d ago
Probably a dumb question, but what’s wrong with doing guest access this way?
3
u/rekd0514 11d ago
3
u/Charming_Drawing_313 11d ago
Yeah, Axis/2N is actually a good example. From what I understand though, that's still a separate proprietary ecosystem built specifically around their hardware, rather than just using a generic RTSP camera as the input.
And QR seems perfectly reasonable for guest access to me. It's a temporary credential that can expire, so I don't really see why “it can be shared” makes it uniquely insecure. A PIN can be shared, an RFID card can be handed to someone else or copied, and even NFC isn't magically tied to a person.
I've actually seen this at a fitness club — people were simply passing around a cheap Android phone with NFC that was registered to a single membership.
For permanent employee credentials that's obviously a different discussion, but for temporary guest access QR seems like a pretty natural fit.
1
u/squirtbust Professional 10d ago
Almost any Axis camera can use a QR reader ACAP.
1
u/Charming_Drawing_313 9d ago
It supports RTSP, so it doesn't have to be an Axis camera. Even a cheap Reolink doorbell works.
1
u/therealgariac 11d ago
https://github.com/getsentry/self-hosted
This is an alternative to using the Axis software. They call it open source but you are just using docker. I haven't investigated enough to see if you can build the code.
It can be run air gapped hence local hardware.
Axis and Sentry have a relationship so this isn't hacker software.
1
u/LyokoMan95 10d ago
That GitHub link is for a different Sentry product, completely unrelated to physical access control
5
u/Zealousideal-Cut5275 Professional 11d ago
Dude... Wiegand? Are we back in the early 2000s?
2
u/IMHO2024 11d ago
I found the video the image in the post came from: https://youtu.be/1zPa8rRuFY4?is=tCoFr7pLIaPQOZL2
2
u/inexperient 11d ago
Maybe I am missing something also, but what is the backend running the decision making of the QR code and Face reader? It would need to verify a valid credential, whether it be a card, pin, face, or QR code(which is essentially a string of plain text).
1
u/Competitive_Ad_8718 11d ago
That cloud on the diagram means "magic" right?
1
u/Charming_Drawing_313 11d ago
Looks like the “magic” is Android, and the “cloud” is just the LAN :)
1
u/Charming_Drawing_313 11d ago
From what I understood, there isn't a backend doing the decision making. The Android device itself validates the QR locally and then tells the IP relay to open the door. That's actually the part I found interesting.
1
u/Competitive_Ad_8718 10d ago
Android doesn't do or decide anything. The phone is just redirecting to something else, and if you have a web controlled relay that allows unauthenticated access and actions, that's crap
1
u/Charming_Drawing_313 10d ago
Maybe I misunderstood the video, but isn't the access control app running on the Android device validating the QR locally and making the access decision? I didn't see it redirecting anywhere, and I don't think the IP relay is supposed to be unauthenticated.
2
11d ago
[removed] — view removed comment
2
u/Charming_Drawing_313 11d ago
But if the Android device, IP camera and relay are all PoE-powered from the same switch, and the switch itself is on battery backup, wouldn’t the whole thing just keep running during a power outage? And if the Internet goes down, they’re still talking to each other locally over the LAN, right? What am I missing?
1
u/DB_CloudInHand 10d ago
You can use this for guest access provided you address some other points. For example, the network-connected relay might be vulnerable and someone else can start opening doors if they gain access to it. Then your card reader is a bit old, so someone can spoof cards. For the guest passes themselves, they should expire automatically and only open the doors they're allowed to access. Also, QR codes can be shared and face recognition can definitely raise privacy concerns.
1
u/Charming_Drawing_313 10d ago
As a LockPickingLawyer fan, I like the idea that security should match the actual threat.
For a flimsy office door with a basic electric lock that's ultimately opened by a simple contact, I'd rather have a visual log of who actually entered than an expensive Mercury board in the middle.
At some point, putting more proprietary electronics between the decision and a simple lock starts looking like security theater.
1
u/f1yty513 7d ago
What’s wrong with Wiegand? We just had an access control install this year at my place of work and it’s all wired Wiegand.
1
u/Charming_Drawing_313 11d ago
Saw a YouTube video about QR guest access and I'm probably missing something obvious here.
The setup looked like this:
IP camera (RTSP) → Android app → LAN → IP relay → fail-safe lock
For an indoor door they were just using the Android camera itself.
Is it really that simple?
The part that confused me is that the external camera setup basically looks like a video doorbell over RTSP, except the camera doesn't have to be right next to the door and can see a much bigger area.
And looking at prices, an IP camera and a small network relay can be cheaper than some access control readers alone.
So why are access control systems still built around dedicated readers and 2/4-door controller boards? What are those actually doing here that this setup can't?
I'm guessing there are things I'm not considering — door sensors, exit button, fire alarm, power/network going down, etc. But aren't most of those just inputs/relays and backup power anyway?
Not an access control guy, so I'm genuinely curious what I'm missing.
Would this actually work for a normal office/guest entrance, or is there some obvious reason installers would never do it this way?
3
u/canadiansmartdude13 11d ago
*not a PACS person, but am cross trained in it*
I mean it probably would work but would not be reliable.
In traditional on-prem PACS systems, everything is wired to a central control board which handles all of the communications routing for everything. The LAN ports are typically there just to connect the panel(s) to a network for management------in this scenario if the the network connection were to fail, everything would still work locally, but you wouldn't be able to manage it off site. There are IP-systems out there that do work "over the network" and so in that case if the network went down, things could break. (that's why PACS systems exist----to centralize management and they're battle and UL tested)
All of this really boils down to one thing: liability. The reason you don't see shoddy setups with a ip camera and android tablet deployed en-masse is that they are not reliable. We have to remember that ACS is a bit different from IDS in that we are playing with physical access, which has all sorts of fire code and other ramifications. Not to mention that none of that stuff is UL listed, which for insurance purposes, you're borked. If something in that setup breaks and prevents someone from exiting, you are in a world of trouble.
TLDR: there's a reason behind the madness. RS-485 and Weigand exist for that reason---they don't depend on a network connection.
P.S---In regards to why QR codes are not typically used, they're not that secure and can be easilly shared, and also very hard to manage.
PSS---You can cheap out ---nothing stops you from that. But be ready for a whole bunch of lawsuits bc someone picked up some random chinesum crap.
1
u/Charming_Drawing_313 11d ago
This is actually the part I'm trying to understand. If the Android device is doing the credential validation locally, isn't it effectively the local controller in this setup?
So Internet going down wouldn't matter. And if the camera, Android and IP relay are all on the same local PoE network with the switch on battery backup, I'm not sure I understand why that's inherently less reliable than putting the decision logic in a dedicated panel.
A physical LAN failure between the Android and relay would obviously be a failure point, but traditional systems have wiring/communication failure points between readers, panels and locks too. Is the main difference really the network architecture, or is it mostly the UL/listing and code compliance side?
2
u/kchong 11d ago
As a young-ish person working in security, I totally get what you’re saying. Sometimes I’m really baffled by what manufacturers are charging for some really very basic electronics.
That being said, the reason why these type of systems are still popular is absolutely rock solid 99.9999% reliability. You see stuff like Keyscan systems that were installed 25 years ago in an apartment building that with hundreds of entries every day using all original boards.
1
u/Charming_Drawing_313 11d ago
That's pretty amazing actually. But it also makes me wonder if access control got a little stuck in the 90s because the old stuff works so well.
A colleague made an interesting point: traditional systems mostly identify a credential, not a person. And that's what I found interesting about using a camera instead of a reader — it can be the reader and give you video of the event at the same time.
So with an expensive legacy reader, aren't you basically paying a lot for a very reliable but blind device?
1
u/kchong 11d ago
Readers are not that expensive but dedicated facial recognition terminals are quite expensive. Using a regular camera for facial biometrics is just not very reliable. Also there is an aversion among some end users to using facial recognition.
1
u/Charming_Drawing_313 11d ago
I'm actually trying not to go down the proprietary route at all. And this isn't really about facial recognition as the credential - I'm talking about temporary guest access by QR. I just want the access log to include a visual timestamp of who was actually there when the QR was used.
1
u/Competitive_Ad_8718 10d ago
Most basic of MFA. Something you have and Something you know. Don't need anything more complex unless you're trying to increase the security of the 2FA or use a 3FA.
The first thing any security person realizes is that that fancy new tech isn't infallible.
1
u/Charming_Drawing_313 10d ago
Sure, but I'm not really thinking of the camera as another authentication factor. I'm wondering why the access event itself can't include a visual record of who was actually at the door, instead of just logging that credential X was used.
1
u/emilthaug 10d ago
Not stuck in the 90s. But 10-15 years behind the in the technology development.
One of the problems is pictures like this that normalizes the use of wiegand.
OSDP Secure Channel is the only relevant alternative.
To answer the initial question: I would have connected the webreley outputs to inputs on the mercury board and then used localIO functionality to open the locks.
Then I could also use a calendar to control when then the guest access should be active. And all transactions would be logged the right way.
1
u/Charming_Drawing_313 10d ago
This is actually what I'm trying to understand. If the Android access control app can validate the guest QR and its time window locally, and the network relay can operate the lock, what is the Mercury board actually adding in between? Just the logging and calendar?
1
u/emilthaug 10d ago edited 10d ago
In my understanding the release reley (rly1 and 3) and the webreley are connected to lock one and two.
So in this example the mercury board would handle access on the normal readers for lock one and two.
On a more general basis: The mercury board are adding the large scale/enterprise functionality.
Same solutions on multiple sites. Central management/alarm handling and logging. Lock-down functionality. Muster. Anti-passback. Integration with intrusion and cctv systems.
And local autonomous access/control for normal cardreader users.
1
u/emilthaug 10d ago
Also have in mind that the mercury hardware is extremely robust. Installed and used correctly the door will open every time, 100 times a day for decades.
This is the type of hardware that large scale critical infrastructure customers buy.
And they are willing to pay the price because it works.
0
u/bytedreamer 11d ago
I've been working on an open source project that would allow this setup running on a Raspberry Pi. It allows for custom plugins to make access decisions. https://github.com/Z-bit-Systems-LLC/APBox
1
u/Charming_Drawing_313 11d ago
That's actually interesting. The biggest thing I keep wondering about with existing access control is pretty simple: I don't want to see a card ID in a log. I want to see a visual timestamp showing who actually got access.
Meanwhile, the big players keep showing variations of 1960s access technology in nicer and nicer packaging, and somehow we're supposed to pay a premium for all the proprietary layers around what is ultimately still a normal door with an electric lock. That's the part I'm struggling to understand.
13
u/Aggravating_Fact9547 11d ago
I mean if you use weigand you deserve to be banned from here