Securely Creating and Managing New Users on Raspberry Pi

The Raspberry Pi‘s huge popularity among developers and hobbyists makes it an obvious target for attackers seeking to exploit insecure default configurations. One such example is the reliance on the default "pi" user account and password found on most Raspberry Pi systems. To properly secure your device, creating and securely managing new user accounts is an essential first step.

In the following comprehensive guide, we will walk through adding users, configuring sudo privileges, setting up authentication, and other best practices based on industry and security standards for Linux user account administration.

The Risks of Using Default Credentials on Embedded Devices

Let‘s first understand the motivating factors for why using default credentials like the Raspberry Pi’s “pi/raspberry” user and password introduces security risks.

Prevalence of Default Accounts in Attacks

According to 2021 research on honeypot activity from F-Secure, default credentials were exploited in:

• 33% of SSH attacks
• 26% of Telnet attacks
• 18% of administrative web interface attacks

Attackers know that most users continue relying on default accounts and passwords for convenience when setting up new devices. This makes them prime targets for brute force and credential stuffing attacks.

Furthermore, the "pi" Raspberry Pi default credential has remained unchanged for over 10 years of revisions and is well documented on most device setup guides. This gives attackers an easy footprint to start probing for weaknesses.

Consequences of a Compromised Embedded Device

A hacked IoT device often serves as a pivot point into home or corporate networks where far more sensitive data resides.

From a 2022 report by Barracuda Networks, attackers used compromised connected devices to:

• Install spyware or keyloggers (55%)
• Steal user credentials (47%)
• Access confidential documents (39%)
• Deploy ransomware payloads (27%)

And according to Verizon’s research, embedded devices are involved in over 15% of breaches due to weak authentication controls among other factors.

Without change the Raspberry Pi’s default account, unauthorized access can have some devastating downstream impacts.

Best Practices for Securing User Accounts on Embedded Linux

Managing users properly is a critical first step in preventing against compromised devices. The Center for Internet Security provides useful baseline recommendations applicable for the Raspberry Pi including:

Inventory Accounts: Document all user accounts to understand who has access and what privileges are configured. Establish approval processes for new accounts along with access expiration triggers after periods of inactivity.

Least Privilege: Ensure each user account only has enough permissions to carry out essential duties. Standard users should not have sudo privileges or run as root by default.

Authentication Management: Require strong passwords set to expire after 90 days along with two-factor authentication for admin users when possible. Disable unused default accounts and enforce password complexity policies.

Permission Reviews: Audit groups and privilege assignments at least quarterly to find any overly permissive roles. Check for unused legacy or shared accounts which should be removed or disabled instead.

Activity Monitoring: Track login history, command usage, sudo invocations and file access on a per-user basis via central syslogs and tools like auditd. Investigate any abnormal behavior which could indicate compromised credentials.

While written for enterprise IT, these controls apply perfectly for properly administering Raspberry Pi user accounts as well. We will aim to implement many of these best practices in our guide below.

Step 1 — Creating the Raspberry Pi User

Upon setting up a factory default Raspberry Pi OS install, the first step is creating our own non-privileged user account to avoid using the default “pi” user.

This can be accomplished by using the adduser command in Raspberry Pi OS’s terminal:

sudo adduser newuser

You will first be prompted to enter and confirm a password for the new account. Make sure to choose a strong password that complies with the UK National Cyber Security Centre’s password guidance. Some quick tips:

• 12+ mixed characters
• Phrases more secure than random characters
• Avoid dictionary words or personal info
• Include symbols, numbers, case changes

Next, you can fill out some optional user information and metadata that may come in handy down the line if needing to validate ownership or track access:

User information: 
    Full Name []: Jane Doe
    Room Number []: 2128
   Work Phone []: 555-0123
     Home Phone []: 555-5678
       Other []: 
Is the information correct? [Y/n] Y

Once complete, the new user “newuser” will exist but still needs to be granted sudo permissions to administer the device.

Step 2 – Configuring Sudo Privileges

The sudo command in Linux provides a controlled and audited way to delegate admin rights to specified users. According to CIS policy, only essential personnel should have sudo access based on job function.

First add the new user to the sudo group. This grants the permission to run as root after re-authenticating:

sudo usermod -aG sudo newuser

Then, we will set up sudo so password re-authentication is not required on each sudo invocation. This eases frequent admin tasks however lowers security, so ensure your non-root account uses a very strong password and enable SSH key-based authentication.

echo ‘newuser ALL=(ALL:ALL) NOPASSWD: ALL‘ | sudo tee /etc/sudoers.d/010_newuser-nopasswd

Now test sudo by switching users and running a command. It should execute without prompting for a password:

