Currently, the debian-installer warns the user to use a "secure" password (6
chars long, with different case letters and punctuation characters) but does
not make an attempt to determine if the user is indeed using one.

Since there are many SSH brute-forcers in the Internet now constantly probing
systems I think it's best if the d-i could warn the users when he "sees" a
user or root password that he believes is insecure.

There are two ways to do this:

- the hard way, like Owl [1], which implements a password checking module
  (pam_passwdqc, which was written by Solar Designer) and goes even
  further by proposing random passwords if the user is unable to provide
  one.

- the simple way, see attached code, which just tries to flags vulnerable
  passwords

IMHO, the installer should:

1.- ask for a password
2.- set the password
3.- check the password
4.- if the password is not "secure" warn the user and give him the
    option to change it (go back to 1) or to proceed

Maybe the check should just be done the first time the user enters a password
in order to avoid a frustating loop from the user POV of: "think a password",
"got it", "damn, the system refuses it", "try think another one", "got it",
"damn! he doesn't like this one either", etc.

If this idea has merit, please say so and I will try to integrate the
attached code with user-setup's user-setup-ask (maybe through a external
script instead of rewritting it in sh?)

Regards

Javier

[1] http://www.openwall.com/Owl/

I think this is an intersting suggestion.

The only drawback I see is sounding a little bit annoying to our
users, especially the less skilled ones but, well, this is about
security and we have to use some pedagogy..:)

About the implementation, I'm not sure that I'm fond of the perl
scripting, mostly because the advantage of D-I is its easy
"hackability" for testing purposes....

I'd better see this integrated in user-setup-ask but my opinion does
not have to be the only one here....as I'm perfectly unable to do the
job, so the final decision is up to the one doing the job, I mean you,
Javier..

I prefer the "simple" method which is probably enough.

This will require writing a new template for warning users about weak
passwords. I suggest of course a boolean one, so that people who
insist on using weak password can do it.

Hello.

I wrote a password checking feature implement by shell script in function.sh.
I attached a patch which name is passwd_check.patch.

This logic checks these.
1. The password length should be more than four.
2. The password shouldn't equal login account.
3. The password shouldn't contain login account.
 e.g. root's password doesn't allow these password.
      "root123"
      "123Root"
      "1ROOT23"
4. The password should contain lower cases, upper cases, numbers.

I'm not sure that people wants to use it.
so, I set a debconf priority low.

Cheers,

Masami Ichikawa <masami256@gmail.com> writes:

I personally liked it a lot. I'd just want to ask you to check the
code indenting since it has some mistakes.

The programm code in the patch seems reasonable.
a Thing I like to see changed,
is "password check" into "password strength check"


Op 16-06-2007 om 21:41 schreef Masami Ichikawa:

 a password strength checking feature


<snip what="header of patch"/>

# Return a true value if password seems to be strong enough
chkpasswdstrength()

???
That check doesn't look reasonable ...
   Template: passwd/chkpasswdstrength
   _Description: : Check password strength?
    Stronger password will make a more secure system.
   Template: user-setup/chkpasswdstrength-bad
  +_Description: The password does not seem strong.

  + The password you entered is not a strong password.

  + Make a mix of capital letters, small letters AND numbers for the password.
  +		# Ask if user wants to check password strength
  +		db_input low passwd/chkpasswdstrength || true
  +		db_input low passwd/chkpasswdstrength || true
  +					    db_fset user-setup/chkpasswdstrength-bad seen false
  +					    db_input critical user-setup/chkpasswdstrength-bad
  +					    db_fset user-setup/chkpasswdstrength-bad seen false
  +					    db_input critical user-setup/chkpasswdstrength-bad


Cheers
Geert Stappers

Hello:-)

Thanks for Otavio Salvador and Geert Stappers to reviewing.
I'll repair the point pointed out ASAP.

Cheers,

Quoting Masami Ichikawa (masami256@gmail.com):

Thanks a lot for this contribution which may help starting some work
about this feature.

Some ppl may find the checks slightly incomplete, but that doesn't
prevent anyone to improve them.

Please let me comment about the wording of the propsoed templates:

That's a tricky case ; Most of the time, the people who might need
such feature....are those who will run D-I at default priority.

I'd vote for the password strength check to be asked at low priority
so that "experts" can decide to skip it....BUT the default answer to
be "True".
Type: boolean
Default: true
_Description: Reject weak passwords ?
 Please choose whether you want the entered passwords strength to be
 checked and passwords found as 'weak' to be rejected.

Template: user-setup/chkpasswd-bad
Type: error
_Description: Weak password
 The strength of the password you have chosen is low.
 .
 Weak passwords can compromize the system's security, so please
 choose another password.

s/ ?/?/ !!!!!!!

Hello.

