Bug#981693: Default Password hash Changes to Yescript for Bullseye

[Sam Hartman]

package: release-notes
x-debbuggs-cc: ***@packages.debian.org

Hi. I've never filed one of these before, and I'm in the middle of
several other things, so I decided to file the bug even if I get it not
quite right rather than forgetting.

Pam 1.4.0-3 changes the default password hash to yescript. That means
that users may get a security improvement if they reset their
passwords. It also has compatibility implications.

I'd recommend text like the following for the release notes

Password Hashing Uses Yescript by Default

The default password hash for local system accounts has been changed to
yescrypt (https://www.openwall.com/yescrypt/ ). This is expected to
provide improve security against dictionary-based password guessing
attacks, focusing both on the space as well as time complexity of the
attack.
To take advantage of this improved security, change local passwords; for
example use the `passwd` command.

Old passwords will continue to work using whatever password hash was
used to create them.


Yescrypt is not supported by Debian 10 (Buster). As a result, shadow
password files (`/etc/shadow`) cannot be copied from a Debian 11 system
back to a Debian 10 system. If these files are copied, passwords that
have been changed on the Debian 11 system will not work on the Debian 10
system.
Similarly, password hashes cannot be cut&paste from a Debian 11 to a
Debian 10 system.

If compatibility is required for password hashes between Debian 11 and
Debian 10, modify `/etc/pam.d/common-password`. Find the line that
looks like:

password [success=1 default=ignore] pam_unix.so obscure
yescrypt



and replace `yescrypt` with `sha512`.

[Debian Bug Tracking System]

tags -1 patch pending

Bug #981693 [release-notes] Default Password hash Changes to Yescript for Bullseye
Added tag(s) patch and pending.

[Paul Gevers]

Control: tags -1 patch pending

Hi,

Post by Sam Hartman
I'd recommend text like the following for the release notes
Password Hashing Uses Yescript by Default
The default password hash for local system accounts has been changed to
yescrypt (https://www.openwall.com/yescrypt/ ). This is expected to
provide improve security against dictionary-based password guessing
attacks, focusing both on the space as well as time complexity of the
attack.
To take advantage of this improved security, change local passwords; for
example use the `passwd` command.
Old passwords will continue to work using whatever password hash was
used to create them.
Yescrypt is not supported by Debian 10 (Buster). As a result, shadow
password files (`/etc/shadow`) cannot be copied from a Debian 11 system
back to a Debian 10 system. If these files are copied, passwords that
have been changed on the Debian 11 system will not work on the Debian 1

0

Post by Sam Hartman
system.
Similarly, password hashes cannot be cut&paste from a Debian 11 to a
Debian 10 system.
If compatibility is required for password hashes between Debian 11 and
Debian 10, modify `/etc/pam.d/common-password`. Find the line that
password [success=1 default=ignore] pam_unix.so obscure
yescrypt
and replace `yescrypt` with `sha512`.

I converted (with small modifications) this into the attached patch,
ready to push.

Paul

[Justin B Rye]

index fbe357b8..f3ff6d48 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -82,6 +82,45 @@ information mentioned in <xref linkend="morereading"/>.
</para>
</section>
+ <section id="pam-default-password">
+ <!-- buster to bullseye -->
+ <title>Password hashing uses yescript by default</title>
+ <para>
+ The default password hash for local system accounts has been
+ changed to <ulink
+ url="https://www.openwall.com/yescrypt/">yescrypt</ulink>. This
+ is expected to provide improve security against dictionary-based

^d

+ password guessing attacks, focusing both on the space as well as
+ time complexity of the attack.

Just what could it change to make such attacks harder *besides* space
or time complexity? If you're focusing on everything, you're not
focusing on anything! So I'd say it as

is expected to provide improved security against dictionary-based
password guessing attacks, in terms of both the space and time
complexity of the attack.

+ </para>
+ <para>
+ To take advantage of this improved security, change local
+ passwords; for example use the <command>passwd</command> command.
+ </para>
+ <para>
+ Old passwords will continue to work using whatever password hash
+ was used to create them.
+ </para>
+ <para>
+ Yescrypt is not supported by Debian 10 (buster). As a result,
+ shadow password files (<filename>/etc/shadow</filename>) cannot be
+ copied from a bullseye system back to a buster system. If these
+ files are copied, passwords that have been changed on the bullseye
+ system will not work on the buster system. Similarly, password
+ hashes cannot be cut&aml;paste from a bullseye to a buster system.

^ ^
That's &amp;, and another lost inflection.

hashes cannot be cut&amp;pasted from a bullseye to a buster system.

+ </para>
+ <para>
+ If compatibility is required for password hashes between bullseye
+ and buster, modify
+ <filename>/etc/pam.d/common-password</filename>. Find the line
+ <programlisting>
+ password [success=1 default=ignore] pam_unix.so obscure yescrypt
+ </programlisting>
+ and replace <literal>yescrypt</literal> with <literal>sha512</literal>.
+ </para>
+ </section>

(This seems a rather obscure corner case, but why not.)

[Debian Bug Tracking System]

Your message dated Thu, 18 Mar 2021 21:27:12 +0100
with message-id <0b121993-42a1-bfc6-7803-***@debian.org>
and subject line Re: Bug#981693: Default Password hash Changes to Yescript for Bullseye
has caused the Debian Bug report #981693,
regarding Default Password hash Changes to Yescript for Bullseye
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)