Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

[Sebastian Benvenuti]

When you set the password during the installation or also when you change it via the gnome-control-center you can insert a weak password (like "123456" or "qwerty" or "abcdef" or "password" itself) without any alerts, or so on.

The suggestion is a password strength verification that includes the most used passwords (like "1234" or "qwerty") and a dictionary that includes the word password in every language.
A special attention to language like Spanish where "password" is "contraseña", and where is the character "ñ" which can be recognize as a special symbol.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1044868/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Mattia Rizzolo (mapreri)]

Thank you for reporting this bug and help to make Ubuntu better!

Umh... I noted also gnome-control-center doesn't check for unsafe password... This is an idea for control-center and ubiquity, so I'll mark the bug against they.

In quantal the situation is the same...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

GNOME started using libpwquality in 3.5 (will be available in Ubuntu next cycle):
https://fedorahosted.org/libpwquality/

"The libpwquality library purpose is to provide common functions for password quality checking and also scoring them based on their apparent randomness. The library also provides a function for generating random passwords with good pronounceability. The library supports reading and parsing of a configuration file. "

That should take care of the gnome-control-center side, maybe ubiquity should use it as well...

[Dimitri John Ledkov (xnox)]

Can you please elaborate on the "without any alerts, or so on"?

As both account settings / account password & ubiquity show password strengths 'Too short / Weak / Fair / Good / Strong'

I do agree that the algorithms they use are not very strong, and they are biased against introducing characters instead of favouring length:

http://xkcd.com/936/

Is cryptographically true.

[Dimitri John Ledkov (xnox)]

Please answer the question in my previous comment.

[Sebastian Benvenuti (sebastianbenvenuti)]

To be more precise in the precise pangolin installer issue, the facts are:
1. "contraseña" is marked as "Fair", having selected a spanish keymap and
spanish language on the previous steps of the installer.
2. When I try an english installation (both keymap an locale), if I use the
password "password" is marked as weak.
3. No warning is displayed other than the word at the right of the topmost
password input field.
4. There's a big green checkmark next to the bottom password input field if
both passwords match

The word list to check against the password should match the locale
selected. The most basic thing to do is to match the fields hint (the text
that is grayed before the input) to the most insecure answer to the query.

The special characters are not the same on all languages. They should be
considered in base of the locale selected for the current algorithm to be
equally valid on different languages.
English is one of the most limited languages in terms of characters. It has
no written accents or any markings on letters. Spanish has the Ñ,
Portuguese and French use the Ç. When it comes to "internationalization" of
the algorithm these rules are most important.
The word "contrasena" (n instead of ñ) does not exist on the spanish
dictionary therefore it should be safer than the well spelled word,
"contraseña" (with the ñ). Same thing happens with the country name
"españa" and the unexisting word "espana".

Some examples:
contraseña (password) = Fair
españa (country name) = Fair
password (contraseña) = Weak
london (city) = Weak
unitedkingdom (country) = Weak
unitedstatesofamerica (country) = weak

I believe these examples must make my point clear.

About (3) and (4):
Most password check instances I've encounter during gnu/linux system
installations do warned me if I entered a weak password, asking for
confirmation to proceed with the weak password just in case I did not
noticed the "weak" value next to the password input field (View attached
images). Maybe is not a part of the bug, but certainly a missing feature.
Also, the big green matching passwords checkmark is more noticeable than
the "weak" (débil in spanish) word that warns about the password strength.

2012/9/3 Dmitrijs Ledkovs <email address hidden>

