0

We are currently working on an IoT product & having a hard time coming up with a strategy to create a unique password for each device/unit.

I do understand that password based on a function of { serial number, CPU id, MAC address or timestamp } is not acceptable as per cyber practices as these are predictable due to the range constraint.

How about UUID of a partition to be used as password determination parameter as the range/space is 128bits compared to MAC(48bits), CPU ID(64bits) which are predictable given that we know the value of one unit/device, the other unit's ID shall be +/- 1 or 2 ?

I think UUID v4 is safe though duplicability is possible but very rare. But at the same time, I had come across this post mentioning that UUID is not to be used for security capabilities - https://versprite.com/blog/universally-unique-identifiers/

In our product, we are using an RW RootFS(UBIFS) file system and already enforcing the user to change the password upon first-time login. I would make use of a bash script which runs for the first time after factory-programming, will change the password of user 'X' and the script is owned by 'root' user and console login is disabled for 'root' so that nobody will be able to read the script file to understand the logic.

Is this an acceptable approach from cybersecurity point of view?

Any suggestions?

Baranikumar Venkatesan
  • 635
  • 4
  • 12
  • Without knowing more about your build and deployment processes, it's very hard to reply. Here is some questions to help you: _ Do you build 1 image per device or 1 generic image to be installed on every device ? _ Do you have a way to "configure" the device just after it has been flashed ? _ Do you have settings that vary between devices ? How do you manage it ? – binarym Aug 06 '21 at 08:53
  • Sorry for the gaps. The plan is to have a rootFS located in a shared FTP server machine which will be downloaded by the Uboot in the production line and flash the non-volatile memory partitions. – Baranikumar Venkatesan Aug 06 '21 at 10:36
  • Secondly, the plan is to have an RW(read/Write) RootFS image and wanted the script to change the password as soon as the first boot after factory programming is completed. Hence, it is one image for all units. Next, w.r.t configuring the device, it is a headless system and so local shell access is unavailable. As part of remote login using SSH, we would like to force the user to change the password. Finally, w.r.t settings all units will have the same settings and it is also packaged as part of the rootFS image. – Baranikumar Venkatesan Aug 06 '21 at 10:43
  • 1
    "I think UUID v4 is safe" But v4 UUIDs are just cryptographically random bits (plus a version flag). If you *can* use them, you could use any cryptographically random option. If you can't use them, why mention them? – CBHacking Aug 10 '21 at 08:28
  • 1
    I am missing why you would want a predictable password at all… why not flash in factory a specific random password generated by a pc that is not tied to the specific hardware, but just to the sticker holding said value… similar to how MAC addresses are flashed into hardware. – LvB Aug 11 '21 at 18:17

1 Answers1

-2

Given the fact that deployment is done using FTP and the assumption that the FTP is only living in your LAN and not available by internet, I would:

  • Generate a totally random password for each device that will be stored in a file which name is derived from the device MAC address, for example, 00:AA:BB:CC:DD:EE_initial_password.txt

  • Store all those files on the FTP alongside the firmware.

  • Modify my installation process (first boot?) so that it downloads the password file of the device and use it as the initial password.

For security, you can pre-hash the password in the file so that it isn't stored in clear on the FTP.

schroeder
  • 123,438
  • 55
  • 284
  • 319
binarym
  • 744
  • 4
  • 8