Hashing with Yescrypt / login problem on latest Debian

Post Reply
d2d
Posts: 5
Joined: Fri Dec 10, 2021 12:36 pm

If you have updated Debian to latest and cant login - look inside /etc/shadow, if your user hash starts with $y$ that means, you are using Yescrypt algo.
What is the problem? Latest version of Debian switched to Yescrypt as default hashing algoritm. Myvesta doesn't know anything about it. Password change, reset, etc dont work. Hashing algos hardcoded in many files of myvestacp, some in bash, some in php. That needs to be reworked, Yescrypt needs to be added.

What can you do now?
Temp fix to login (if you cant)- use web panel password reset, go via url in email, reset password and you will be logged in this browser until logout.
OR
in console run comand

Code: Select all

echo "your_user:your_password" | chpasswd -c SHA512
For example echo "admin:hardpass" | chpasswd -c SHA512
OR
Change password with sha-512 hash manually in /etc/shadow. If you dont know what are doing - dont do it please, read this first.
1. Generate sha-512 hash using mkpasswd tool.

Code: Select all

mkpasswd -m sha-512 'your_password'
2. Edit VERY gently /etc/shadow file under root, use hash from mkpasswd, insert it between colons. Its between user: and :18556 on this picture.
Image
OR
You could change some myvesta files to be able to reset, change, login etc
PHP implementation of yescript here.
But they will be overwritten with latest update, so you need to keep copy of it.
Last edited by d2d on Thu Jan 20, 2022 2:26 pm, edited 1 time in total.
User avatar
myVesta
Site Admin
Posts: 928
Joined: Fri Jun 19, 2020 9:59 am
Has thanked: 8 times
Been thanked: 6 times

Thanks.
We choose to not using Yescrypt in order to keep backup/restore compatibility from deb8,9,10 to deb11.

Thanks for yescrypt php implementation.
Where exactly you put that php script?
d2d
Posts: 5
Joined: Fri Dec 10, 2021 12:36 pm

myVesta wrote: Thu Jan 20, 2022 11:06 am Thanks.
We choose to not using Yescrypt in order to keep backup/restore compatibility from deb8,9,10 to deb11.
Understand. But now its behavior could be rather unpredictable too. As after making system update, user cant login, he makes password reset, his browser autologed and user would think that all is good now. After that new bakups creation, old backups deleted and again the same problem.
myVesta wrote: Thu Jan 20, 2022 11:06 am Thanks for yescrypt php implementation.
Where exactly you put that php script?
Personally me didn''t change vesta files, but it should be integrated to web/reset/index.php at least, maybe other files, where php used to create/check password. bin/v-check-user-password use -eq operator for hash detection, and failing at "y" letter, need to be fixed with equal sign. I didn't checked all files, as I have few users on few servers, so manually password change was better solution for me. It's not my implementation of yescrypt btw.

IMHO support for Yescrypt MUST be implemented. It could be optional, or at least notify user about this problem right now.
I think rather good fix could be in changing every call to chpasswd with -c SHA512 parameter in bash scripts, or alias, but i'm not sure about it.
User avatar
myVesta
Site Admin
Posts: 928
Joined: Fri Jun 19, 2020 9:59 am
Has thanked: 8 times
Been thanked: 6 times

d2d wrote: Thu Jan 20, 2022 2:20 pm Understand. But now its behavior could be rather unpredictable too. As after making system update, user cant login, he makes password reset, his browser autologed and user would think that all is good now. After that new bakups creation, old backups deleted and again the same problem.
Not sure to understand.
I never get a situation that user can't login after system update.
At least I didn't see that some package is updating /etc/pam.d/common-password
https://github.com/myvesta/vesta/blob/9 ... 1448-L1451
d2d
Posts: 5
Joined: Fri Dec 10, 2021 12:36 pm

myVesta wrote: Thu Jan 20, 2022 3:12 pm
d2d wrote: Thu Jan 20, 2022 2:20 pm Understand. But now its behavior could be rather unpredictable too. As after making system update, user cant login, he makes password reset, his browser autologed and user would think that all is good now. After that new bakups creation, old backups deleted and again the same problem.
Not sure to understand.
I never get a situation that user can't login after system update.
At least I didn't see that some package is updating /etc/pam.d/common-password
https://github.com/myvesta/vesta/blob/9 ... 1448-L1451
I mean user cant login to web panel, not ssh. Mine /etc/pam.d/common-password was changed 11 of Nov.

Code: Select all

# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords.  The default is pam_unix.

# Explanation of pam_unix options:
# The "yescrypt" option enables
#hashed passwords using the yescrypt algorithm, introduced in Debian
#11.  Without this option, the default is Unix crypt.  Prior releases
#used the option "sha512"; if a shadow password hash will be shared
#between Debian 11 and older releases replace "yescrypt" with "sha512"
#for compatibility .  The "obscure" option replaces the old
#`OBSCURE_CHECKS_ENAB' option in login.defs.  See the pam_unix manpage
#for other options.

# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password        [success=1 default=ignore]      pam_unix.so obscure yescrypt
# here's the fallback if no module succeeds
password        requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password        required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config


User avatar
myVesta
Site Admin
Posts: 928
Joined: Fri Jun 19, 2020 9:59 am
Has thanked: 8 times
Been thanked: 6 times

Hmmm, ok.
I will make a check if file is overwritten... until I make support for Yescrypt.
eris
Posts: 1
Joined: Tue Jan 05, 2021 12:23 am

myVesta wrote: Thu Jan 20, 2022 6:16 pm Hmmm, ok.
I will make a check if file is overwritten... until I make support for Yescrypt.
If you upgrade from Debian 10 to 11 common-password gets overwritten causing new passwords generated to break when generating new password.

In Hestia we have added a check if y is the hashed method and provide an error
Post Reply