How to generate and programmatically set encrypted user passwords

[Deleted member 65953]

I know that it is possible to set user passwords programmatically using echo 'mypassword' | pw usermod myuser -h0. However, this exposes the plaintext password (e.g. in ps and when the command is included in a shell script under version control). The alternative is to generate an encrypted password from the plaintext password, and programmatically set the encrypted password.

Generate encrypted password:

# echo 'mypassword' | pw usermod nobody -N -h0 | cut -d : -f 2
$6$07r1vTa8eEhfGRKu$8kzORlnaPhH47akHNZsox6CCV14l1NKe1YV8FblEEjlSkj21OjHNKGeagZt8w0Pe28JUxY121Q73RP/oUex3i1

Set encrypted password:

# echo '$6$07r1vTa8eEhfGRKu$8kzORlnaPhH47akHNZsox6CCV14l1NKe1YV8FblEEjlSkj21OjHNKGeagZt8w0Pe28JUxY121Q73RP/oUex3i1' | \
    pw usermod myuser -H0

Questions:

1. Is there a more straightforward way to generate the encrypted password instead of the solution shown above which involves two pipes?

2. Is it secure to place the encrypted password into a version-control system along with other shell scripts that I use for system management? The plaintext password cannot be retrieved from the encrypted password, correct?

 

[covacat]

look at openssl passwd

 

[Kai Burghardt]

[…] However, this exposes the plaintext password […]

If security.bsd.see_other_uids (and see_other_gids, security(7)) is not 0 (or uncertain) you use a heredoc to conceal input data:​

pw usermod myuser -h0 << 'EOT'
mypassword
EOT

The << 'EOT' … EOT stuff does not appear in ps(1) as it is processed by the shell and not passed to execve(2). ?​

Is it secure to place the encrypted password into a version-control system […]?

I’m a bit wary about that because deleting data can be difficult. Your passwords may be stored in many files, e. g. for different branches, tags etc. You don’t want sensitive data (including encrypted data) scattered all over the place.​

The plaintext password cannot be retrieved from the encrypted password, correct?

That’s the idea, the hypothesis behind “one-way functions” (“trapdoor encryption”) that has so far not (publicly) been proven wrong.​

 

[Deleted member 65953]

look at openssl passwd

Thank you. To generate an encrypted password using openssl-passwd(1): openssl passwd -6 'mypassword'.

 

[SirDice]

The plaintext password cannot be retrieved from the encrypted password, correct?

That’s the idea, the hypothesis behind “one-way functions” (“trapdoor encryption”) that has so far not (publicly) been proven wrong.

It can be bruteforced offline though. Simple enough passwords are easily broken; rainbow tables and GPU based cracking will make short work of them.

 

[covacat]

rainbow tables are not very useful when salts are used especially if salts are long enough

 

[SirDice]

Generate tables with the specific salt that was used for this password. I don't need to go through all salts, I just want to break this one.