Thanks for people who gave me comments:-)
I wrote a new patch which changed these.

* s/chkpasswd/checkpasswdstrength/
* fix indent.
* rewrote messages in user-setup-udeb.templates.
* default answer is true.
  The user has to choose a strong password now in default.

Cheers,

Op 17-06-2007 om 21:21 schreef Masami Ichikawa:
 <snip/>

If I understand the above code snippet correct,
then it does allow user='root' and password='root'
and does depend on further checks.

Please simply to source code into

 +	ret=`echo $passwd | grep -ci $user`
 +	if test $ret = 1; then
 +		return 0
 +	fi

It does better match
 +	# password shouldn't contain login account.
and it will prevent user='R00tme' with pasword='R00tme'


 <snip/>

Nitpicking:

Start 'choose' with a capital.



Thanks for the patch
Some one who should find out,
if he could had apply the patch into versioning system.

Should be:

_Description: Reject weak passwords?

s/choose/Please choose

I suggest removing 'another':

 Please choose a password that....

on 06/18/07 01:04, Geert Stappers wrote:
Yes. That's right.
when I tested like that user="foo" password="food123", I thought this case may be allowed.
because, this case grep returns 1.
so, I added "if test $passwd_len -ge $user_len; then" line.
I couldn't find another solution:-(
Yes.

Cheers,

on 06/18/07 03:02, Christian Perrier wrote:

Yes. should be.

Yes.

Cheers,

Masami Ichikawa wrote:

I'd suggest turning this around. Don't first ask whether to check
passwords. Just check them. If the password is weak, prompt y/n whether
to accept the weak password. The benefits are:

a. It's easier to decide whether a weak password should be accepted once
   you've actually entered it. It could even indicate what's wrong with
   the password in its message.
b. This avoids the extra question "most" of the time, assuming people
   often enter a strong password.
c. This should be reasonably non-annoying for testers, who tend to use
   weak passwords.

Also, it seems to me that it would be much better to use the existing
cracklib stuff for password strength checking rather than
re-implementing that. If it could be made into a small enough udeb..

Hello.

on 06/18/07 03:02, Christian Perrier wrote:

I fixed messages in user-setup-udeb.templates.
maybe this patch is final version. also, joey's suggestion is interesting to me.
so, I'd try to implement his suggestion.

Cheers,

(Please send mails to -submitter so I can actually see them, I'm the
originator of this bug but I'm not subscribed to debian-boot)

Joey, the cracklib2 library, IIRC, does not check for password robustness
(i.e. size, use of characters, etc.) but, actually, tries to crack it using
its dictionary. This prevents people from entering, for example 'debian' or
'debian123', as a password. Including it in d-i (as I suggested) would mean
providing a dictionary for cracklib's (in installed systems it is available
at /var/cache/cracklib/ and generated from from the local dictionaries being
installed) which could be rather large: 820K in my local filesystem based on
the 1,7M dictionary files I have installed (including spanish and english
words)

The libpam-passwdqc module, however, when stacked in /etc/pam.d/passwd, will
do both the cracklib2 checks *and* checks for password robustness (minimum
length, character sets in the password, etc).

If we want to go that way I suggest we do what Owl's installer does [1]:

- have PAM be configured to use libpam-passwdqc per default in any Debian
  system

