Tails

#2 Updated by Gaff 2018-06-08 16:53:50

Oh right - can you point me to the discussion?

The main risk here is that it saves the users from themselves. Users will forget to lock the screen and then risk having their unattended machine accessed. See also: Feature #15488

I can think of a few ways to solve this:

• Demand users setup a password when they first use the machine.
• Persist /etc/shadow via the persistence mechanism.
• Change the tails-locker script to save the (encrypted) password and have a startup servers that does `usermod -p` on startup using this data.

Would any of these solutions be acceptable?

#5 Updated by Gaff 2018-06-10 17:44:39

In such rare circumstances, swtting a root password in the greeter would override the persisted password. Simple ;)

Most users are familiar with the pattern that your computer locks automatically if you leave it idle. I think it is surprising / dangerous that tails does not do this by default. Especially for persistent users who may not be certain if they have locked their desktop manually this session or not.

#7 Updated by segfault 2018-06-11 12:38:17

segfault wrote:
> Gaff wrote:
> > * Demand users setup a password when they first use the machine.
>
> That doesn’t solve the problem of how to persist the password.

… but we could still consider asking for the password after running tails-persistence-setup, if the user chose to persist the screen locker password.

#8 Updated by intrigeri 2018-06-11 12:51:01

> For the longest time we didn’t have a screen locker in Tails at all (except if you set the admin password), and I don’t recall getting a lot of requests for this by users (@tails-support: please correct me if this is wrong).

FWIW the lack of a screen locker was reported to me (in person) as one of the most painful aspects of Tails many times.

#9 Updated by Gaff 2018-06-11 12:55:56

segfault wrote:
> I also see the risk that users might forget their password (especially existing users who are used to our session passwords) and lose their unsaved work because they can’t unlock the screen.
>
> Another UX problem could be that the admin password set in the greeter will overwrite the screen locker password.

You could go the extra mile and replace “admin password” with “enable sudo” for the case where a password is persisted. Though having an option in the greeter to overwrite the password solves the problem of users forgetting their persisted password.

> Gaff wrote:
> > * Demand users setup a password when they first use the machine.
>
> That doesn’t solve the problem of how to persist the password.

My thinking here is that it’s more important that a password is configured each session, than to have it persisted. But yeah this is an inferior option.

> we could still consider asking for the password after running tails-persistence-setup, if the user chose to persist the screen locker password.

Presumably the Debian default is to ask for a user password after boot? So this should be simple-ish.

#11 Updated by Gaff 2018-06-24 08:38:52

Without redesigning Linux passwords / sudo significantly it’s only possible to have one password! Or are you referring to the encryption password?

Personally I think it’s important to have a screen lock option, even if users don’t like it. There’s plenty of other things tails / tor does to save users from themselves, this should be on that list.

(I’m also happy to do some of the dev work here).

I think the options are:

* When an administrative password is set any persisted password is ignored.
This is slightly surprising, but only affects uses who use the admin option (which should be used rarely).
Simple to implement
* When the admin password is set the persisted password is replaced.
The danger here is the users may not know this has happened
* When you unlock the greeter it loads and persisted password, and if found replaces the “administration password” option with an “enable administration” checkbox.
This is neat, although leaves no user friendly way to replace forgotten passwords.
* Always demand a screen lock password (if none is persisted). Replace the admin password with a checkbox. Add options to replace persisted passwords.
Good for security, follows the Tails threat model
It is an extra hurdle for users. Though users are often used to entering passwords when setting things up.
Means we could retire the non-standard screen lock password stuff and replace it with regular gnome.
* Use the encryption password as the screen lock / admin password. Replace the admin password with a checkbox for persistence users.
Not ideal for security
Convenient

My thinking was to go with the first option initially and see how things pan out. A lot rests on how we encourage users to set screen lock passwords. Though the more I think about it the more I’m leaning towards always demanding a lock password.

#12 Updated by sajolida 2018-07-05 18:24:50

> Without redesigning Linux passwords / sudo significantly it’s only possible to have one password!

I don’t understand this sentence. Can you rephrase maybe?

> Personally I think it’s important to have a screen lock option, even if users don’t like it. There’s plenty of other things tails / tor does to save users from themselves, this should be on that list.

The thing is that Tails already has a screen locker. This ticket is only
about making it possible to save it to persistence.

Users can already use the same screen locker password every time they
lock their screen.

So the only benefit of making the screen locker password persistent is
to have to screen locker enabled automatically when people start Tails.
I see two scenarios where this makes a difference:

