Passwd -a sha256|sha512 less secure than default

Luci was broken with the 'defconfig' for x86_64. Hopefully someone will catch this and 'fix' in the next revision. Maybe sha256 should be a WORKING default?

I can confirm that sha256 indeed works if you choose 'advanced config' and 'enable crypt' as mentioned. I do think it should be a 'default' since the non-modifed config results in a brain-dead luci. Oh well.

From that discourse

All password hash algorithms except for MD5 (default) and DES (for
compatibility reasons) have been stripped from libc to cut down on
useless bloat.

If you care about password storage security, it's better to use a
function that was intentionally designed NOT to be fast, e.g. PBKDF2 or

It does not make sense however to refer to bcrypt and then even compile it into the shadow package when at same time crypt_blowfish being stripped in the toolchain (in the same patch as SHA256|512).

Further from that discourse

I think switching from MD5 to SHA256/SHA512 is rather pointless.
It slows down password cracking by a small factor, but not by real
orders of magnitude,

That seems rather debatable as MD5 comes with fixed 64 rounds whilst SHA256|512 rounds are adjustable and even with the default of 5,000 rounds provides reasonable resistance. Increasing it to 15 <> 20 k makes it even difficult for quantum computing power.

Which leaves

been stripped from libc to cut down on useless bloat.

How much bloat?

14KB after LZMA on MIPS.

1 Like

Thank you for the input. Though it seems small probably every byte counts in the scheme of things.

Reconsider though

Either crypt_blowfish should be reinstated or bcrypt not compiled into shadow or else this setup makes no sense.

I have a PR in the works that switches shadow-utils to use libxcrypt and not the one in the libc.

1 Like

That would be splendid if accepted into the distro.

Currently waiting on to get accepted.

1 Like

Thank you @neheb for your contribution which has returned bcrypt | sha256 | 512 with shadow.

Just tested with brcypt (mind if using PAM to change the algo there too) and works fine.

Suppose that resolves/thread (least once OpenWrt 20.x) arrives.

Note that authentication against such hashes will fail for rpcd (LuCI) and uhttpd basic auth (if using the $p$user notation) since those still use libc's crypt() function. Not sure about Dropbear / OpenSSH etc.

Indeed, as just learned the hard way (surprise surprise) - having lost access to the node through LuCI, SSHD and Dropbar... ...and only been able to recover through serial console...

Now that libxcrypt is available in the repo it would make sense to recompile those packages as otherwise @neheb's effort would be sort of in vain and nothing gained for the user but being stuck with DES or MD5

Yeah sure, but it would entirely defeat the point of removing those hashes from the libc in the first place. Instead of a space reduction, everything else becomes even bigger than before.

I was under the impressions that ‭ libxcrypt is in general less bloated than libc. If that were the case it would seem beneficial in a general way?

As for password security one could argue that if someone unintended/unauthorized gets hold of the hashed password, in whichever way that may be (and there could various with different node deployment scenarios) it would constitute a security breach in the first place. And I would agree, but unfortunately that may not be an uncommon occurrence.
Even with the OS drive being unencrypted a stolen and cracked password could be of use for the adversary. And latter does not even have to possess suitable hardware (like powerful GPU) for taking a crack at DES | MD5 hashed password as there are plenty of such services readily online available.

DES or MD5 are not suitable for proper salting passwords against cracking.

@jow might be good to let the user know that luci-app-acl generates a MD5 salted password hash

I made libxcrypt be used by nothing except shadow-utils as those are expected to have no size concerns. Everything else does.

Unfortunately it turns out that the amount of work you put in is in vain since we are almost back at start, except for shadow. But since

are not tagging along it is pre-emptive. Suppose one can do without LuCi and Dropbear but at least needs SSHD to access the node, unless resorting to serial console.

Why and to which extent should the size for SSHD matter since not being a standard and any user consciously installing it should know whether the nodes can carry it?

Plus luci-app-acl providing MD5 salted hash only does not make sense as it barely raises the bar above unencrypted.

While it would be best to have this fixed, why don't you just use pub/priv key for SSH access?

It is not always suitable scenario since it requires a key for each and every remote device accessing the node and there are times when accessing it with a password only.

Sounds like you are using OpenWRT in a production environment, if so, that is unadvised.

If not, I am curious when you cannot use a key pair?

I know how to handle secure remote access without necessitating SSH key pairing. Besides this seems to drift off-topic (password salting hashes)