Mkpasswd

[Salomon Thoj]

Weuse OpenSSH key pairs on a regular basis and due to the asymmetric nature of key pairs, as far as I understood the concept, giving out your public key to the ... well ... "public" - is considered a safe thing to do since it can only be used to verify that you are really you. Creating content or authenticating yourself works against the private key which never leaves your machine, hence the strong security.

Now, given the above mentioned situation as a comparison, can it be considered secure if I created a password hash with the unix tool mkpasswd and a salted SHA512 hash and gave THAT out to the public?

The key difference here (no pun intended) is that the key includes a significant amount of entropy (i.e. it is random). Passwords are often quite terrible, commonly having under 30 bits of entropy. 30 bits is easily brute-forceable, so password hashes are designed to be slow (you specified salted SHA512, but you omitted the number of rounds), making the brute-force take longer. Despite this mitigation poor passwords will still be broken quickly.

Without a salt an attacker could use precomputation in the form of a rainbow table. That way, they could spend a bunch of time doing work so that when they do discover the hash value they can break it very quickly. The use of a (sufficiently long and random) salt prevents this, so that the attack can only begin the moment the hash is exposed.

It should also be noted that SHA-512 with the default of 5,000 rounds is not very good. It's not nearly as bad as a single round of MD5, but most computers nowadays can do over 2,000,000 rounds in under a second. You could expect a motivated attacker targeting a 5,000 round SHA-512 password to do millions to billions of guesses per second.

First and foremost, you would have no way to authenticate yourself. If you send the hash, you proved nothing as everyone knows your hash. If you send plaintext password, the party now not only knows it, but other parties may not know you used it. So it is one-time use at best and completely insecure at worst.

As for the security of hashing a password, it can be secure if the password is long, generated randomly and hashed with a strong hash function. But for human created passwords, dictionary attacks would make it questionably secure even for good long passwords like correct horse battery staple.

There are actual applications that outright rely on the content not being retrievable from the hash other than password protection. A notable use is a secure coin flip. Therefore, it was presumably studied and determined safe for random passwords/keys.

I found a tutorial indicating that mkpasswd -m sha-512 "my password here" would produce a salted and hashed password that can be used in combination with useradd -m -p "hashed and salted passwd" -s /bin/bash username, however when I tried this on a test user, I keep receiving Incorrect Login.