• People leaving their computer unattended (going to the toilets at the
  library). It’s still much safer for them to lock the screen manually
  than to rely on an automatic screen locker and I would expect most Tails
  users to already have this habit.

• People closing their laptop and putting it in their bag (I do this a
  lot). Not having the screen locker enabled automatically might make a
  big difference in case they are searched, their loose their laptop or
  leave their bad unattended.

If we agree on this, then let’s keep in mind that we’re talking about
this particular scenario as a benefit when discussing the costs in terms
of UX, which might affect all other scenarios.

> * When an administrative password is set any persisted password is ignored.
> This is slightly surprising, but only affects uses who use the admin option (which should be used rarely).
> Simple to implement
> * When the admin password is set the persisted password is replaced.
> The danger here is the users may not know this has happened

So what about asking the user what they want to do?

We could check whether the administration password that was entered is
the same as the persisted password:

• If the passwords are the same, don’t ask anything and start Tails.
• If the passwords are different, ask the user what to do:

1. Ignore the persisted password = Use the administration password for
   administration and unlocking the screen. If people always set an
   administration password (like I do), they will quickly get bothered by
   this message but can disable the persisted password.

1. Replace the persisted password with the new administration password.
   That would also serve as a recovery mechanism for the persisted
   password in a way…

What do you think?

> * When you unlock the greeter it loads and persisted password, and if found replaces the “administration password” option with an “enable administration” checkbox.
> This is neat, although leaves no user friendly way to replace forgotten passwords.

I think that this option would require more evolved changes in Tails
Greeter, like inspecting the content of the partition as soon as it
opens, adjusting to the persistence being unlocked either before or
after the administration password is set, etc.

> * Always demand a screen lock password (if none is persisted). Replace the admin password with a checkbox. Add options to replace persisted passwords.
> Good for security, follows the Tails threat model
> It is an extra hurdle for users. Though users are often used to entering passwords when setting things up.
> Means we could retire the non-standard screen lock password stuff and replace it with regular gnome.

I really want to avoid doing this. Thankfully I think that we have
better options to consider. If it was the only option, I would probably
reject this proposal.

> * Use the encryption password as the screen lock / admin password. Replace the admin password with a checkbox for persistence users.
> Not ideal for security
> Convenient

I also thought about having “one password to rule them all”. But I’m
afraid this would require even more discussion and even more work than
the first options we have, so let’s keep this for later…

> My thinking was to go with the first option initially and see how things pan out. A lot rests on how we encourage users to set screen lock passwords. Though the more I think about it the more I’m leaning towards always demanding a lock password.

Not me :)

#15 Updated by segfault 2018-07-06 06:58:32

sajolida wrote:
> > * When an administrative password is set any persisted password is ignored.
> > This is slightly surprising, but only affects uses who use the admin option (which should be used rarely).
> > Simple to implement
> > * When the admin password is set the persisted password is replaced.
> > The danger here is the users may not know this has happened
>
> So what about asking the user what they want to do?
>
> We could check whether the administration password that was entered is
> the same as the persisted password:
>
> * If the passwords are the same, don’t ask anything and start Tails.
> * If the passwords are different, ask the user what to do:
>
> # Ignore the persisted password = Use the administration password for
> administration and unlocking the screen. If people always set an
> administration password (like I do), they will quickly get bothered by
> this message but can disable the persisted password.
>
> # Replace the persisted password with the new administration password.
> That would also serve as a recovery mechanism for the persisted
> password in a way…

I like to give the choice to the user, but instead of asking after they entered a password I would prefer giving them the following choices in the greeter, if there is already a persisted password:

1. Enable administration access (enables sudo with the persisted password)
2. Reset password (changes the persisted password, in case the user forgot it)

If there is no persisted password yet, the option would look like it currently does (Set password). But I think in that case the password should also be persisted, if that was enabled in the persistence settings. So the next time the user boots, it would be the two choices from above.

In this design, we should use the same name for the password in both the greeter and the screen locker dialog (because it would be the same password), for example user password.

What do you think?

#17 Updated by sajolida 2018-07-19 17:44:36

Answering to Gaff:

> * People who fall asleep while using their laptop (admit it - we’ve all done this! ;)).
Indeed :)

>> So what about asking the user what they want to do?
>>
>> We could check whether the administration password that was entered is
>> the same as the persisted password:
>>
>> * If the passwords are the same, don’t ask anything and start Tails.
>> * If the passwords are different, ask the user what to do: […]
>>
>> What do you think?
>
> We could, but it’s a bunch of UX work for an edge case.