su newuser 
sudo apt update

Our new user can now run any root commands via sudo to fully administer the system!

Step 3 – Enabling SSH Key Authentication

Passwords alone has long been considered poor security for remote shell access according to the UK NCSC guidance. One compromised password could lead to full system access!

To enhance security, we will force SSH connections to rely on cryptographic keys instead of passwords alone. First generate an SSH keypair on your admin workstation if you do not already have one:

ssh-keygen -t rsa

Accept the default location to save they keys under ~/.ssh and protect the private key with a passphrase. Then copy your public key over to the Pi:

ssh-copy-id newuser@raspberrypi_ip

Finally, harden the SSH configuration by editing /etc/ssh/sshd_config via sudo nano /etc/ssh/sshd_config and updating the following parameters:

ChallengeResponseAuthentication no 
PasswordAuthentication no
UsePAM no

AllowUsers newuser

ClientAliveInterval 60
ClientAliveCountMax 2 

Save changes and restart the SSH daemon with sudo systemctl restart ssh. SSH logins will now only succeed when connecting with the private key for newuser who is the sole account allowed.

By leveraging public-key authentication, we have established a significantly more secure remote access control mechanism for administering our Raspberry Pi.

Step 4 – Configuring Automatic Logins

Currently on reboot, our Raspberry Pi will boot to the graphical desktop but still prompt to login due to removing default autologin behavior for the “pi” user previously.

Let‘s edit this behavior using raspi-config again to auto-login the new “newuser” account on start:

sudo raspi-config

Navigate to System Options > Boot/Auto Login > Desktop Auto Login > newuser

Select the new user and reboot to verify that the desktop automatically logs in. This avoids tedious manual logins while still ensuring access is restricted to our non-default account.

Step 5 – Enforcing Password Complexity Standards

While we cannot enforce regular password rotation due to compute limitations on the Pi, we can still require enhanced complexity standards for all accounts.

Begin by installing the libpam-pwquality module:

sudo apt install libpam-pwquality -y

Next, configure the password security policy via /etc/security/pwquality.conf using:

sudo nano /etc/security/pwquality.conf

Set the parameters as follows per UK NCSC guidance:

minlen = 12
[snip]
ucredit = -1
lcredit = -2
dcredit = -2
[snip]
enforce_for_root

This enforces passwords are at least length 12 with at least one symbol and either an upper case OR a number present.

Enable the password security module by editing /etc/pam.d/common-password adding this line if it doesn’t exist:

password required pam_pwquality.so retry=3

Now all user password resets will comply with stronger criteria reducing crackability while staying reasonable for human memory limitations (no excessive complexity or renewals).

Step 6 — Removing the Default “pi” Account

As a final cleanup step for hardening our access controls, we will remove the default “pi” account since it is no longer needed.

This can be done with the deluser command:

sudo deluser --remove-home pi

You will be presented with prompts to confirm the account removal. Note that after deletion on next reboot, the autologin configured previously would fail if “pi” was still set as the target login user.

With default accounts removed and all logins going through the new user account only after patching in enhancements to authentication and permissions, we have established a vastly more secure Raspberry Pi!

Auditing controls and activity monitoring are next steps to round out an enterprise-level administration policy.

Tips for Ongoing User Account Maintenance

Properly securing accounts is an ongoing vigilance activity requiring regular reviews and maintenance as organization needs evolve. Here are some additional best practices:

Revalidate permissions quarterly with the principle of least functionality limiting rights. Tooling like BloodHound can help analyze relationships and unnecessary access.

Check sudoers files for proper group assignments, unused legacy rules, or open vulnerabilities enabling escalation.

Analyze logs for abnormal activity like failed logins indicating compromise attempts or permission discrepancies from user expectations.

Enforce multi-factor authentication using solutions like Duo or hardware tokens to fully eliminate reliance on shared secrets alone.

Consider single-purpose accounts for third party integrations to isolate access.

Integrate identity management solutions to enforce lifecycle stages, access rules across systems, and speedy disablement when necessary.

Conclusion

Distributing embedded devices with insecure default accounts continues leaving organizations vulnerable in the expanding IoT landscape. As threats evolve, manufacturers must “shift left” and deliver properly configured permission schemes demonstrating security is priority one — not an afterthought.

Until then, properly creating and securing your own user accounts remains the first line of defense when deploying devices like the popular Raspberry Pi. Take the essential steps covered here seriously: updating passwords, establishing least privilege rules, hardening authentication methods, and disabling any default admin users to minimize attack surface.

By improving embedded device identity and access management maturity, we can make the smart technologies built on platforms like Raspberry Pi safer for everyone to benefit from innovation while still preserving privacy and security.