@MSGID: 1@dont-email.me> ffb448fb
@REPLY: 0Q9oz@news.chiark.greenend.org.uk>
2161f3de
@REPLYADDR pozz <pozzugno@gmail.com>
@REPLYTO 2:5075/128 pozz
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
0Q9oz@news.chiark.greenend.org.uk>
@TZUTC: 0200
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.14.0
@TID: FIDOGATE-5.12-ge4e8b94
Il 30/08/2023 18:14, Theo ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> This is the first time I release an embedded device based on Linux OS
>> (it runs on iMX6ULL CPU).
>>
>> This device will be produced in a medium scale (100-1000 pieces). I`m
>> thinking about root password: should it be the same on all the devices,
>> or should it be different?
> 
> If it`s the same and network accessible, it`ll get added to databases of
> root passwords that get used for exploits.  Doing that is also forbidden by
> law in some jurisdictions (eg UK).

The device will be connected to Internet, but I`m going to disable SSH, 
because the application and the user won`t need it.

The password here is the **root** password, where root is the Linux root 
user, not an admin user.

The device runs a web server and the user can interact with it with a 
standard web browser. The web application is protected by a login 
(username and password), but the "web users" are different from Linux 
root user.

The default web user will be admin/admin and hopefully the user will 
change the password at the first login.

This post refers to Linux root user that isn`t normally exposed to the 
end-users, mostly if I disable SSH service.

My concerns are for someone with sufficient technical skills that wants 
to enter the Linux system. The first thing he would do is finding the 
console UART, connect/soldering a USB/UART converter, open putty and try 
to login guessing the root password.

The original question was for this scenario.


>> Each device has a different 4 bytes serial number. I could use it to
>> scramble an unencrypted password and obtain an enctrypted password that
>> will be the normal root password.
>>
>> I could disable SSH service at all to be safer, but anyway the board has
>> a console over UART that I don`t want to disable.
>>
>> Any suggestions?
> 
> Having a fixed root password that`s only accessible via a UART inside the
> case is safe, but not if via network.

So in my case is safe, because via network SSH will be disabled and web 
application uses different credentials.


> Disabling SSH if the customer doesn`t need it is generally a good idea, since
> it`s just another channel for attacks (or, even if not vulnerable, it
> creates noise in your logs/IDS).
> 
> Standard best-practice is to provision a unique password but to print it on
> a label on the device (eg on the back or underneath) so physical access is
> needed to discover it.

It`s useless in my application. The end-user will never need the Linux 
root password, only an hacker would need it and I wouldn`t show him the 
password well printed on a label.


> Do you have a provisioning flow where new devices get loaded with their
> firmware, MAC address and similar identifiers?  Could you set the password
> there?

Yes, in case I choose to set a different Linux root password for each 
device, the choice of password will be done during programming of 
firmware and so on.

In this case I can generate a random password, saving it in a database 
of devices. However, the time I need to enter the system (if something 
goes wrong and I need to read logs or issue commands), I need the serial 
number and the database.

If I generate the password from the serial number using a well-known 
algorithm, I could always recover the Linux root password from the 
serial number only.

I`m wondering if there was a standard or typical approach here.
 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.14.0
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441