Screen saver refuses to unlock if the password is only one char

[rogueeve]

Steps to reproduce:

• From DeskBar, click Haiku button/Preferences/ScreenSaver
• For convenience, set all sliders to 30 sec and activate a "Fade now when mouse is here" corner.
• Check "Enable password lock" and "Set Password".
• Choose "Custom password" and enter a single character, such as "a". Click OK.
• Move mouse to previously selected corner to enable screen saver, as soon as screen saver comes on move mouse again to get password prompt.
• Enter the previously selected password and it will refuse to unlock.

Tested on: R1/Alpha1 R33000 RC. I put this under "System" instead of "add-ons/screen savers" because it is potentially a more serious bug than "screen saver bug" would suggest, as it can result in data loss if you had files open since you have to reset your computer.

[rogueeve]

I looked at the source and I know what is wrong now. It should be a fairly simple patch. Here is what is going on.

Check /haiku/src/preferences/screensaver/PasswordWindow.cpp, line 139, in function PasswordWindow::MessageReceived(). This is the function that changes the screen saver password.

You can see that the screen saver password is hashed using the crypt() function, like so:

fSettings.SetPassword(crypt(fPasswordControl->Text(), fPasswordControl->Text()));

However, this is an incorrect usage of the function. ​http://www.opengroup.org/onlinepubs/9699919799/functions/crypt.html states that the 2nd argument to crypt, the salt, shall be at least two characters long and that it shall consist of only A-Z, a-z, 0-9, or '.' or '/'.

So by using the password itself as both the key and the salt, the crypt() algorithm fails when the password is only one char long, and it could also possibly fail if the password contained any unusual chars.

I am not an expert on the crypt() function but it seems that typical use is to choose a "magick" two-character salt such as "AQ" or whatever and pass that in. I couldn't find where the other side (the password checking) comes in at, but if both of those instances where adjusted to use a common constant salt the issue should be resolved.

[stpere]

Hi,

It should be fixed in hrev33069. Thanks!