Xfce Forum

Jajamszeu

Member

Registered: 2022-07-15

Posts: 4

Password input timeout (question) - I assume design choice?

On a few occasion privilege escalation is needed, Xfce (gnome) present a nice GUI password input box, with even some info regarding software in question. And I don't know if this was always like this or is it new development, but the box expire around 20 seconds after it is displayed. There doesn't seem to be any information available on how to fix it on the internet - found some old guide, but it was clearly out of date (not to mention featured adding obscure pieces of code to system scripts with no explanation how they relate to the problem). At a same time I found no clue on why it would be so strict, as there do not seem to be a single piece of software so restrictive in such regard, and second best sit on multiples of that time allowance.

So my first question would be:
- Is there a reasonable way, like configuration option to change that timeout value?
- Why would that even be a thing? What kind of security benefits are gained by this restriction considering negative effect on long and complex passwords, which take long time to input, even longer one to correct (since you do not see it) and due to other (more standard/reasonable) restrictions cannot be submitted incorrectly more than few times without locking account used for authorization?

Last edited by Jajamszeu (2022-07-15 17:17:10)

---

Signature letters look back at you as you check it up.
[you] take [1] point of [emotional] damage!
1) Cry.  2) Run.  3) Reload.  4) Get back to work - you have that presentation tomorrow...
>

KBar

Member

Registered: 2021-11-05

Posts: 689

Re: Password input timeout (question) - I assume design choice?

Hello and welcome!

On a few occasion privilege escalation is needed, Xfce (gnome) present a nice GUI password input box, with even some info regarding software in question. And I don't know if this was always like this or is it new development, but the box expire around 20 seconds after it is displayed.

I haven't lived long enough to tell whether this has always been the case, but it's been the default behavior since I've started using Linux, which was around 2016.

- Is there a reasonable way, like configuration option to change that timeout value?

It doesn't look like it.

- Why would that even be a thing? What kind of security benefits are gained by this restriction considering negative effect on long and complex passwords, which take long time to input, even longer one to correct (since you do not see it) and due to other (more standard/reasonable) restrictions cannot be submitted incorrectly more than few times without locking the account?

It only closes on inactivity. You can keep typing an arbitrary long password as long as you're not inactive for 30 seconds.

---

Remember to edit the subject of your topic to include the [SOLVED] tag once you're satisfied with the answers or have found a solution (in which case, don't forget to share it as well), so that other members of the community can quickly refer to it and save their time. Pretty please!

Jajamszeu

Member

Registered: 2022-07-15

Posts: 4

Re: Password input timeout (question) - I assume design choice?

@KBar

I recognize the window you mentioned here (the one that closes on inactivity) it is reasonable, even with shorter timeout window - box I'm talking about (looks like something build around password/key management) ignore any actions taking place. You have 20 something second and that's it, period. You don't submit inside that window, you don't submit it at all.

Which reminds me, another annoying quality of that access box is that in some cases application starts anyway, regardless of password input failure (fresh install by the way 4.16 - on minimalistic, secure host for VMs (few console tools, hypervisor, core hardware management nothing fancy)). I assume this is not a case of root/privileged access being occasionally granted just because someone spend more than 20 seconds on password input, but rather than application is being started without sufficient privileges, which seem like a quick way to data loss... and neither of those causes I like in realm of possibilities.

Ps. I'm writing here rather than distro forums, because Xfce (on X) is the only place I experienced this issue (actually will try to wait out gnome 3 one and see what happens).

Last edited by Jajamszeu (2022-07-15 19:18:40)

---

Signature letters look back at you as you check it up.
[you] take [1] point of [emotional] damage!
1) Cry.  2) Run.  3) Reload.  4) Get back to work - you have that presentation tomorrow...
>

KBar

Member

Registered: 2021-11-05

Posts: 689

Re: Password input timeout (question) - I assume design choice?

Can you provide a screenshot?

---

Remember to edit the subject of your topic to include the [SOLVED] tag once you're satisfied with the answers or have found a solution (in which case, don't forget to share it as well), so that other members of the community can quickly refer to it and save their time. Pretty please!

Jajamszeu

Member

Registered: 2022-07-15

Posts: 4

Re: Password input timeout (question) - I assume design choice?

Here are examples from network manager, password box and (not nice) expiration popup - however at this point password still can be provided regardless and it seem to authorize requested action:
https://imgur.com/2o9roVq
https://imgur.com/6mWyHmx

