Default Images and: California: SB-327 Information privacy: connected devices.

So looking at:

https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=201720180SB327

The unique password requirement applies in the case where “a connected device is equipped with a means for authentication outside a local area network” which a beaglebone does not unless the user manually forwards ports on their router, which could be argued as the user intentionally compromising their own security.

That being said, I still like option 2.

As for option 1: MAC addresses are visible over the network and are therefore not secure passwords. The serial number would be programmed into the EEPROM at the factory and is easily messed up by anyone messing with I2C, It’s also a big hassle to type in a serial number every time we flash a board and boot the first time.

Also, I thought we did away with root:root a along time ago in favor of debian:temppwd?

Best,
James

The unique password requirement applies in the case where "a connected device is equipped with a means for authentication outside a local area network" which a beaglebone does not unless the user manually forwards ports on their router, which could be argued as the user intentionally compromising their own security.

That being said, I still like option 2.

As for option 1: MAC addresses are visible over the network and are therefore not secure passwords. The serial number would be programmed into the EEPROM at the factory and is easily messed up by anyone messing with I2C, It's also a big hassle to type in a serial number every time we flash a board and boot the first time.

I agree, i don't like the hassle of a random serial number..

Also, I thought we did away with root:root a along time ago in favor of debian:temppwd?

root:root is there, but "locked" out from ssh.. So technically it's
there, and could be exploitable through other software...

Regards,

On Fri, 5 Oct 2018 14:26:00 -0500, Robert Nelson
<robertcnelson@gmail.com> declaimed the
following:

So looking at:

https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=201720180SB327

**********************************************************************************************************************************************
SECTION 1. Title 1.81.26 (commencing with Section 1798.91.04) is added
to Part 4 of Division 3 of the Civil Code, to read:

TITLE 1.81.26. Security of Connected Devices

1798.91.04. (a) A manufacturer of a connected device shall equip the
device with a reasonable security feature or features that are all of
the following:
(1) Appropriate to the nature and function of the device.
(2) Appropriate to the information it may collect, contain, or transmit.
(3) Designed to protect the device and any information contained
therein from unauthorized access, destruction, use, modification, or
disclosure.

  I'd probably take this from a liberal reading of (a-1)... Interpreting
the "nature and function" of, for example, a fresh BeagleBone Black to be a
component usable for building a "connected device" but, as received,
basically functionless -- other than SSH, the Cloud9 webserver (I ignore
the NTP sync as that isn't an inbound connection). It doesn't really
"collect, contain, or transmit" anything out of the box; and if SSH is
available from outside the local network, I'd consider that a matter for
the local network administrator to secure.

  If they are sold as, say, part of a networked weather reporting
station, the responsibility for securing the "weather reporting station"
would be on the packager of said station.

  If that isn't sufficient -- I suppose one could go the Windows route,
and rig images so that first boot /requires/ one to create a user
account/password. Which, of course, means first boot will have to have some
console access -- and likely annoy anyone deploying multiple units (the
Peoples Republic of CA likely will tack on some requirement that one can
not reuse account/password <G>)

So to meet (1), should we just use the "serial number" on the side of
the board, or mac address, etc...?

I don't recall how that sticker is generated but if the board "knows"
that value than I think this would be fine. MACs have the issue of
broadcasting themselves over networks. I believe the point of this
legislation, and IANAL, is to prevent the mass baby-cam like spying
where all credentials are default and never changed.

Thus, while the password is just a sticker on the board, it solves
this requirement.

A more user-friendly one is perhaps a QR code somewhere but has
logistical and supply-chain complications.

Or to meet (2), require use to change default password, the problem,
#2 States: "before access is granted"... My initial fix is "after
access is granted"...

I would agree.

Or Option 3: ship the boards blank... :wink:

Would also meet the requirement, but my wink-detection is working I
think, so from a usability perspective, probably not ideal.

and what about "root:root"... do we nuke "root" by default and just
let the user init it...

Are you asking if the root password should be root and/or if we should
allow root over ssh?

If this was a server (and sometimes beagles tend to be), I think best
practices would be:

- no root login (over ssh or serial)
- ssh via pubkey only

But sometimes the beagle is just this hardware hacking tool, ya know?
And in this case it's a big pain to remember the unique password when
all you want this thing to do is dump a SPI flash and return the
results.

The problem is when a hardware-hacking beagle gets plugged into the
internet with default passwords and then shuts down half the Internet
so somebody's minecraft server gets taken down.

I'm not sure what to recommend. I could see a path where there is the
sticker password and then on first connect there are some init steps
depending on use case. But if you connect with the browser first
(which admittedly, I never do) then this flow probably wouldn't work.

So, changing the default password to the sticker value would otherwise
meet those requirements I think.