Tails

#7 Updated by touss 2019-11-26 01:36:34

Hi @intrigeri,i would appreciate some advice on this:
I tried to make the GUI as similar as possible with to that of the GNOME Disks.It uses Data::Password::zxcvbn to estimate the given passphrase strength (is this ok or should we use another module?).I’m not sure of the position of the warning label; would it be better to align it with the level bar? I also added an extra commit to make mouse clicks not grab focus in Show passphrase button.

#9 Updated by segfault 2019-11-27 08:25:55

Hi,

thanks for working on this!

touss wrote:
> I’m not sure of the position of the warning label; would it be better to align it with the level bar?

It would be helpful if you could add a screenshot of that, and then we can ask @sajolida for his opinion.

#11 Updated by sajolida 2019-11-28 18:38:32

Cool! I’m not worried so much about the alignments of the different elements but I prefer image2.png.

I’m a bit more worried about the quality of the indication itself.

Password, password strength, and password policies are a really hot topic in usable security.

Just to give one example: https://blog.fleetsmith.com/password-security-guide/.

• I like the fact that the algorithm seems to detect weak l33t-speak and not pretend than “p4ssw0rd” is stronger than “password”.
• I like the fact that the algorithm doesn’t force the use of numbers or special characters, for example for diceware passwords.
• I’m a bit concerned by the strength levels. For example “password1234” gives me “Good” in GNOME Disks and “password1234!” gives me “Strong”, cf. ““I Added ‘!’ at the End to Make It Secure” :) (https://www.usenix.org/system/files/conference/soups2015/soups15-paper-ur.pdf)

Could we higher the bar to “Good” and “Strong”?

#12 Updated by intrigeri 2019-11-28 19:28:04

Hi touss & others!

First, thanks a lot for working on this!

Wrt. how much we like the passphrase length checking algorithm, I’m glad we have sajolida’s input here. touss, see the previous comments on this ticket (you were not on the list of watchers so you did not get notified of sajolida’s questions).

A few notes from me:

• Depending on how much we feel this feature is important, some tools are readily available to us, while some others require more work (e.g. packaging new stuff for Debian). Of course, they won’t yield the same feedback for a given passphrase.
• At first glance, I would be tempted to favor consistency over security. That is, it would feel weird to me to have the same password give different feedback here than in GNOME Disks.
• I’d like us to keep in mind that we currently have no passphrase check at all. Arguably, even the worst passphrase checker will provide better educated info than what our average user would guess by themselves: at least it’ll warn against lots of obviously bad ideas. IMO this outweigh the risk for giving a false sense of security, but I may be wrong.
• GNOME Disks uses libpwquality. I don’t know how good it is, but if we want to be consistent with GNOME Disks, I have a few question for touss:
  • Are there Perl bindings available for libpwquality?
  • Failing that, does libpwquality provide gobject-introspection data? If it does, we can use Gobject-Introspection to use this library.
  • Failing all of the above, I see Buster has libpwquality-tools, which ships a pwscore CLI. I optimistically assume we could use it to provide feedback similar to GNOME Disks’.

> It uses Data::Password::zxcvbn to estimate the given passphrase strength (is this ok or should we use another module?).

I did not evaluate the quality of the feedback provided by this library; I’m inclined to trust sajolida’s input on this.

Upstream seems adequately maintained and the code looks sane.

The only problem I see is that this module is not in Debian, which is a requirement before we can use it; all the dependencies seem to be there though (at first glance). I’m a Debian developer myself and a member of the Debian Perl Group, so adding this module to Debian should not take more than a couple hours to me, if we decide 1. that’s really the module we want; 2. it’s worth this sort of effort. Then, maintenance is done collectively over there; putting a few hours/year into it would be the minimum; sky is the limit wrt. the maximum :) I’m fine with doing this work myself but I’d rather mentor touss to join the Debian Perl Group and do it themselves. It’s a very nice group of people and the most active ones are very Tails-friendly. touss, what do you think?

I see libcrypt-cracklib-perl is in Buster already. Would it do the job?

Perhaps you could explain us why you picked this module specifically?

#14 Updated by sajolida 2019-11-29 11:14:56

> * At first glance, I would be tempted to favor consistency over security. That is, it would feel weird to me to have the same password give different feedback here than in GNOME Disks.

From our VeraCrypt survey, 41% of our users in 2018 didn’t even know
what GNOME Disks was:

https://tails.boum.org/blueprint/veracrypt/

I’m tempted to think that a lot of the ones who did know what GNOME
Disks was came from the 45% of Linux users in our user base.

As we make Tails easier to use for Windows and macOS users, I expect
only a minority of our target user base to be ever confronted with GNOME
Disks years from now.

Another consistency that we should be worried about is between the
advice that we give in our doc and what the software tells people.
We’re currently saying in /install/win/usb#create-persistence:

« We recommend choosing a long passphrase made of five to seven random
words. »

Which is probably the shortest good advice that we can give. It also
matched the NIST guidelines, referenced from the fleetsmith.com article
linked above.

