Add (a potentially much better) timestamp_timeout: with a shorter PIN

[eugenesvk]

sudo has this timestamp_timeout option that doesn't re-prompt you for a password within, say, 5 minutes of entering a password

It seems that please doesn't have this option yet, but also I'd like to propose another modification that could make this option even better — slightly less convenient, but more secure — by using the concept of PINs, so instead of not re-prompting you for the full password during this timestamp_timeout period, the please command should instead prompt you every time, but not for your full password, but for a secondary, shorter password (aka "PIN")
This way you don't have to risk some wrong copy&paste or something worse doing anything as root within the blessed period

I understand that with proper more granular permissions this might not be as important, but at the same time not everyone will bother with granularity #1, so this is still useful and and improvement over the total passwordlessness!

[edneville]

Hello Evgeny,

On 2022-12-24 08:22-0800, Evgeny wrote: `sudo` has this `timestamp_timeout` option that doesn't re-prompt you for a password within, say, 5 minutes of entering a password

So far, I've not implemented a customised timeout, thanks for reminding me, I'll look into customisable delays.

It seems that `please` doesn't have this option yet, but also I'd like to propose another modification that could make this option even better — slightly less convenient, but more secure — by using the concept of PINs, so instead of not re-prompting you for the full password during this `timestamp_timeout` period, the `please` command should instead prompt you every time, but not for your full password, but for a secondary, shorter password (aka "PIN") This way you don't have to risk some wrong copy&paste or something worse doing anything as root within the blessed period

I'm wondering, would a PIN be implemented differently from 'reason', <https://github.com/edneville/please#actions>, which needs to be matched, or at least supplied. This (-r ...) argument is provided when run, so wouldn't always prevent every copy&paste mistake. Some other examples of configuring a reason requirement: <https://github.com/edneville/please/blob/master/please.ini.md#reasons>

I understand that with proper more granular permissions this might not be as important, but at the same time not everyone will bother with granularity #1, so this is still useful and and improvement over the total passwordlessness!

Ideally access should be tailored to principle of least privilege, but some organisations will argue that some people should have full access, similar maybe to a "break-glass" account. Ed

[eugenesvk]

I'm wondering, would a PIN be implemented differently from 'reason'

These seem to be rather different in their goals and thus implementations, a couple of differences of the top of my head:

• PIN would be encrypted in a similar way the main password is instead of being stored as a plain text configuration rule (so its input should also be secure, not a -r cli flag saved to history)
• PIN would apply to all the commands requiring a password (until the timeout elapses) instead of having to be configured for each command in a config

Ideally access should be tailored to principle of least privilege, but some organisations will argue that some people should have full access, similar maybe to a "break-glass" account.

Sure thing, ideal is ideal ;)! But maybe PIN could help even in the case of lesser privileges, especially for repeatable commands that should rightfully require a proper challenge, but just maybe not every single time that challenge should be the full long password?
(though maybe some commands could opt out?)

[edneville]

On 2022-12-24 09:03-0800, Evgeny wrote: > I'm wondering, would a PIN be implemented differently from 'reason' These seem to be rather different in their goals and thus implementations, a couple of differences of the top of my head:

I do see the difference here, but if the goal was to molly guard, then it might have covered that.

- PIN would be encrypted in a similar way the main password is instead of being stored as a plain text configuration rule (so its input should also be secure, not a `-r` cli flag saved to history) - PIN would apply to all the commands requiring a password (until the timeout elapses) instead of having to be configured for each command in a config

Would the PIN be generated on first execution where a token doesn't exist, then stored within the token file perhaps (a different/new PIN per tty). This would need to be printed to the user, which might affect stdin/stdout.

Sure thing, ideal is ideal ;)! But maybe PIN could help even in the case of lesser privileges, especially for repeatable commands that should rightfully require a proper challenge, but just maybe not every single time that challenge should be the full long password? (though maybe some commands could opt out?)

Assuming a four-digit PIN, it wouldn't take much to brute-force, I wouldn't want' to treat it as a form of authentication. `-r` isn't considered protected information, it molly-guards, so if routine things could correlate to business tickets, there's a room to associate that. Or if you're about to poweroff a computer, you can require that the reason matches the hostname to protect the admin from mistakenly powering off the wrong machine, for example. This is where I have connected the copy&paste comment, if you want to avoid pasting 'rm -rf' or similar, routine things could perhaps have a fall through in the config, and everything else could require a reason. I know that isn't exactly what you're asking for. I'll keep this open whilst I think about the way to implement. Ed

[eugenesvk]

Would the PIN be generated on first execution where a token doesn't exist, then stored within the token file perhaps (a different/new PIN per tty). This would need to be printed to the user, which might affect stdin/stdout.

Hm, my idea was that the user generates the PIN, so it'd be a special please init pin command that asks for your main password, then asks with the same secure input for a new pin, then saves it to some system keychain or something, so nothing would need to be printed to the user.

Assuming a four-digit PIN

It doesn't have to be this trivial, PINs can also be alpha-numeric, so you can make it arbitrarily complex, the key thing is that it's much less complicated than the main system password

everything else could require a reason.

Here is another difference, I think, this -r approach complicates every single invokation of a command you have to keep in mind beforehand, while with a PIN you just get asked

• 🆔PIN or 🔏Password: instead of the regular
• 🔏Password: prompt
  (and you don't even have to think about PIN and type your password on auto pilot, but when you do ten commands that require it, it might be worth switching to something easier)

I know that isn't exactly what you're asking for. I'll keep this open whilst I think about the way to implement.

Thanks!

[edneville]

Related c617695, adding token_timeout