I do not disagree that we could improve on this. And i'm not saying hashes change frequently. But storing a hash would at some point become equally insecure when it's deprecated. And if someone gets a hold of the hash it's a small bump in the road for a local attack.

I think the chmod is a solid approach and increases security significantly for me to consider this done for now.

I'll submit a PR with it together with the /tmp password and issue surrounding passwords being stored in disk_layout.json

I think I've figured out a clean way to approach this.
As storing hashes presents the issue of not being able to rely on toolings like passwd for setting the password.
Obviously not a huge obstacle but we'll need to transition to setting it with opening /etc/shadow manually.

Something in the lines of:

salt = base64.b64encode(os.urandom(12))
password = base64.b64encode(hashlib.pbkdf2_hmac('sha512', b'password', salt, 200000, 64))

with open(f"{target}/etc/shadow", ...) as shadow:
    shadow.write(f"{user}:$6${salt.decode('UTF-8')}${password.decode('UTF-8')}:{the_rest}\n") # In case it's not obvious, pseudo code

200000 appears to be a reasonable iteration count as explained by NIST-SP-800-132 and stackexchange pbkdf2 iterations question, as referenced by hashlib.pbkdf2_hmac

A heads up if we go this route is:

Deprecated since version 3.10: Slow Python implementation of pbkdf2_hmac is deprecated. In the future the function will only be available when Python is compiled with OpenSSL.

The alternative is to use passwd and extract the set password hash, salt and algorithm used.
But that would mean we run the risk of storing clear text passwords in the conf and potentially save it to disk before replacing it.
So I'd want to go the route of generating a /etc/shadow compliant alg+salt+hash combo at the "set password for user X" prompt in the menu.

Moving this to a later milestone as this could potentially cause issues. And I'd like to get v2.5.1 out to patch some older issues that's been lingering.

Obviously not a huge obstacle but we'll need to transition to setting it with opening /etc/shadow manually.

FWIW chpasswd has a -e, --encrypted supplied passwords are encrypted option. Opening the file manually is likely easier, but just for the record :)

That would be easier to implement. I couldn't find such a flag for passwd but happy to see that chpasswd prevails ^^ Thanks @klausenbusk!

Hi! I have perhaps a dumb question.

How severe of a vulnerability is this? Is there a recommended way of working around this issue in the meantime? Is the current workaround for users to use chpasswd after installation so that the passwords stored on plaintext disk are no longer the actual passwords?

Thanks!

How severe of a vulnerability is this?

This seems to be a pretty big security vulnerability if you do not have any LUKS encryption enabled and work/live somewhere, where others might have access to your computer. Additionally, malicious scripts may be able to read your password from this file.

Is there a recommended way of working around this issue in the meantime?

The way to go about this as you described seems to be a good workaround, don't take my word for it, though. I'll be happily corrected if there's something wrong.

Securely deleting this log file also seems like a simple workaround in the mean time.

I won't use archinstall until this is fixed, my stomach just tells me no (Especially since it's such a basic security principle; Do not store passwords in plain text).

Sad, because it looks like a cool script!

Oh, @Torxed: If this has been fixed, make sure to close this issue to let us know :p Just reminding you because I frequently forget to close issues.

As a possible fix: Don't log the passwords at all.

Can we not simply delete the file after the installation?

it should never be written to the drive in the first place because of drive recovery techniques

Can we not simply delete the file after the installation?

Not advised. Keep in mind on SSD's and modern storage systems that data might not be actually deleted even when you rm -f. Due to wear leveling often a delete simply markes a page or cell as "used" but the contents of that data can still be recovered using lower level recovery mechanisms. Helpful read here. If your ssd block life is, for example, 3000 writes before block marked as end-of-life, then the contents of the last write before being marked will be retained physically forever.

Assume if you store anything in clear text that it can be recovered through forensic analysis. This is why on modern systems one should make sure /tmp is either encrypted, or stored in memory with swapfs write to disk forbidden or with swapfs encrypted. And if this all sounds confusing and convoluted, it absolutely is which is why most users that care about security but don't have time to dig into linux details should just stick with using a macbook (cough, secureboot, cough)

My suggestion:

• don't log credentials by default
• 600 the log
• optionally log credentials with debug logging enabled, or with a separate flag.

Just to shed some light, we don't log passwords in the log that is written to disk.
We do write user credentials to ramdisk while the ISO is alive so that the user can copy them if they choose to.

We could also omit writing the credentials all together since we now have a "save configuration" menu alternative which we didn't have when this ticket was created.

I'll patch out the credential writing by default, and let the users save the creds and deal with permissions and what not if they choose to do so.

Just to shed some light, we don't log passwords in the log that is written to disk. We do write user credentials to ramdisk while the ISO is alive so that the user can copy them if they choose to.

This mitigates the issue right? Since even if it's plaintext, it's in the ramdisk, so unless you're targeted immediately after/shortly after the install it should be "fine"?

So this user_credentials.json isn't generated anymore by default with the current archiso, right?

Just to shed some light, we don't log passwords in the log that is written to disk. We do write user credentials to ramdisk while the ISO is alive so that the user can copy them if they choose to.

This mitigates the issue right? Since even if it's plaintext, it's in the ramdisk, so unless you're targeted immediately after/shortly after the install it should be "fine"?

Should be fine yes.
I'd like to verify a few things before closing this ticket tho :)

I found that with the installation image from the end of June, I can still find my disk encryption_password as plain text in the file /var/log/archinstall/install.log also after rebooting into the freshly installed system. The user or root passwords are not part of the log anymore.