With the introduction of the “Additional Software” feature in Tails 3.9,
hopefully many more people will set an administration password (at least
some of the times), people who are otherwise not used to Linux and doing
stuff as root, and this might not be an edge case anymore.

> And as you point out it means the tails greeter would need to load persistent settings.

The problem that I was pointing out with Tails Greeter inspecting the
content of the persistence is about doing this while the main window of
the Greeter is displayed.

When you start Tails, the persistence is locked and Tails Greeter
doesn’t know whether there’s a persistent password. It could only know
this after you unlock your persistence. Then Tails Greeter would have to
adjust its UI accordingly.

I don’t think this is much of a technical problem but it would be more
complicated for the user. For example, the interface for the
administration password is hidden by default and might change invisibly
depending on whether the persistence is unlocked already or not. The
user might set an administration password before unlocking the
persistence, etc. The user might click “Start Tails” without clicking
“Unlock” and benefit from the automatic unlocking of the persistence by
then (that’s what I do all the time). It’s add much more complexity to
the UX problem…

In my solution, I’m proposing to inspect the content of the persistence
only after the user clicks “Start Tails”. By then we can know for sure
whether there’s a persistent password or not.

> It’s not that surprising that the admin password trumps the persisted password, and the user will have recently typed it in anyway - so I don’t think it’s worth the effort.

We are not the user and we don’t know how surprising it is:

https://www.nngroup.com/articles/false-consensus/

> I agree that this would be controversial. However thinking about it more - it might be better to use the persistence password than no password at all!

Agreed. But let’s keep this controversial proposal in mind for a
unspecified point in the future :)

>>> * Always demand a screen lock password (if none is persisted). Replace the admin password with a checkbox. Add options to replace persisted passwords.
>>> Good for security, follows the Tails threat model
>>> It is an extra hurdle for users. Though users are often used to entering passwords when setting things up.
>>> Means we could retire the non-standard screen lock password stuff and replace it with regular gnome.
>>
>> I really want to avoid doing this. Thankfully I think that we have
>> better options to consider. If it was the only option, I would probably
>> reject this proposal.
>
> Can you explain why?

Right now (and unfortunately), it seems like most people using Tails
don’t use it with persistence. I don’t want to add a question that
people without persistence would have to answer every time.

Especially since we already have a nice design to ask for a screen
locking password when people do that for the first time.

#18 Updated by sajolida 2018-07-19 17:53:14

> I like to give the choice to the user, but instead of asking after they entered a password I would prefer giving them the following choices in the greeter, if there is already a persisted password:

• As explained in my previous note, the thing is that you might not know
  whether there is a persistent password or not until the user clicks on
  “Start Tails”. How would you handle the user not unlocking the
  persistence until they click on “Start Tails”? Or are you thinking about
  saving the persistent password outside of persistence?

• Can you explain why you would prefer this in terms of benefits for the
  user?

I’ll comment on the rest of your proposal after I understand this better…

#20 Updated by segfault 2018-07-19 18:51:25

sajolida wrote:
> > I like to give the choice to the user, but instead of asking after they entered a password I would prefer giving them the following choices in the greeter, if there is already a persisted password:
>
> * As explained in my previous note, the thing is that you might not know
> whether there is a persistent password or not until the user clicks on
> “Start Tails”. How would you handle the user not unlocking the
> persistence until they click on “Start Tails”?

Ah, I didn’t think about that.

> * Can you explain why you would prefer this in terms of benefits for the
> user?

• It’s less surprising
• It makes it clear to the user what the password they enter will be used for before they enter it
• They can learn about the password reset feature via the UI, and not only by accidentally stumbling upon it when they enter a different password than the persisted one
• It doesn’t use two different names for the same thing: there would only be a “persisted password”, no administration password

#24 Updated by segfault 2018-07-29 11:56:37

> We could make it a multi-step dialog, adding an “Additional Settings” button left to the “Start Tails” button, which unlocks the persistence partition if a password was set, and then displays the additional settings in the main window.