- have d-i install some common dictionaries, libpam-passwdqc and cracklib2 at the target system
  (that way Cracklib's dictionary will be generated there)

- chroot to it and use PAM to set the root/user password (see
  pam_root_password [2])

- let PAM tell us if the password is valid or not.

This could be done *in*addition* to some simple checks done in the installer
itself, as I suggested initially and Masami Ichikawa implemented, as long as
the checks done in d-i are consistent with libpam-passwdqc's configuration.

This has the advantage that password checking would be a standard setup in
any Debian system, regardless of whether the password is set on d-i or it's
changed later. And would actually apply to all users (not only those
configured through the d-i).

It has the disadvantadge that is a major change that implies changes in other
packages (PAM's default configuration) and significant coding (although this
could be simplified if reusing Owl's code [3], which is already available)

Another (different way) that could be implemented as an alternative
would be to:

- have d-i provide the cracklib-runtime + libcracklib2 + a proper (pregenerated)
  dictionary (note the size increase, as described above)

- do some basic password checks within d-i (with the patch provided in this
  bug)

- use the 'crack_testlib' binary to run a test on the password and let the
  user know if the password is based on a dictionary password.

That would be easier to code and has the advantage that no other changes are
needed (to PAM) but it has the disadvantages that the d-i size increases
(which is an issue currently) and is also duplicating code (as the password
checking code is already present in libpam-passwdqc, which we are not using
in this case)

Hope that helps clarify stuff,


Javier


[1]
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/owl-setup/setup/root_passwd_settle.cpp?rev=1.3;content-type=text%2Fx-cvsweb-markup

[2]
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/owl-setup/setup/pam_root_passwd.cpp?rev=1.2;content-type=text%2Fx-cvsweb-markup

[3] The .spec file claims It's BSD-licensed, but it would be nice to ask
Solar Designer to add proper licenses to the headers of all the files in
there, to avoid any licensing confusion with it.

While I agree that the first proposal needs more work it also looks
much better to be ... we can add it in a way we can disable it if need
(during install, using preseeding) and then allow for it usage or not.

Second proposal looks simpler but I dislike the idea of first user
being check only.

While I agree that the first proposal needs more work it also looks
much better to be ... we can add it in a way we can disable it if need
(during install, using preseeding) and then allow for it usage or not.

Second proposal looks simpler but I dislike the idea of first user
being check only.

Op 19-06-2007 om 21:58 schreef Masami Ichikawa:
 <snip/>

Those three tests can be reduced to one single test:

 +	# password shouldn't contain login account.
 +	ret=`echo $passwd | grep -ci $user`
 +	if test $ret = 1; then
 +		return 0
 +	fi


Cheers
Geert Stappers

All:

I do realize the importance of good/strong password and the desire of
guiding installers to used them. I also realize the need for ease of use
especially for new users.

If I'm new to Debian installer I don't care about good/strong passwords
as I know I will probably muck it up or want to redo the install several
times. So setting the root password to "root" is very convenient and not
a security risk.

Many new users to Debian complain how difficult and geeky it is to use.
Some of them even go back to MS. Opensource should be about not only
choice but also simplicity.

If I want to run a kiosk that only displays pictures of the building its
in using a stand alone machine locked in a box, I don't care about
security. It would really piss me off if I was force to use a long
complex password as this would be a waste of my time.

Let the user/installer chose whether he/she wants to use "root" as the
root password or some 256 char long password with whatever set of
characters without bugging them. The guide is there and guess what...
the user/installer can read! If they chose to ignore the guidelines then
that is there choice.

Quoting Steven Demetrius (steven.demetrius@fiwwi.com):

This is anything but a legend now. Sorry, but I (and probably many
other D-I developers) feel sick when reading this as a full default
Debian install is as painless as any other Linux system install. I
suspect many Linux so-called gurus (or pseudo ones) to be responsible
for this and continue to spread out such legend.


Anyway, I think you'r emissing the point of the bug report.

Being able to use weak passwords is not something we plan to remove
the possibility for. The point is only adding a check and warn users
when they use weak passwords...giving them the opportunity to either
go on, knowing what they're doing) or change their mind and use a
stronger password.

Even in the closed-source software world, this is something that is
done more and more (just look at the password policy for many
corporate environments based on Microsoft products), so I don't think
this is something that will scare users.

Again, this is not about strictly enforcing strong passwords.

Anyawy, all this is science-fiction right now as nobody cared enough
to implement a good password quality test in user-setup.

Christan:

Thanks for your response.
As you've quoted my comment was aimed a Debian in general. I have also
previously commended the d-i team on its improvement of the d-i in etch.
Much easier to use. In fact its now easier to use than MS's installer.
The GUI installer is very well done. Good job.

As long as the check is just a check and a warning then I have no
problem with it.

Unfortunately this was not the case with the local and time zone
settings (bug 448328). Just wanted to make sure the same thing didn't
happen here.

Again I think the d-i team has done an excellent job in improving the
d-i. Keep up the good work.

PS. I have an idea for doing Debian training. Can you point me in the
right direction. I don't want to go into details here as this is not the
right place for it. You can email me directly.


Thanks.


Christian Perrier wrote:

# Anyawy, all this is science-fiction right now as nobody cared enough
# to implement a good password quality test in user-setup.

tags 364526 +patch

Hello,

We have created custom Debian 13 (trixie) installation ISOs with
pre-configuration, and
we would like to follow up on this request with a specific use case.

Our installations create only the root account (passwd/make-user false), and
our security policy requires that the root password be at least 7
characters long,
including one uppercase letter, one lowercase letter, one digit, and
one special character.
Currently, user-setup only checks that the password is not empty and
that both entries match; it does not validate the password strength,
and I have not found
any preseed option to enforce any policy.

It would be very helpful if the policy could be configured via preseed, for
example:

  d-i passwd/policy/mode      select       enforce
  d-i passwd/policy/minlen    string       7
  d-i passwd/policy/require   multiselect  uppercase, lowercase, digit, special

where passwd/policy/mode could be one of the following:
 - none: current behavior, no validation (default);
 - warn: display which requirements are missing and allow the user to keep the
   password (in line with what was suggested earlier in this bug report);
 - enforce: reject the password and ask again until it complies.

Thank you,
Emerson Comar