I also tried to make the user without the -p flag (meaning don't add a password) and manually copied the salted/hashed password into /etc/shadow which produces the same results as above, Login incorrect.

The $6...,$1..., and $b... portions from your hash are treated as variable. Of course, the fault is with the shell - shells perform variable expansion (unless they're single-quoted ) before anything runs. And because those 3 variables don't exist in your environment they disappear from the string you pass to useradd.

In other words, you generated correct hash, but shell passes completely different thing to useradd as argument, which ultimately is the command that system runs. In fact, let's just take your hash for instance and compare two cases of quoting and non-quoting:

The mkpasswd utility is present on many Linux systems as part of the base install. In Ubuntu 12.04, for some unknown reason, it appears to be part of the "whois" package. Other than "historical reasons", is there a reason for this seemingly arbitrary inclusion?

The mkpasswd program can be used to create a /etc/passwd file. Cygwin doesn't need this file, because it reads user information from the Windows account databases, but you can add an /etc/passwd file, for instance if your machine is often disconnected from its domain controller.

Note that this information is static, in contrast to the information automatically gathered by Cygwin from the Windows account databases. If you change the user information on your system, you'll need to regenerate the passwd file for it to have the new information.

By default, the information generated by mkpasswd is equivalent to the information generated by Cygwin itself. The -d and -l/-L options allow you to specify where the information comes from, some domain, or the local SAM of a machine. Note that you can only enumerate accounts from trusted domains. Any non-trusted domain will be ignored. Access-restrictions of your current account apply. The -l/-L when used with a machine name, tries to contact that machine to enumerate local groups of other machines, typically outside of domains. This scenario cannot be covered by Cygwin's account automatism. If you want to use the -L option, but you don't like the default domain/group separator from /etc/nsswitch.conf, you can specify another separator using the -S option, analog to mkgroup.

The -o option allows for special cases (such as multiple domains) where the UIDs might match otherwise. The -p option causes mkpasswd to use the specified prefix instead of the account home dir or /home/ . For example, this command:

would put local users' home directories in the Windows 'Profiles' directory. The -u option creates just an entry for the specified user. The -U option allows you to enumerate the standard UNIX users on a Samba machine. It's used together with -l samba-server or -L samba-server. The normal UNIX users are usually not enumerated, but they can show up as file owners in ls -l output.

Here's the source code for mkpasswd. It's an expect script. You would have to modify the script (at least the shebang) in order for it to work. There are other command line tools such as openssl (md5), jot and dd that can generate passwords.

Search in other suite:[buster][buster-updates][buster-backports][bullseye][bullseye-updates][bullseye-backports][bookworm][bookworm-updates][bookworm-backports][trixie][sid][experimental]Limit to a architecture: [amd64] [arm64] [armel] [armhf] [i386] [mips64el] [mipsel] [ppc64el] [s390x]You have searched for paths that end with mkpasswd in suite bookworm, all sections, and all architectures.Found 4 results.FilePackages/usr/bin/expect_mkpasswd expect /usr/bin/mkpasswd whois /usr/sbin/ircd-mkpasswd ircd-irc2 /usr/share/bash-completion/completions/mkpasswd whois This page is also available in the following languages (How to set the default document language):

This Perl library defines a single function, mkpasswd(), to generate random passwords. The function is meant to be a simple way for developers and system administrators to easily generate a relatively secure password.

The exportable mkpasswd() function returns a single scalar: a random password. By default, this password is nine characters long with a random distribution of four lower-case characters, two upper-case characters, two digits, and one non-alphanumeric character. These parameters can be tuned by the user, as described in the "ARGUMENTS" section.

If set to a true value, password characters will be distributed between the left- and right-hand sides of the keyboard. This makes it more difficult for an onlooker to see the password as it is typed. The default is false.

If set to a true value, password characters will not include any that might be mistaken for others. This is particularly helpful if you're distributing a printed list of passwords to a group of people. The default is false.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.1 or, at your option, any later version of Perl 5 you may have available.

I laughed and asked him why he wasn't using the included utility which doesexactly that: make passwords. He told me that mkpasswd actually doesn't generate passwords, it actually generates the hashed and salted password thatgoes in /etc/shadow.

So there's at least two methods to generate hashed passwords: the old DESstyle, and the newer MD5 based style. If you have it enabled, the SHA-256 version could be used. I figured that of course mkpasswd used the newer style, so I was safe. The random salt would be good enough.

I protect my GRUB menu entries using the method outlined in the GRUB entry in the ArchWiki. However, I am sending my laptop in for repairs to the manufacturer and I would like to remove the password protection so that someone can boot into the system without having to enter my username or the GRUB password.

I tried removing the entry I made in the 00_header file in /etc/grub.d/ that contains the username and password hash, but the system still asks for both in order to boot the system. Is there any way I can completely remove this requirement so that GRUB simply boots without a username and password, or am I stuck with it?

Searches of Google/Arch forums have only revealed advice regarding re-setting the password by generating a new password and hash using grub-mkpasswd-pbkdf2 after chrooting into the system. The man page for grub-mkpasswd-pbkdf2 also does not list any way of deleting a hashed password. Any help would be appreciated!

I guess one work-around would be re-running grub-mkpasswd-pbkdf2 and just hitting 'Enter' to produce a blank hashed password, then adding the new hashes to the 00_header file and regenerating the GRUB profile. I'd still have to type in a username, but the password would just be a keystroke.

That's a GRUB issue, not an Arch issue. Arch doesn't patch software unless absolutely necessary. It also might just be your mistake. I know that 99% of the time, it's because I made an error. I would check the other scripts for grub.d. I had to comment out the username and password in my configuration and then regenerate the grub.cfg.

3a8082e126