I think something similar will also be needed when we store the locale settings on the persistent partition (that’s what Feature #5501 is about, IIUC).

#25 Updated by intrigeri 2018-07-29 12:39:20

> I think something similar will also be needed when we store the locale settings on the persistent partition (that’s what Feature #5501 is about, IIUC).

Feature #5501 is explicitly about saving these settings “in the Tails system cleartext partition”, not on the encrypted persistent one.

#26 Updated by segfault 2018-07-29 13:09:43

intrigeri wrote:
> > I think something similar will also be needed when we store the locale settings on the persistent partition (that’s what Feature #5501 is about, IIUC).
>
> Feature #5501 is explicitly about saving these settings “in the Tails system cleartext partition”, not on the encrypted persistent one.

Ah, I see. Well, if that’s the plan, we can also consider whether we want to store the hashed password on the system partition. My point is that what we want here is basically to persistently store a setting that can be configured by the greeter, which we also want to support for other settings (locale).

#28 Updated by Gaff 2018-08-03 13:48:57

Just to add my 2 cents to this:

• I can’t see any sane way to store password data outside of persistence.
• Having the greeter load stuff once it has been unlocked (such as locale info, persisted screen lock passwords, …) is a little tricky but not impossible.

Also a data-point: Android has full disk encryption and is used by millions. The design there is that the persistence-password is also the screen-lock-password. Simple. Perhaps tails should follow Android? I must confess I’m worried about the risk of people shoulder-surfing the persistence password in this scenario.

Another suggestion: How about making the last 3 characters of the persistence password the screen-lock password? It’s a system used bye KeyPassX and others. It’s simple to understand and setup. If you buy into this then here’s what the flow would look like:

> 1. User unlocks persistence
> 2. Greeter code sets the account password to the last 3 characters.
> 3. Admin password is replaced with Admin checkbox (aka enable sudo).
> 3a - Need to indicate to users that the sudo password is the last 3 characters of their persistence password
> 4. Lock screen prompt says “please enter the last 3 characters of your persistence password”

This is pretty simple to implement across the board. WDYT?

#29 Updated by Gaff 2018-08-03 14:30:05

Alternatively:

> 1. User unlocks persistence
> 2. Greeter code sets the account password to the last 3 characters.
> 3. Leave the Admin as it is, if the user specifies an admin password it will override the last-3-characters password
> 4. Lock screen prompt says “please enter the last 3 characters of your persistence password”

This is really simple to implement - probably a handful of lines of code! :p

#30 Updated by sajolida 2018-08-11 09:03:13

> Also a data-point: Android has full disk encryption and is used by millions. The design there is that the persistence-password is also the screen-lock-password. Simple. Perhaps tails should follow Android?

Good point :)

> I must confess I’m worried about the risk of people shoulder-surfing the persistence password in this scenario.

Yeap. The persistence password is meant to be typed only once and you
can take extra precautions when typing it. While the screen locking
password is meant to be typed several times and might be harder to
protect from shoulder-surfing, cameras, etc.

I personally use a different screen locking password when I’m at
conferences or in public places because of that.

> Another suggestion: How about making the last 3 characters of the persistence password the screen-lock password? It’s a system used bye KeyPassX and others. It’s simple to understand and setup. If you buy into this then here’s what the flow would look like:

As I proposed in Bug #15641#note-17, let’s stick to having different
passwords for persistence and screen locking for the time as this might
be a very controversial topic. I’d rather see implemented what we
already agreed upon on this ticket first.

#34 Updated by sajolida 2019-07-24 18:01:01

@segfault:

> I don’t want to spend time on any of those two options. I still don’t think that the design summarized in the description of this ticket will bring a good UX, for the reasons I listed in Bug #15641#note-20.

I keep thinking that this particular ticket is low prio so I’m fine with
disagreeing on the best design for it and move on to other tickets that
you find more exciting. I haven’t actually dived into the whole
discussion because it’s very old and I remember it being painful.

> Regarding Feature #5501, I don’t see why we should try to persistently store settings outside of the persistent partition.

Feature #5501 includes persisting the keyboard layout. Users with a non-English
keyboard might have to change the layout before they can unlock their
Persistence, otherwise they might not know how to type their passphrase
with an English keyboard.

That’s why thought about persisting the keyboard layout outside of the
Persistence. But I haven’t read Feature #5501 entirely again so I might miss
some details.

> having to reconfigure the same settings on each boot, is one of the remaining major UX issues of Tails, which I would like fix at some point.

I agree. If we also agree that ideally the majority of our users would
be non-US, then Feature #5501 should be our top priority in term of persistence
preset.

We didn’t include it in the selection that we made in Feature #14544#note-75
because we expected a higher cost than other tasks, but it’s also really
important.