Everything works well when I put the password in ASCII in the piaware-config.txt file. The generated wpa-roam.conf contains the password in the psk setting, and the quotes around it don’t cause problems.
For security reasons, though, it’s not wise to leave a password in plain text on the system.
However, when I use wpa_passphrase to get a 256-bit encoded version of the password and put that in the piaware-config.txt file without quotes, the generated wpa-roam.conf has quotes around the encoded value. However, wpa_supplicant throws a parse error when trying to bring up wlan0 because the psk string is an unexpected length. If I use nano to strip off the quotes in wpa-roam.conf, things work fine…until the next reboot when the quotes come back.
Is there some way to have wpa-roam.conf suppress generating quotes around a 64 character hex string, or have wpa_supplicant handle a quoted 64 character hex string psk?
FWIW while this is not unreasonable, it’s only really an issue if you are using the same password in more than one place (which is a bad thing!). The 256-bit hash is equivalent to a plaintext password for the purposes of authentication, so switching to that doesn’t help with the problem that if someone obtains it, they can authenticate.
This seems like a pretty significant security hole. Unfortunately, the credentials are for wireless login by the PiZero to a network. So, yes, the password is used elsewhere (by other devices that access the network). However, the network router also restricts access by MAC address, so that minimizes exposure to some degree (I’m betting a determined hacker can spoof a MAC address).
Is there an option to prompt during system boot for the wlan0 password or a key for decrypting an encrypted form of the wlan0 password retrieved from a file?
No more than the fairly standard approach of persistently remembering wifi passwords - I’d guess you do that on e.g. your phone, your PC, etc?
Not directly; you could set up an encrypted root FS or full-disk encryption which would achieve much the same thing (prompting for a key on boot).
However keep in mind that prompting for a key like this is only useful if your threat model is “someone is going to physically steal my Pi or its sdcard”. After the decryption has happened or the password has been entered, the passphrase has got to hang around in memory at least (and probably on disk, e.g. in a wpa_supplicant config file) while the system is running; so that is vulnerable to attacks that break into a running system.
To protect against attacks on a running system about your only option is to have a separate cryptographic processor which is physically tamper-resistant and holds the keys securely. The Pi has nothing like this and you’re getting into fairly specialized hardware if you want to do it. (Also, you may be overthinking it for a wifi password - if you’re relying on only the wifi layer to keep data secure, you’re doing it wrong, especially in the face of things like KRACK…)
I really meant “reused in a different context” but you could mitigate the password reuse by using WPA-EAP (you’ll need to roll your own config files for this, the piaware sdcard doesn’t support WPA-EAP as the setup can be quite complex and specific to how the AP wants to do it). Then each device can have separate credentials.
another very simple solution with additional speed and reliability advantage is what i did. i use an apple airport express that connects to my wifi network - and the pi is connected via 20" ethernet cable to the airport express.
Thanks for all the feedback / ideas. I’ll monitor KRACK’s patch status and research WPA-EAP.
At least for the short term I’ll use the router’s guest network capability and create an SSID for the guest network with it’s own unique password. It’s not perfect, but it will help limit the usefulness of the password to any hacker that may obtain it.
The previous incarnation of my PiAware system was a Pi 3 B, and it was tethered to a local switch with an Ethernet cable. Now I’m running it on a PiZero W. I could get a small USB hub and connect the antenna device and a USB-to-ethernet adapter to the hub, which would enable using your suggestion…and that’s definitely a fallback option if the guest network idea prevents SSH connections to the PiZero. I’ll also keep Apple’s AirPort Express in mind. The ASUS RP-N12 I’m using in media bridge mode with my TiVo Mini only supports 2.4G connections to its wireless router “source”. Thanks for your comment.
sorry i over-read that you use a zero! but yes this is a quite simple workaround for your security concerns - at least for pi2/3. but your idea with the guest-wifi should work too depending of your router capabilities you can setup firewall-rules that allow to communicate via ssh to the pi zero. i would think most of the cheaper wifi-routers/access-points can also be used as a simple wifi-client like my airport express. my additional finding was that the airport is less prone to loose the wifi connection over time than the raspberrys itself. an overnight auto-reboot helped me in the past when i used pis wifi
sudo crontab -e
0 5 * * * /sbin/shutdown -r now
this also helps a little security wise and always asks then for sudo password
sudo visudo
pi ALL=(ALL) ALL
if not needed you can disable this remote update setting
sudo piaware-config allow-auto-updates no
sudo piaware-config allow-manual-updates no