Would You consider this a different issue?

I found that with the installation image from the end of June, I can still find my disk encryption_password as plain text in the file /var/log/archinstall/install.log also after rebooting into the freshly installed system. The user or root passwords are not part of the log anymore.

Would You consider this a different issue?

I've been bashing my head for a while now with this one.
I can not reproduce it in any capacity: https://youtu.be/PjG__PGKP4Y

And the credentials on the ISO is no longer world readable:

And no configuration files is automatically copied to the installed system:

What is the status on this? Could the secrets in the (manually saved) user_credentials.json be saved/loaded as hashes? I'm currently setting up an unattended archinstall and it would be great if archinstall could load the user_credentials.json via http.

What is the real reason why this is kept? Isn't just better to just rm -rf after all the install or make a chmod at least? Am I missing something?

Should archinstall's readme have the following warning?:

archinstall stores all user and (secondary) disk encryption passwords in plain text.

I feel like this issue should be broadcasted more loudly to Arch newcomers.

The Arch Wiki has this banner on archinstall; I feel like this project's readme should have it too until the issue is resolved.

What is the real reason why this is kept? Isn't just better to just rm -rf after all the install or make a chmod at least? Am I missing something?

this exact question was answered above in thread: #1111 (comment)

What is the real reason why this is kept? Isn't just better to just rm -rf after all the install or make a chmod at least? Am I missing something?

this exact question was answered above in thread: #1111 (comment)

Refill the file with /dev/random then rm -rf ?

Call me crazy, but why write it there in the first place? Why not /dev/shm/?

/dev/shm/

That's actually not a bad option. It would completely remove without recovery since it saves into RAM. Also according to the archwiki it's already been used in /run /var/run and /tmp directories without an entry on fstab.

What if we change lib/configuration.py file to something like:

def save(self, dest_path: Optional[Path] = None):
	dest_path = dest_path or self._default_save_path

	if self._is_valid_path(dest_path):
		self.save_user_config(dest_path)
		self.save_user_creds(Path('/var/run/archinstall'))

This is wrong, but it's a starting point

What is the real reason why this is kept? Isn't just better to just rm -rf after all the install or make a chmod at least? Am I missing something?

this exact question was answered above in thread: #1111 (comment)

Refill the file with /dev/random then rm -rf ?

The exact reason this too will not work was answered above

Hey I just started to play around with the installer and plan to move to arch soon.

I am quite confused with this issue still being open and the warning being still present in the arch wiki:

Is this still a potential security issue? Since I want to use arch on my daily driver laptop with disk encryption I am a little bit concerned.

Is this still a potential security issue?

The short answer is, not really.
At least the big issue from when this was originally created was that all configuration files were world readable, since long - they're not:

The matter of storing hashes is a really good idea — so I've left the issue (slash feature request) open until I've had time to implement it (or someone chimes in with a PR hehe).

Should the scary archwiki banner be removed? If this isn't an issue anymore.

When using archinstall to install Arch Linux from an existing host running Arch Linux the password will be written in plaintext to /var/log/archinstall/cmd_history.txt as the following example shows:

timestamp ['/usr/bin/arch-chroot', '/mnt/archinstall', 'sh', '-c', 'echo username:password | chpasswd']

Was this issue ever fixed? From comments in here it looks like this was patched ages ago and passwords are no longer stored in that json.

A hashed password is safe and for a high enough password entropy will never be an issue to have it recovered @Torxed , i didn't quite understand the scepticism in your first posts about hashing it and leave it be even with chmod 744 . It really doesn't matter who's hands it falls into, not even in a world of post-quantum will it be an issue:

https://cr.yp.to/hash/collisioncost-20090517.pdf

I can make a PR using Argon2id @Torxed

Did anyone consider just using a secure python crypto lib to encrypt the whole user_credentials.json with a master password?

Instead of storing user_credentials.json the file could be named user_credentials.json.enc asking a master-password when saving the files and reading the files. That would probably solve a lot of problems and could be implemented backwards compatible by still supporting the plaintext-version (e.g. by using an empty master password)...

Why does the password need to be saved anywhere in the first place?

Why does the password need to be saved anywhere in the first place?

As long as you store one user on an unencryted drive its easy to provide a short password during an automated install, but providing multiple users with different passwords along with a 32+char encryption key is pretty inconvenient...

I admit that encrypting the user_credendials.json with a master password might not be the most elegant solution, but it would be easy to implement and an improvement over storing plaintext files...

EDIT:

import base64
import os
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC

password = b"password" # potential master password provided by user

salt = os.urandom(16)
kdf = PBKDF2HMAC(
    algorithm=hashes.SHA256(),
    length=32,
    salt=salt,
    iterations=1_000_000,
)

# derive a secure key from the given master password
key = base64.urlsafe_b64encode(kdf.derive(password))
f = Fernet(key)
# encrypt 
token = f.encrypt(b"<user_credentials.json content>")
# token
# b'...'

f.decrypt(token)
# b'<user_credentials.json content>'

Source: https://cryptography.io/en/latest/fernet/#using-passwords-with-fernet

The only thing that's missing is that the salt has to be prepended / appended to the encrypted message.

With a thorough review of the comments here, it appears the expectation from users is that the user_credentials.json file should not be created by default. Making this change should not be a problem as there is an option to save it for those that want it.

Use an approach like Ansible Vault?

#3276 has partly addressed the issue, usee account passwords will be stored in hashed form in the configuration file.
Unfortunately that's not possible for the disk encryption password.

So looking into options of encrypting the entire file as suggested by #1111 (comment)