The following example is the problematic, this one (and if I recall properly some others) dissapear once ~24 seconds pass, and considering similar triggering circumstances I assume both issues are related:
https://imgur.com/kD60R1e

Just for comparison:
- sudo don't seem to have authorization issues (waits for more than few minutes)
- gnome3 don't seem to have authorization timeout issues (waits for more than few minutes)

---

Signature letters look back at you as you check it up.
[you] take [1] point of [emotional] damage!
1) Cry.  2) Run.  3) Reload.  4) Get back to work - you have that presentation tomorrow...
>

KBar

Member

Registered: 2021-11-05

Posts: 689

Re: Password input timeout (question) - I assume design choice?

Thanks.

I've got a feeling that it depends on whether a service is provided by systemd or not; those that are timeout in 25 seconds. I killed all instances of PolicyKit and ran

systemctl reload NetworkManager.service

No graphical dialog spawns since the agent daemon was killed. After 25 seconds of inactivity, the password prompt disappears. This means that it is not governed by PolicyKit. Grepping through the source code of systemd for error messages and strings like "timeout" and "25 seconds", the following can be discovered: https://www.freedesktop.org/software/sy … eout.html#

Indeed, setting and exporting the SYSTEMD_BUS_TIMEOUT environment variable affects the timeout of next spawned dialogs. However, 25 seconds seems to be the upper limit, as you can't really go above it. It's hard-coded and defined in src/libsystemd/sd-bus/bus-internal.h:326

#define BUS_DEFAULT_TIMEOUT ((usec_t) (25 * USEC_PER_SEC))

You may try changing this value and recompiling to see if the behavior changes.

---

Remember to edit the subject of your topic to include the [SOLVED] tag once you're satisfied with the answers or have found a solution (in which case, don't forget to share it as well), so that other members of the community can quickly refer to it and save their time. Pretty please!

Skaperen

Member

From: right by Jesus, our Saviour

Registered: 2013-06-15

Posts: 862

Re: Password input timeout (question) - I assume design choice?

driving up waiting password prompts is a type of denial-of-service attack method.  timing them out should be used.  also, typing the first character of the password should reset the timer, giving you another 25 seconds.  an eight character password typed in slowly could be done in a little over 3 minutes if they did this the right way.  if i were to implement it, i would not reset the timer for backspace and retype as that could be a variant of the attack.

Jajamszeu

Member

Registered: 2022-07-15

Posts: 4

Re: Password input timeout (question) - I assume design choice?

@KBar,
That is actually very educative answer. Thank you.

Didn't have much experience related to systemd beyond making a frowning face when it replaced init. Was actually hoping that window was some system security management component managing stuff rather than OS doing knee jerk caused by running something without privileges it requires (not sure if my understanding of the issue make much sense, GUI software development wise is relatively simple to understand and use, but the underlying OS side always seemed confusing/limiting). Your explanation will help a lot, but I will try to axe about a bit for some ugly but less inconvenient workaround, before trying that one. Thanks

driving up waiting password prompts is a type of denial-of-service attack method.  timing them out should be used.  also, typing the first character of the password should reset the timer, giving you another 25 seconds.  an eight character password typed in slowly could be done in a little over 3 minutes if they did this the right way.  if i were to implement it, i would not reset the timer for backspace and retype as that could be a variant of the attack.

That is not a way I would conceptualize it. It looks like an linguistic issue to me, caused by the way password input is often referred to or presented as something "waiting for password". The way I see it its a bubble machine, you throw in the "password" coins and it spit out "authorized" candies. Problems could exist, like too many candies given out at short amount of time can be a problem, but that is a capacity(load) issue and not authorization one. As for people sending incorrect passwords, they don't get anything and that's that. Whatever anty-ddos or anty-brutforce security solutions could be implemented with 'waiting' approach, can be implemented at candy machine one, plus some more, plus at lower cost. You gain nothing solving the problem of machine waiting for password as someone intensively works their keyboard for hours because no matter how many hours he spend on it that is not an entering of password, pressing enter is (coincidence?)

Last edited by Jajamszeu (2022-07-19 01:29:01)

---

Signature letters look back at you as you check it up.
[you] take [1] point of [emotional] damage!
1) Cry.  2) Run.  3) Reload.  4) Get back to work - you have that presentation tomorrow...
>