1

My team is currently working on an IoT product and we're having some issues thinking about a good way to create a unique password for each device.

Each device runs on GNU/Linux and we have an application that generates an image for every device we ship. This application is written mostly in bash.

Since each device has a unique serial number we thought about using it as part of the password generation, maybe as a seed.

Any suggestions?

  • Would this password only be used as a default password and be expected to be changed by the end user, or is this a backdoor password for your service team to use? – Allen Howard Feb 28 at 19:09
  • Yes, it would be used as a default password (unique on each device) and we'll advice our users to change it. – steuck92 Feb 28 at 19:20
  • 2
    I'm not sure why a randomly generated password would not work. What would using the serial number as a seed give you? What problem are you trying to solve? – schroeder Feb 28 at 19:44
  • We were curious if there was something we should or shouldn't do. – steuck92 Feb 28 at 21:28
  • 2
    Don't advice your users to change the password; force them. Most users don't care about or read your advices anyway. If you force the password change before the device is ready for use, there's no matter whether the initial password is fixed or unique. – Esa Jokinen Mar 1 at 15:01
0

Creating the password:

Don't use serial numbers, or anything else that is going to be within a predictable range (so this also rules out timestamps, MAC addresses, and so on) for anything related to password generation. If the password doesn't need to be entered frequently, there's no reason to go with anything other than pure entropy from a secure random number generator (base64-encoded so you can print it and users can type it).

dd if=/dev/urandom bs=9 count=1 2> nul | base64

72 bits of high-grade entropy is actually overkill if this password cannot be remotely accessed over the Internet. In that case, anything down to about 6 bytes (change the bs parameter) will work fine. The base64 encoding will add 1/3 the to the length (9 bytes gives 12 characters) and the characters will be ASCII upper-case, lower-case, digits, and the +, /, and = characters (or you can trim the = characters, they are just padding), so make sure you use a font that distinguishes all of those characters clearly (for example, o, O, and 0 should be recognizable, as should 1 and I). You could optionally use another encoding that restricts the character set to exclude hard-to-distinguish characters, or just pipe the output through tr to, so, replace the five characters listed above with @, #, $, %, and &.

If you want the password to be easy to say to another person / easy to remember, you could use the Diceware / XKCD method of generating passphrases (4+ randomly-chosen reasonably-common words). They're longer, but actually easier to type in most cases and definitely easier to tell somebody else to type, and still quite secure.

After initial setup

A password/passphrase generated this way is actually going to be more secure than one that the vast majority of users would come up with on their own, but it's still bad practice to leave the password that was set at the factory (and therefore could have been seen by another person) on the device longer than needed. Forcing the user to change the password is recommended, and you definitely need to give them the option to do it.

1

Why not make the user create a password when the device is booted for the first time? Or you could also create a random password for each device.

0

Using serial number as a password is a big NO unless your goal is to make password guessing for outsider easier. It's equivalent of using your street address or name as your personal password.

  • 4
    OP did not say that the serial number would be used as the password. – schroeder Feb 28 at 19:45
  • Hi, you deleted your post about copying an InfoSec policy, but I thought you'd find this useful – paj28 Mar 1 at 16:41
0

Why not hash the serial number to get the default password? It's easy to implement in bash and scales well for all your devices.

  • Serial numbers are... serial. They can be predicted. If the device is at all remotely accessible, this is a terrible way to generate the default password. – CBHacking Mar 1 at 22:56
  • They can be, and the hashing can be predicted. But this is the default password we're talking about. It should be changed anyways. This gives a fairly good amount of protection. – Crumblez Mar 4 at 2:17
  • 1
    It is strictly worse than just using random values. Even leaving aside the fact that a lot of people don't change their passwords, why would you use a predictable value at any point in time? Cryptographically secure random bits are dead cheap these days (and you don't need much per device) so there is really no reason to have even a short "between when the device is plugged in and when the user gets far enough in the setup to change the password" period where an outsider could guess the password. – CBHacking Mar 5 at 9:02
  • Yeah I think I was overthinking it. A random value would be just as easy to implement and offer more security. – Crumblez Mar 5 at 14:37
-1

OPTION 1 : Physical access

If you need a physical access to device which it ask for a password, you can use Pluggable Authentication Mechanisme.

apt-get update && sudo apt-get install libpam-usb pamusb-tools

STEP 1 - Plug your USB and

sudo pamusb-conf --add-device yourUSB
Please select the device you wish to add.
* Using "SanDisk Corp. Cruzer Titanium (SNDKXXXXXXXXXXXXXXXX)" (only option)
Which volume would you like to use for storing data ?
* Using "/dev/sda1 (UUID: <6F6B-42FC>)" (only option)
Name            : MyDevice
Vendor          : SanDisk Corp.
Model           : Cruzer Titanium
Serial          : SNDKXXXXXXXXXXXXXXXX
Volume UUID     : 6F6B-42FC (/dev/sda1)
Save to /etc/pamusb.conf ?
[Y/n] y
Done.

STEP 2 - Add user

sudo pamusb-conf --add-user user_name
Which device would you like to use for authentication ?
* Using "MyDevice" (only option)
User            : nom_d_utilisateur
Device          : MyDevice
Save to /etc/pamusb.conf ?
[Y/n] y

STEP 3 - Check if everything is OK

$ pamusb-check nom_d_utilisateur
* Authentication request for user "nom_d_utilisateur" (sudo)
* Device "MyDevice" is connected (good).
* Performing one time pad verification...
* Access granted.

OPTION 2 : Remote access

Depending what services are open to your device (SSH, Telnet, ...) and what communication protocols (WIFI, Bluethooth).

Supposing the device have WIFI device and ssh deamon service activate. You can access by login over ssh by checking login/password

First check if ssh are installed and the service is started

$ apt install ssh
...
# service ssh start
ssh.service - Open Secure Shell server
Loaded: loaded
Active: active (running)
---[SNIP]---

$ ifconfig wlan0

On the client side, connect with its name host and ip

# ssh nameIOT@IPLAN

Or you can generate keys pair for accessing via RSA-encryption, which give a better security. Think about ip static if needed...

Generate random password

date +%s | shasum256 | base64 | head -c 32 ; echo

Output 32 length

another way based UUID, here I use the uuid of disk sda1, but you can use your serial number of your iot

vol_id —uuid /dev/sda1 | shasum256 | base64 | head -c 32 ; echo

Or by using openssl

openssl rand -base64 32
  • Maybe I'm missing something, but this doesn't seem to answer the original question about password generation. If you're suggesting an alternative to passwords then you should add more content to your answer explaining this. – PwdRsch Mar 1 at 20:16
  • @PwdRsch voilà ! – s4r4z1n Mar 1 at 20:59

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.