Secure Mode Password: Login uses only 8 characters from longer passwords....

[Harnessmaker]

The boot prompt in secure mode offers the very handsome password length of 8-56 characters.  However it seems that only the first 8 characters are recognized by the system at login, so no increased security is being achieved by using a longer password.

Discovered this by accident, and then tested as follows: 
(Double-quoted is typed by me, single-quoted by box)

Using TinyCore version 3.5 as live cd:
Booting with codes "tinycore secure"

At the prompt, 'Enter password (8-56 characters) for root:'
I enter "MyRadicallyLong&ComplicatedRootPasswordUsing56Characters"
and for tc, "MyMoreReasonableTCPasswordUsing43Characters"

After X loads, in terminal:

'tc@box:~$' "su"
'Password:' "MyRadic" [7 characters, refused as expected]
'su: incorrect password'
'tc@box:~$' "su"
'Password:' "MyRadica" [8 characters out of 56, yet login occurs]
root@box:~#

then I exit to console via control+alt+backspace
"exit"
'Tiny Core Linux box login:' "tc"
'Password:' "MyMoreRe" [8 characters out of 43, yet login occurs]
and X starts.

Thus it seems that in the secure mode, only the first eight characters of longer passwords are actually being acted upon, and thus the use of longer passwords is not adding any security.
 
It would be grand if longer passwords could be effective.

However, if this is not possible, perhaps the login instruction could alert the user that only the first 8 characters have effect? 

Regards, and thanks.

Harnessmaker

[maro]

I find this an interesting observation and thought initally "well, BusyBox seems to be a bit too limited for this" and started browsing the BusyBox sources and did a few of my own testing:

As I already had a MC 3.5.1 system running in a VM I used the 'passwd' tool to assign passwords of various length to users 'tc' and 'root' and checked whether I could login using either shorter or longer variations of the assigned passwords. Unlike the observation of the OP only the correct password (i.e. neither longer nor shorter) was accepted. I also realised that the BusyBox 'passwd' applet was rather strict WRT what passwords were deemed acceptable (e.g. minimum 8 characters, not too simple, etc.).

I then tried to understand how the 'secure' boot code (as implemented via '/etc/init.d/tc-config') works. It utilises the 'getpasswd()' function (from '/etc/init.d/tc-functions') which implements its own mechanism to (securely) read in the password ensuring suitable length. This information (in the form of 'USER:PASSWORD') is then passed to 'chpasswd' (another BusyBox applet) to change '/etc/shadow'.

I had a bit a look and discovered that the 'chpasswd' applet is much more lenient WRT what type of passwords are acceptable (e.g. empty or single character passwords are OK). More interesting was the fact that the password hash entries in '/etc/shadow' produced by 'chpasswd' looked quite different to those generated by 'passwd' (WRT hash length and its prefix). Closer scrutiny of the respective sources lead me to the conclusion that the former uses by default the 'des_crypt()' function, whilst the latter uses 'md5_crypt()'. As can be found on this page the 'des_crypt()' function uses only a "8-byte encryption key with parity", which I interpret to mean that only the first 8 characters are significant (which matches the original observation). The 'md5_crypt()' function does not seem to have such a (small) limit.

Luckily the '-m' paramter for the 'chpasswd' applet exists that allows to change the hashing function from 'des_crypt()' to 'md5_crypt()'. So adding this parameter to all three occurences of 'chpasswd' in '/etc/init.d/tc-config' should help to overcome this issue. At least some quick testing I did seemed to confirm this assumption.

[roberts]

Excellent analysis. Will update as suggested. Thanks.