By now we’ve seen plenty of projects that use an ESP8266 as a form of rudimentary access control: tap a button on your smartphone, and the door to your apartment unlocks. With the power and flexibility of the ESP, it’s a very easy project to pull off with minimal additional hardware. But what about if you want to get a little more serious, and need to support many users?
Rather than reinvent the wheel, you might want to check out the extremely impressive ESP-RFID project. It’s still based on the ESP8266 we all know and love, but it combines the diminutive WiFi-enabled microcontroller with a nice custom PCB and some exceptionally slick software to create a very professional access control system without breaking the bank. As the name implies, the system is geared towards RFID authentication and supports readers such as the MFRC522, PN532 RFID, or RDM6300. Add in a stack of Mifare Classic 1KB cards, and your hackerspace is well on the way to getting a new door control system.
The official hardware for ESP-RFID can be purchased through Tindie with or without an installed ESP-12F module, but as it’s a fully open source project, you’re also free to build your own version if you’d like. In either event, the board allows you to easily connect the ESP up to your RFID reader of choice, as well as door sensors and of course the door locks themselves.
On the software side of things, ESP-RFID should be able to handle about 1000 unique users and their RFID cards before the relatively limited RAM and storage of the ESP catches up with it. But if you’ve got that many people coming and going in your hackerspace, it might be time to update your systems to begin with. Incidentally, the project makes no guarantees about the security of the ESP-RFID code, and says that the system shouldn’t be used for secure locations. That said, you can run ESP-RFID without an Internet connection to reduce your attack surface, at the cost of losing NTP time synchronization.
If you’re not managing a few hundred users and their RFID cards, one of the more simplistic ESP8266 door locks might be more your speed. We’ve also seen similar tricks pulled off with the Particle Photon, in case you’ve got one of those rattling around the parts bin.
Ah ha, you have my attention, thanks for post, looking forward to comments :D
Great work on your device, looks clean!
I am finishing up my ESP32 NFC device with motion detection (for when you exit). You can find kicad files and code on my github: https://github.com/physiii/nfc-lock – I’ll push the blender model there once I run a test print.
The device connects up to the server (could be a raspberry pi) via websockets https://github.com/physiii/open-automation/tree/dev
Nice thing about my system is supports many devices, zwave locks, smart light switches (https://github.com/physiii/liger/tree/dev), cameras (https://github.com/physiii/open-automation-gateway), wifi thermostats, and ofcourse this mag lock controller.
This is a really well structured project using many best practices. Anyone interested in IoT Web Development should track this project and review the code.
I’m sorry, but I get tired of hearing these kinds of phrases: (On a secure door lock): “Not to be used for secure locations”. This is chicken sh** engineering. Stand behind your design. Ferret out problems in your requirements and fix them. It’s just poor engineering if you make a product billed as a solution for something, then say in fine print “by the way, don’t use it for it’s advertised purpose”.
I get your point but most people can build an ok access control system. This does not mean that it will be good enough for controlling access to locations needing more robust and secure solutions…
But every hackaday post is getting to be like this now, that’s the problem. Every day the article headlines sound more and more like generic click-bait, and the writing quality has gone down.
No project like this is ever going to give you a guarantee that it’s suitable for security, because it would take them liable.
Right in the MIT license (which this project uses) it says “The software is privided “as-is”, without warranty of any kind”. Going against that just so some commenter on the internet doesn’t call them a chickenshit doesn’t sound very wise.
A disclaimer is like “Enter at your own risk” it protects the designer if there were an issue and they were to be sued. This is standard practice. I work for an alarm company and we state that are alarms deter theft. It is just a fact of life if some wants to steal from you, they will find a way. Not bad engineering just common sense. The statement is for people who do not have that common sense.
I feel you, when I was started working on this project I did not know much about programming (both frontend and backend), I tried my best to achieve a secure transaction between a reader and a RFID tag, but ultimately I realized that is not possible with the hobby grade (cheap) parts.
The only option is using heavily hardened proprietary tags (and still they are vulnerable to some side-channel attacks).
This whitepaper dated February 15, 2019 https://arxiv.org/pdf/1902.00676.pdf
So basically it is not a design flaw rather RFID tech flaw, further read is here https://www.theregister.co.uk/2008/09/03/mythbusters_gagged/
Security section in README intentionally kept that way, to simply reduce the risk of newcomers to loose monetary value by using this piece of software.
I really appreciate the reply. I understand where you’re coming from and that you’ve looked into the tech. I realize nothing is bulletproof, and it sounds like you’ve researched the options. In my original gripe, I was referring to projects where it seems the maker wasnt really serious about their work.
Nice job on the project itself. It is what it is, and it sounds like you know well what it’s limits and capabilities are.
Thing is.
Keys are similarly vulnerable and a lot easier to photograph.
I’ve come to the conclusion that nothing is bulletproof. Compromise is always where it ends up.
Making sure my phone is home before I can unlock my back door via HASS.io for example.
Sure, someone could steal my phone… someone could steal my keys too.
I take it the lock on your house can’t be defeated by a skilled lock picker then. Good for you.
Sarcasm aside, that is exactly what you are saying:
Locksmith builds new kind of lock. Locksmith knows it can still be picked, but it’s still better for reasons xyz than the old lock. Locksmith admits honestly “it can be picked. Like any other lock.”
You shout “How DARE he be a a little chicken $hi÷!”
It’s a PROJECT not a PRODUCT. (Even if you can buy some boards on Tindie).
If you want product reviews, spend five minutes on Google and you will find hundreds of digital lock systems/devices far less secure than this one, delivered to your door in 48 hours or less.
That was my point though. How many of those systems have disclaimers telling the user not to use them for their stated purpose? I replied to the creator above buffering my original gripe a little, as it sounds like he really understands what the capabilities of this hardware are. I just don’t like the almost knee-jerk reaction our litigious society has formed in us as creators because we have to worry about being sued for everything. There are those who almost automatically discount the robustness of their work, all for the just-in-case scenario of someone hacking it. But does that fear really let people deliver their best? Does it let me as a user have confidence that they’ve tried their best? No and no.
“I just don’t like the almost knee-jerk reaction our litigious society has formed in us as creators because we have to worry about being sued for everything.”
Don’t blame the makers or hackers, blame the lawyers. If lawyers were not using their profession to analyze and deconstruct everything ever built or said so that they could charge more billable hours then disclaimers and statements to that effect would not be required in this age. In the end those statements need to be made because the majority of us do not have the money to put up to fight someone who is unwilling to think (and rationally analyze a product or situation) but has the money to pay a lawyer, so we end up with phrases and statements that remove general liability from most legal antics.
I hear what you are saying, I really do, but the makers and the hackers are not the ones to get mad at here. They are just trying to CYA because they would rather not loose their house due to someone with more cash than brains and a half decent lawyer.
“But does that fear really let people deliver their best? Does it let me as a user have confidence that they’ve tried their best? No and no.”
First, if stating a disclaimer is going to affect the quality of the project then the maker was never going to deliver their best to begin with. If a maker is going to deliver their best then they will do so with or with out a disclaimer.
Second, if a disclaimer is effecting your evaluation of a project then essentially you are a part of the problem. As i noted above, these types of disclaimers are due to people not being able to accurately evaluate a project on its merits and thus relying on lawyers to make up for their own personal mistakes. In one sentence you have pretty much stated that the disclaimer takes away from your confidence in the project while the statement doesn’t actually affect the quality or substance of the project its self. So essentially you have proven why the disclaimers are necessary in your statement about the disclaimer.
Sorry to destroy how you see the world…. But, as long as there is a transmission, there are ways to compromise it.
And most locks are even worse
If you store some gold and expensive art, this may be not the right solution. If you have a frigging garden shack, storing some tools, this is perfectly fine. If you have some machinery in your makerspace, which only some people should use, this could be perfect. So instead of having some key somewhere you just give cheap badges to those folks.
Too much to expect from a security project or even from a product. You should read through the disclaimer from the every commercial product and find that every disclaimer works.
>Mifare Classic 1KB cards
arent those the easily clonable ones? I remember watching presentation at CCC hmm 10 years ago? Oyster cards were based on this, and shitton of other cities transit infrastructure.
bam https://timdows.com/projects/using-a-mobile-phone-to-clone-a-mifare-card/
Good project ! We built a similar access control system for our maker space. It’s running on 8 tools and a kiosk. It’s on track to get open-sourced, but the code and doco needs some cleanup.. https://twitter.com/pdp7/status/1044568600655396864
I always cringe at this excuse for not open sourcing. Just put it on github, makes development so much easier. Code will always need to be refactored and documentation will always need updating.