> * I’d like us to keep in mind that we currently have no passphrase check at all. Arguably, even the worst passphrase checker will provide better educated info than what our average user would guess by themselves: at least it’ll warn against lots of obviously bad ideas. IMO this outweigh the risk for giving a false sense of security, but I may be wrong.

I’m not so sure. Right now, when someone types in “password1234” we
don’t tell them anything. With the meter from GNOME Disks, we would
explicitly tell them that it’s a good password.

I think that it’s not a good password in the context of Tails and we
should probably not advocate for any simple combination of any 2 of the
Top 500 passwords:

https://www.symantec.com/connect/blogs/top-500-worst-passwords-all-time

> * GNOME Disks uses libpwquality. I don’t know how good it is,

I couldn’t find any information about the algorithm used by libpwquality
in their GitHub repo, though I didn’t read the code.

I could find an article comparing the password meter from different
online services and the Dropbox algorithm seems to be among the
strictest ones:

https://www.ndss-symposium.org/wp-content/uploads/2017/09/06_3_1.pdf

I tried zxcvbn (what a name!!!) from the python3-zxcvbn package and it
tells me that “password1234” is “a very common password”. I like that.

Sooooo, I would propose to:

• Do some more tests with zxcvbn, see how it compares to libpwquality,
  and whether we think that its results make sense in the context of
  Tails.

• If so, advocate for using zxcvbn in GNOME Disks as well. I haven’t
  checked thoroughly but I would guess that this password meter is used
  only on the passphrase of encrypted volumes. Then it would make sense
  for GNOME Disks to be a bit more strict. I see several bindings for it
  in Debian and we might even consider writing a patch to GNOME Disks
  upstream. Until then, the meters in Tails and GNOME Disks might be
  inconsistent but I would prefer that to advocating for “password1234”.

• If not, maybe we should give up on having a meter in the first place
  and instead move our advice from our doc to the Persistence creation
  app.

I hope that I’m not being too much of a downer here @touss. It’s so cool
to see you working on the Persistence app, it’s one of our key software
and we could improve it so much!

#17 Updated by touss 2020-01-06 15:11:36

> I also tested what strenght label we would get for every 2 of the top 500 passwords combined for libpwquality,zxcbn
Here is the list that i used:
https://salsa.debian.org/touss-guest/pwcheck/raw/master/500-worst-passwords-combined.txt

#20 Updated by sajolida 2020-02-25 21:36:18

Wow, such a detailed analysis!

To make it easier to compare libpwquality and zxcbn, I combined both your results and the ones from the paper. I’m only counting here the passwords that are “Very Weak”, “Weak”, “Fair”, or “So-so”. It’s good because it comparing their performance on real databases (and not only my anecdotal evidence on 2 x Top 500 passwords).

    libpwquality        zxcvbn      total
Top500  499 100%    499 100%    499
Cfkr    181 100%    181 100%    181
JtR 3545    100%    3545    100%    3545
C&A 285466  93% 260971  85% 306706
phpBB   182574  99% 164894  89% 184389

So on the 2 big databases (C&A + phpBB), zxcvbn would complain about 10% more passwords; not to bad but not a huge difference either.

I would say that we should:

• Use zxcvbn if it’s not much more complicated than using libpwquality and especially if it seems doable to advocate to GNOME Disks to do the change as well.
• Use libpwquality otherwise.

But I don’t have a strong opinion either :)

@intrigeri: What do you think?

@touss: What would find more exciting to work on?

#22 Updated by touss 2020-02-29 01:23:29

> @touss: What would find more exciting to work on?
I think i would prefer working with zxcvbn. I’m a bit worried if we use libpwquality, because i didn’t find a better way to use it other then using pwscore CLI and i suppose calling pwscore CLI every time the user types something would be a performance issue.

> * Are there Perl bindings available for libpwquality?
> * Failing that, does libpwquality provide gobject-introspection data? If it does, we can use Gobject-Introspection to use this library.
I’m also not sure how much work it’s going to take to implement some of these solution in case we decide to use libpwquality without pwscore CLI. Maybe we can find another solution

> The only problem I see is that this module is not in Debian, which is a requirement before we can use it; all the dependencies seem to be there though (at first glance). I’m a Debian developer myself and a member of the Debian Perl Group, so adding this module to Debian should not take more than a couple hours to me, if we decide 1. that’s really the module we want; 2. it’s worth this sort of effort. Then, maintenance is done collectively over there; putting a few hours/year into it would be the minimum; sky is the limit wrt. the maximum :) I’m fine with doing this work myself but I’d rather mentor touss to join the Debian Perl Group and do it themselves. It’s a very nice group of people and the most active ones are very Tails-friendly. touss, what do you think?
Considering that this is the only problem,i would really appreciate doing this work if @intrigeri is still willing to mentor me.

#23 Updated by touss 2020-02-29 14:18:46

I’m a beginner so I’m willing to work on what you think it is the best solution for Tails.