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?

  • 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 6, 2021 at 8: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. Aug 6, 2021 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. Aug 6, 2021 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, 2021 at 8: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, 2021 at 18:17

1 Answer 1


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.

  • 2
    This would let anyone who knows the MAC address of a device easily acquire its password hash. Aug 11, 2021 at 4:19
  • The FTP server used to flash the first firmware on a device is usually not directly avaible to internet users. I wish it's OP case.
    – binarym
    Aug 11, 2021 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.