2 factor authentication for web app login - after reading some of the security comments, I think a simple 2 factor (as default, but with opt-out) would be a good start in securing our farmbots. I’m a newb to FarmBot, but a cyber wonk at my day job. Also recommend OWASP for top 20 vulns.
(NOTE: As an Open Source software package, FarmBot allows security professionals to perform independent research on any of our software packages. You are welcome to perform such research. If you do find an area of concern, we ask that you follow responsible disclosure practices.)
@cris You bring up a great point. We’re actually planning to do a big revamp of our current token system, and addition of two factor auth is included in those plans. With that being said, we are not aware of any exploits or vulnerabilities with the current token system (although adding 2FA would definitely strengthen things further)
Here’s how we do auth today:
- On the device, we use refresh tokens to allow the device to operate for extended periods without risking a service interupption to the device. The token is revokable via a password reset.
- On all other services, we use JWT Bearer tokens. Like a refresh token, it can be revoked via password resets. The default expiration date is 40 days from issuance.
- We do the usual salting and encryption of passwords via Devise library to prevent user password exposure in the event of a data breach.
We have not started the 2FA migration yet, but I think this is a good time to talk about some of the challenges that makes FarmBot unique from a security perspective (your feedback is appreciated):
- A lot of IoT products will flash a crypto module with a secret before leaving the factory. FarmBot will always allow end users to build their own device, so that means that in many cases, there is no “factory”.
- I really like time based OTP (I’m particularly fond of Authy), but unfortunately, older FarmBot models do not have a reliable realtime clock, which would require users of older devices to add a hardware RTC module.
- It is not a desktop application. Although this sounds fairly obvious, there are a number of really good security solutions out there that assume the end user has access to a web browser, which is not the case for a Raspberry Pi running unattended in an outdoor/embedded environment.
Because of that, we need a 2FA solution that:
- Lends itself well to an unattended embedded system (ie: does not lock the device out after a certain time period or require user intervention).
- (Ideally) does not require the use of a real time clock.
- Does not require the use of factory installed security such as a shared symmetric key that is burnt in at the factory (since some users don’t buy their electronics from us)
- Does not require the use of DRM or other proprietary software that restricts the rights of end users or prevents people from running an on-premise server due to licensing fees/restrictions.
With this in mind, I am interested to hear ideas from the community, particularly with regards to how we can implement 2FA. Have you seen any 2FA strategies that meet the needs of the situation described above? Again, 2FA support is still a work in progress, so we have not decided on a solution and are open to suggestion. I look forward to hearing your feedback. You may message me privately if you feel there are sensitive matters that must be discussed.