brickbots / PiFinder

A plate solving telescope finder based around a Raspberry PI and RPI HQ Camera
Creative Commons Zero v1.0 Universal
144 stars 27 forks source link

More secure WiFi setup #179

Open jscheidtmann opened 1 month ago

jscheidtmann commented 1 month ago

As I am going to go to a star party in September, I was wondering how to give PiFinder a better default security posture:

First, the documentation should recommend to attach an Ethernet cable during the build phase to setup local WiFi client access. This avoids entering WiFi passwords over unencrypted channels, as the documentation currently recommends.

Second, if the unit activates access point mode, it should:

What do you think?

dnlombard commented 1 month ago

Yes, /recommend/ Ethernet. There could be much more to it.

Hotspots typically display SSID & PW either on the home screen or from 1 button press. The former is nicer when the screen will blank after a timeout.

WPA2 is fine.

On 6/2/24 07:25, Jens Scheidtmann wrote:

As I am going to go to a star party in September, I was wondering how to give PiFinder a better default security posture:

First, the documentation should recommend to attach an Ethernet cable during the build phase to setup local WiFi client access. This avoids entering WiFi passwords over unencrypted channels, as the documentation currently recommends.

Second, if the unit activates access point mode, it should:

  • attach a random number (5 decimal places from 00000-99999) to the SSID, such that PiFinders in the vicinity use different SSIDs (at least a collision is rather unlikely),
  • At least WPA2 should be configured on the WiFi, using a random password of 15 or 20 places consisting of characters a-z0-9, in groups of 5.
  • This password should be displayed after boot up and be part of the "main" screens, i.e. it must be accessible from pressing "A" multiple times (screen can be deactivated in settings)
  • This configuration shall be created once and be stored and reused by each boot up,
  • until a new configuration is generated by the user in settings.

What do you think?

— Reply to this email directly, view it on GitHub https://github.com/brickbots/PiFinder/issues/179, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACLERHL7276HKNNDZCGRC6LZFMTOXAVCNFSM6AAAAABIVDP7HWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMZDSNRYGUYTMNY. You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- dnl

brickbots commented 1 month ago

Thanks @jscheidtmann for thinking about this and for your passion about security! I'm on-board with all of your thoughts, except the suggestion of using an ethernet cable. It seems if your other suggestions were implemented, the need for this would be removed, but I may be missing something.

I have some hints/suggestions for anyone who wants to take this change on, but in the meantime, here are a couple things which can help anyone who is using a PiFinder at a public event:

These two steps will discourage/prevent any accidental and general mischief. A determined attacker can still do packet collections and such, but the cost/benefit for this attack would be pretty low as there is not much value to a compromised PiFinder.

A quick/easy software change could enable manual mitigation of the remaining risks: Allow the setting of a WPA password on the Access Point network via the web interface. Yes, initial configuration is done in the clear, but the chance of an attacker being in the right place at the right time to take advantage of this is, seemingly, quite small.

BUT, better is better and your suggestions are very good ones that should not negatively impact the usability very much. For anyone who wanted to take a run at implementing some of these, here are some thoughts:

1) The current PiFinder image is based on an older version of Raspberry Pi OS (Bullseye). There is a branch where work has been started to port the software to Bookworm. I mention this as the network subsystems have changed significantly between the two so making these changes on Bullseye will require some re-implementation on Bookworm. Might be worth targeting the Bookworm branch and helping to accelerate the transition there.

2) There is not any mechanism or hook currently for 'first time boot-up' which could be used for generating the random AP network config. This would be pretty useful though and there are probably a couple of ways to set this up so that it runs on first boot along with the SD Card volume expansion 🤔