On 06/07/21 22:57, Michael Richardson wrote:
Alberto Bursi <bobafetthotm...@gmail.com> wrote:
> "unique" per-device passwords like most vendors are doing are low
security
> and relatively easy to brute force once someone has disassembled the
firmware
> and learned the algorithm used to generate them. They rely on obscurity
for
> most of their security, which is not really a thing for an open source
> project.
If they devices are shipped with such derivable passwords, then they violate
the California (now US) regulations, and also the come UK ones.
We can do better, and we are doing better.
Yeah, like most devices are also paying lip service to the other US laws
about not allowing "custom firmware" on the device because that could
make it go against radio power/emission regulations.
One thing is the law, one thing is actually enforcing it besides asking
nicely to the OEMs and trusting their "boy scout's word" that it's all
secure.
> They are also completely useless for DYI users that are just flashing a
> couple devices.
> With much less effort you can just ship a pre-made wifi config file with
your
> own settings and passwords, and that's what many are already doing.
Many devices have USB ports, and I'd suggest having a standard names .json
file that can be fed into uci in some way. I think that this solves a lot
problems. Have to make sure that vfat support is included in the base image
because... users.
And the idea mill keeps going. Not specifically just you but I've seen
these discussions run in circles so many times at this point that I'm a
bit jaded.
Imho this proposal does open more problems than it solves, and it is
non-trivial to implement, and it adds bloat in firmware images so people
will be unhappy.
And it is not universal, a lot of devices don't have USB ports.
The best idea I've seen so far is to just add the feature to add a
custom wifi config (possibly more than just wifi) in the image builder
website frontend framework thing made by Spooren (aparcar on github)
https://github.com/aparcar/asu
So that the user can generate an image with custom config from a point
and click interface, and when the device does the first boot it will
come up with an already configured wifi and network and whatnot.
This avoids bloating images, does not add any new attack vectors in the
device firmware, keeps the wifi security freaks happy as no wifi is
enabled by default, while still being friendly to the end user.
The only thing that could go wrong is that the user screws up the config
and locks himself out, device reset will not change the configs he
integrated, but I think Fallback mode can to be modified to always use
"openwrt default configs (i.e. 192.168.1.1 IP and device default ports
for LAN/WAN, no wifi enabled)" instead of whatever the user has shipped.
So that if the user does something wrong they can still get into
fallback mode and then reflash a new firmware with the right configs.
Not saying this is easier to develop or faster or whatever.
Just that imho this would be the optimal "solution" that satisfies the
most types of userbase.
-Alberto
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
