Currently waiting on https://github.com/openwrt/packages/pull/12530 to get accepted.
1 Like
Thank you @neheb for your contribution https://github.com/openwrt/packages/pull/12577/commits 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.
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)