> Can you please elaborate on the "without any alerts, or so on"?
>
> As both account settings / account password & ubiquity show password
> strengths 'Too short / Weak / Fair / Good / Strong'
>
> I do agree that the algorithms they use are not very strong, and they
> are biased against introducing characters instead of favouring length:
>
> http://xkcd.com/936/
>
> Is cryptographically true.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1044868
>
> Title:
> Unsecure passwords reported as acceptable as well as strong ones
>
> Status in “gnome-control-center” package in Ubuntu:
> Triaged
> Status in “ubiquity” package in Ubuntu:
> Confirmed
>
> Bug description:
> When you set the password during the installation or also when you
> change it via the gnome-control-center you can insert a weak password
> (like "123456" or "qwerty" or "abcdef" or ...

[Mattia Rizzolo (mapreri)]

I thing checking the password in order to prevent the use of a dictionary word is excessive (it's true the password is important, but -in a desktop location- sometimes the security isn't a issue), but looking for a limited set of words, like "password" in all language, "qwerty", and so on...

@xnox: I let you change the bug state at your opinion

[Dimitri John Ledkov (xnox)]

I am not keen on implementing this just in ubiquity, some generic library/service would be nice. Please note that ubiquity has no space to include "common dictionary words" for all possible languages and locales.

[Sebastian Benvenuti (sebastianbenvenuti)]

Most of those words are already on the installation media.
The country names, being the most basic are obviously there since I have to choose it on previous steps.
The most important thing is that special characters should be based on the keymap and/or the selected locale.
Being ambiguous, like dns that accept "ñ" as "n", "ç" as "c", should solve the part were españa is not treated as a word but as espa(special character N)a.
Keep in mind that In most countries english is not the local language.
If the last impression, prior to the use of the installed system is "my password is ridiculously weak and it's accepted as fair without a warning" does not look secure enough. And it's misleading to have a strength check that does not respond to rules relative to the language, keymap and country declared before. However simple and inconclusive the verification is, it should behave the same way for every condition provided.
I remark the country name because it's prompted, even auto-selected with geoip with internet connection, before the password is entered. That check is obviously done with the unitedkingdom and unitedstatesofamerica.

[Dimitri John Ledkov (xnox)]

Some country names are, but not all.

Converting to ascii is not that easy, think about arabic languages.

I am confused about your remark about unitedkingdon and unitedstatesofamerica, we use geonames database which has comprehensive official, alternative and local/slang names of cities/towns/locations. It is not specific to UK nor USA. The database quality does vary from country to country.

"However simple and inconclusive the verification is, it should behave the same way for every condition provided."
Both halfs of this statement contradict each other. It currently is simple and inconclusive. It is not meant to be comprehensive and cover every possible condition.

This is out of scope for ubiquity project by it self and should be implemented externally. Do you know a library that provides such comprehensive functionality and calculates passwords strengths based on localised hints?

[Dimitri John Ledkov (xnox)]

Thank you for taking the time to make Ubuntu better. Since what you submitted is not really a bug, or a problem, but rather an idea to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at http://brainstorm.ubuntu.com/ where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion!

Individual packages do not have capacity to each develop their own algorithms, a strong / good library should be created or chosen out of multiple implementations and integrated in many packages: ubiquity & gnome-control-centre is just two of many places where users create a passwords. Therefore this will required deeper thought and better integration, given the high requirements, full i18n awareness is hard to achieve pragmatically.

As a rule of thumb concatenated short sentance (15 characters of more) will always be stronger than random / shorter strings.

And there will always be an easy password as perceived by the human, yet marked as hard by an algorithm.

We do not want it to be impossible to achieve "fair/good/strong" passwords. As it is merely an indication that a user is on the right track to a strong password, not an approval.

There are many installations and context where a strong password is not needed, nor desired by design. E.g. cloud images have passwordless accounts & passwordless root. Because access to those machines is locked down via public-key ssh connections. There is no way to know what authentication context will be used and what is the full security model. One password will not protect you.

[Jeremy Bícha (jbicha)]

As Seb already mentioned https://fedorahosted.org/libpwquality/ is a smarter password strength checker. The library itself is already in main.

$ rmadison -S libpwquality
libpam-pwquality | 1.1.1-1 | quantal/universe | amd64, armel, armhf, i386, powerpc
libpwquality | 1.1.1-1 | quantal | source
libpwquality-dev | 1.1.1-1 | quantal | amd64, armel, armhf, i386, powerpc
libpwquality-tools | 1.1.1-1 | quantal/universe | amd64, armel, armhf, i386, powerpc
libpwquality1 | 1.1.1-1 | quantal | amd64, armel, armhf, i386, powerpc
python-pwquality | 1.1.1-1 | quantal/universe | amd64, armel, armhf, i386, powerpc

Reopening the gnome-control-center bug since this will actually be fixed next cycle. I think this should stay open as a wishlist bug against ubiquity.

[Sebastian Benvenuti (sebastianbenvenuti)]

xnox, I have no intent to improve the password strength verification on the installer itself. That was a suggestion on the first post. My intentions in this thread is to make the same relative rules apply to the installer verification algorithm. As absolute ones, such as treating ñ as a special character are inappropriate in spanish or treating ç makes no sense in portuguese or french, since they are part of the local alphabet.
It was mentioned and link-referred that length makes stronger passwords but not if it's a known phrase or, lets say, country name. Including thousands of words per language/locale/keymap it's very hard, acknowledged. But making "ñ" look the same to an "n" or an "ç" the same to the "c" when spanish, french or portuguese are the declared locale/language on the installation process does not seem like an awkward request to fix the misbehavior of the password strength verification.
Another idea is: lets get rid of the whole verification process on locales/languages other than english, since it does not reflect any good practice at all, specially, compared to the relative situation in english settings.
To explain in more detail my previous paragraph: If I choose england as my country, english as my language, english as my keymap, the unitedkingdom password is marked as weak. It certainly should. But if my locales are spanish, my country espaÑa and my keymap the ES one, españa is a fair password to the installer. That is not the same behavior when taken relative to the declared variables (keymap,country,language) witch, at least to me, looks like a bug.
You mention that you do not want it to be impossible to achieve "fair/..." passwords, that is a merely indication of the right track to a strong password. Well, the country name should not be on that path. I really think someone else thinks like me, otherwise, why is unitedstatesofamerica (21 character long) a weak password?

The bug call remains. I believe everything to fix this mis behavior is already in place.

PS: Thank you to the pointers to improve the verification, I'll see what can I suggest in through those channels.
PS2: for the previous, present and following posts, I apologize for any language related confusion. English is not my first language and I sincerely understand that's a barrier to comprehend each other.

[Sebastian Benvenuti (sebastianbenvenuti)]

"There are many installations and context where a strong password is not needed, nor desired by design. E.g. cloud images have passwordless accounts & passwordless root. Because access to those machines is locked down via public-key ssh connections. There is no way to know what authentication context will be used and what is the full security model. One password will not protect you."

I know. That is why I defined the conditions where the bug appear to be obvious to me. Not a cloud image, not the server installer, not the alternate cd installer, the GUI installer from the 32-bit Ubuntu Live CD installing on a qemu-kvm VM.

[Sebastian Benvenuti (sebastianbenvenuti)]

reinodeespana = Weak (miss spelled)
reinodeespaña = Fair (spelled properly)
it's the "Ñ", witch is NOT a special character in any es_ locale.

republiquefrancaise = Weak (miss spelled)
républiquefrançaise = Good (spelled properly)

the "é" and the "ç" add extra strength, thought it's how french people write it.

Having in mind that the only access the password provides in a default installation is with physical access to the machine, not by a random internet bot or virus, how is that stronger when it's spelled correctly? (according to the declared locale/country/keymap)

[Jeremy Bícha (jbicha)]

This is fixed with gnome-control-center 3.6.3 which has been uploaded to raring for Ubuntu 13.04. You can't set 123456 as your password via System Settings.

I'm reopening the ubiquity task as ubiquity should be updated to use libpwquality. It's frustrating that it's possible to set a very easy password when installing Ubuntu but you can't set that password via System Settings.

[Gunnar Hjalmarsson (gunnarhj)]

On 2012-11-24 03:56, Jeremy Bicha wrote:
> This is fixed with gnome-control-center 3.6.3 which has been uploaded to
> raring for Ubuntu 13.04. You can't set 123456 as your password via
> System Settings.
>
> I'm reopening the ubiquity task as ubiquity should be updated to use
> libpwquality. It's frustrating that it's possible to set a very easy
> password when installing Ubuntu but you can't set that password via
> System Settings.

Personally I'd prefer a slightly different solution. _Encouraging_ strong passwords, as the bug summary says, is excellent; making strong passwords _mandatory_ is not. Ideally there should be an option for admins to decide the level of security by selecting either "recommended" or "mandatory". Probably a suitable topic for an upstream bug...

[Jeremy Bícha (jbicha)]

Here's the bug to allow overriding the strong password check: https://bugzilla.gnome.org/show_bug.cgi?id=688315

I still think ubiquity should use the same library for password strength checking (python-pwquality).

Also, "contraseña" is a valid password because it's 9 characters long; "passwords" is also valid. cracklib, the underlying library, can use wordlists.

[Gunnar Hjalmarsson (gunnarhj)]

On 2012-11-24 22:38, Jeremy Bicha wrote:
> Here's the bug to allow overriding the strong password check:
> https://bugzilla.gnome.org/show_bug.cgi?id=688315

So it was already written. Thanks!

I'll add a comment saying that I support it. Hopefully it will make Matthias happy, so he supports my proposal at https://bugzilla.gnome.org/show_bug.cgi?id=687945. ;-)

> I still think ubiquity should use the same library for password strength
> checking (python-pwquality).

Agreed.

A better algorithm does not preclude an option for admins to decide whether it's mandatory to comply with it, right?

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Gunnar Hjalmarsson (gunnarhj)]

Yes, the password check in the installer is still not in sync with the check in g-c-c.

[Marcus Tomlinson (marcustomlinson)]

Thanks for the update Gunnar.