On 4 Aug 2024 17:44 +0100, from recoverymail123890@gmail.com (Mick Ab):

I have a Debian Bullseye desktop PC.

I am looking for a 2fa authenticator that works on my desktop, without
using a smartphone or tablet.

Most modern password managers that can run under Linux meet those
criteria. KeepassXC is one example which has a corresponding add-on to
Firefox. (I don't know about Chrome.)

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 04, 2024 at 05:44:07PM +0100, Mick Ab wrote:

I have a Debian Bullseye desktop PC.

I am looking for a 2fa authenticator that works on my desktop, without
using a smartphone or tablet.

I don't know what an "authenticator app" is. If what you need is TOTP,
oathtool (in the same-named Debian package) might be your friend.

What I do is, in a terminal:

echo "MY-TOTP-SECRET-KEY" | oathtool -b --totp - | xclip -r -selection clipboard

Xclip (from the same-named package) puts the result in some X selection
(here I use the clipboard, because the result is going to the browser,
and those are too stupid to handle other X selections gracefully).

Now of course this simplified schema doesn't take care of keeping your
TOTP secret secure and things, so you might want to use GPG for that.

Or, as others suggested, go with a password manager (if you ask me, not
the cloudy type -- those tend to leak [1] from time to time).

Cheers
[1] https://www.theverge.com/2023/2/28/23618353/lastpass-security-breach-disclosure-password-vault-encryption-update
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZq/A/AAKCRAFyCz1etHa RvDcAJoCRKa8Uv3dl2cSJ0AkrMjGunfiCACeLx2gLLvAxgUBUAXXAGrG1p+Q01k=
=kj8h
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 04, 2024 at 02:09:30PM -0400, Greg Wooledge wrote:

On Sun, Aug 04, 2024 at 19:57:22 +0200, tomas@tuxteam.de wrote:

I don't know what an "authenticator app" is.

I don't either, but I have to use one at work.

https://support.microsoft.com/en-us/account-billing/about-microsoft-authenticator-9783c865-0308-42fb-a519-8cf666fe0acc

I have no idea what it is, but it's installed on my work-issued phone,
and I have to use it occasionally when I sign in to certain web apps
on my work-issued laptop.

On the days where the web app decides it hasn't talked to Microsoft Authenticator recently enough, I have to go get my phone, type the
passcode once to unlock it, click the Authenticator icon and type my
passcode a second time to launch the app, then type my passcode a
third time inside the app to validate that yes, I am the person trying
to open the web page. I think there's a two-digit number that I have to
type as well.

By the sound of it, it /might/ be a TOTP. At work we have two "applications", one is a webmail (*spit*), the other is -- uh -- a Gitlab. My approach
works with both. Just get this secret key from the "app" and do roughly
as I outlined. TOTP is sufficiently standardized that you might have a
fighting chance.

I cannot imagine how installing one of these things on your Linux PC
is going to help you. Either you're dealing with a workplace-enforced authentication setup, in which case you need to use whatever authenticator *they* chose... or you're trying to establish some sort of "two factor authentication" of your own, in which case, having both factors be
"I'm logged into my Linux account" kinda defeats the purpose.

I have come to the conclusion that 2FA is, mostly, snake oil.

It might protect you from a password leak (if the planets are aligned properly), but then they nudge you into storing your secret *and*
your password in a cloud based password manager. Duh.

My hunch is that surveillance capitalism has smelled blood again.
The next Big Thing will be identity management in the Internet.
You can already hear the feet shuffling to get a pole position.

Cheers
--
tomás

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZq/G4gAKCRAFyCz1etHa RlD8AJ9HFbPtHwIPokTmP4VDWDZ56+0K2wCeLCimz4hyTinxw/02RBzQu+G1reg=
=LznM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 04, 2024 at 19:57:22 +0200, tomas@tuxteam.de wrote:

I don't know what an "authenticator app" is.

I don't either, but I have to use one at work.

https://support.microsoft.com/en-us/account-billing/about-microsoft-authenticator-9783c865-0308-42fb-a519-8cf666fe0acc

I have no idea what it is, but it's installed on my work-issued phone,
and I have to use it occasionally when I sign in to certain web apps
on my work-issued laptop.

On the days where the web app decides it hasn't talked to Microsoft Authenticator recently enough, I have to go get my phone, type the
passcode once to unlock it, click the Authenticator icon and type my
passcode a second time to launch the app, then type my passcode a
third time inside the app to validate that yes, I am the person trying
to open the web page. I think there's a two-digit number that I have to
type as well.

I cannot imagine how installing one of these things on your Linux PC
is going to help you. Either you're dealing with a workplace-enforced authentication setup, in which case you need to use whatever authenticator *they* chose... or you're trying to establish some sort of "two factor authentication" of your own, in which case, having both factors be
"I'm logged into my Linux account" kinda defeats the purpose.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/4/24 19:57, tomas@tuxteam.de wrote:

On Sun, Aug 04, 2024 at 05:44:07PM +0100, Mick Ab wrote:

I have a Debian Bullseye desktop PC.

I am looking for a 2fa authenticator that works on my desktop, without
using a smartphone or tablet.

I don't know what an "authenticator app" is. If what you need is TOTP, oathtool (in the same-named Debian package) might be your friend.

What I do is, in a terminal:

echo "MY-TOTP-SECRET-KEY" | oathtool -b --totp - | xclip -r -selection clipboard

I also use oathtool, but with an encrypted key:

gpg --decrypt --quiet key.asc | oathtool -b --totp -

Xclip (from the same-named package) puts the result in some X selection
(here I use the clipboard, because the result is going to the browser,
and those are too stupid to handle other X selections gracefully).

Copy via double-click and paste via single click works fine
here (for Firefox and Chromium) in X via SSH (the browsers
run inside an LXC container).

Detlef

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

OT question, can debian desktop run a simulator for phone app?

Thanks


On 2024-08-05 04:58, didier gaumet wrote:

Le 04/08/2024 à 22:16, Mick Ab a écrit :

I realise that Authy is still available on smartphones and tablets,
but I do not want to use a smartphone or a tablet.

I simply need to run a simple 2FA TOTP authenticator on my Debian
desktop PC.

Hello,

I do not use such applications but a search on the totp word in Debian packages lists numerous answers. From what I understand, at least these Debian packages could perhaps suit your needs:
- numberstation (GUI)
- nitrokey-authenticator (GUI)
- otpclient (GUI)
- otpclient-cli (CLI)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 05-08-2024 at 07:31 Wesley wrote:

OT question, can debian desktop run a simulator for phone app?

Not so off topic.

I once ran an Android simulator that required a google account, on my laptop in a KVM VM, as a test for running a program that could only be run on an Android Mobile phone.

The concept worked but only because my laptop had a AMD graphics, required by the VM graphics. It did not work on Nvidia cards (but as the saying goes, "that was then, but this is now", things in IT sometimes change).

I expect an authenticator would run in that Android simulator.

I did this recently for a friend, but once the need no longer existed, it seems I deleted the VM.

Hopefully there is a simpler way to run an authenticator.

George.

Thanks

On 2024-08-05 04:58, didier gaumet wrote:

Le 04/08/2024 à 22:16, Mick Ab a écrit :

I realise that Authy is still available on smartphones and tablets,
but I do not want to use a smartphone or a tablet.

I simply need to run a simple 2FA TOTP authenticator on my Debian
desktop PC.

Hello,

I do not use such applications but a search on the totp word in Debian packages lists numerous answers. From what I understand, at least these Debian packages could perhaps suit your needs:
- numberstation (GUI)
- nitrokey-authenticator (GUI)
- otpclient (GUI)
- otpclient-cli (CLI)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 05-08-2024 at 06:16 Mick Ab wrote:

I realise that Authy is still available on smartphones and tablets,

but I

do not want to use a smartphone or a tablet.

I simply need to run a simple 2FA TOTP authenticator on my Debian

desktop

PC.

Having had to use Authenticators myself, I understand.

I wonder for which company runs the default authenticator from the
system you are using, is it Microsoft or Google?


 You do not need to answer this (for security reasons), but I am
curious, as I wanted to know which Authenticators might work for you
and which would not.

I had thought that if it was, say, Microsoft, then only Microsoft Authenticators would work, as I expected these devices to be very
proprietary since they are supposed to be for supporting security. But
that does not seem to be the case, there are many alternatives for
Office 365.

Even Google Authenticator can be used for Microsoft 365.

However I fond that Microsoft 365 has many alternatives to Microsoft Authenticator.

https://www.capterra.com/p/219694/Microsoft-Authenticator/alternatives/

https://ctinc.com/google-authenticator/


What I do not know at this time, is there 2FA industry wide standard?
Or is it that everyone has their own standard and way to provide 2FA
codes?


 I noticed that biometric 2FA is now being implement.



https://softwaredevelopers.ato.gov.au/RequirementsforDSPs


https://authy.com/what-is-2fa/


https://www.imperva.com/learn/application-security/2fa-two-factor-authentication/




George.

<html>
<head>
<style type="text/css">
body,p,td,div,span{
font-size:13px; font-family:Arial, Helvetica, sans-serif;
};
body p{
margin:0px;
}
</style>
</head>
<body>On Monday, 05-08-2024 at 06:16 Mick Ab wrote:<br>
&gt; I realise that Authy is still available on smartphones and tablets, but I<br>
&gt; do not want to use a smartphone or a tablet.<br>
&gt; <br>
&gt; I simply need to run a simple 2FA TOTP authenticator on my Debian desktop<br>
&gt; PC.<br>
&gt; <br>

Having had to use Authenticators myself, I understand. <br>
<br><div>
I wonder for which company runs the default authenticator from the system you are using, is it Microsoft or Google?</div><div><br></div><div>&nbsp;You do not need to answer this (for security reasons), but I am curious, as I wanted to know which
Authenticators might work for you and which would not.</div>

I had thought that if it was, say, Microsoft, then only Microsoft Authenticators would work, as I expected these devices to be very proprietary since they are supposed to be for supporting security. But that does not seem to be the case, there are many
alternatives for Office 365.<br>

Even Google Authenticator can be used for Microsoft 365.<br>

However I fond that Microsoft 365 has many alternatives to Microsoft Authenticator.<br>

<a href="https://www.capterra.com/p/219694/Microsoft-Authenticator/alternatives" target="_blank" class="normal-link">https://www.capterra.com/p/219694/Microsoft-Authenticator/alternatives</a>/<br>

<div><a href="https://ctinc.com/google-authenticator" target="_blank" class="normal-link">https://ctinc.com/google-authenticator</a>/</div><div><br></div><div>What I do not know at this time, is there 2FA industry wide standard? Or is it that everyone
has their own standard and way to provide 2FA codes?</div><div><br></div><div>&nbsp;I noticed that biometric 2FA is now being implement. <br></div><div><br></div><div>https://softwaredevelopers.ato.gov.au/RequirementsforDSPs</div><div><br></div><div>
https://authy.com/what-is-2fa/</div><div><br></div><div>https://www.imperva.com/learn/application-security/2fa-two-factor-authentication/</div><div><br></div><div><br></div><div>George.</div><div><br></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 04, 2024 at 09:16:15PM +0100, Mick Ab wrote:

I realise that Authy is still available on smartphones and tablets, but I
do not want to use a smartphone or a tablet.

I simply need to run a simple 2FA TOTP authenticator on my Debian desktop
PC.

For TOTP, at least two in this list use oathtool successfully. It does one thing, and does it well.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZrBVIgAKCRAFyCz1etHa RvyAAJ952JZMJeCyJIgY/0Um5NsPWJYJ4gCfXriDZWDDEYdf5rtHFljzNXg30qk=
=aZGm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 04, 2024 at 09:19:33PM +0200, Detlef Vollmann wrote:

[...]

I also use oathtool, but with an encrypted key:

gpg --decrypt --quiet key.asc | oathtool -b --totp -

Thanks for posting the "correct" way. Yes, this way your secret is
secure when "at rest".

Xclip (from the same-named package) puts the result in some X selection (here I use the clipboard, because the result is going to the browser,
and those are too stupid to handle other X selections gracefully).

Copy via double-click and paste via single click works fine
here (for Firefox and Chromium) in X via SSH (the browsers
run inside an LXC container).

The xclip part just saves me the clickery. I'm very keyboard-centric. So
I just give the browser the focus and CTRL-V (provided the @&%$* Javascript "application" gives the focus to the field whithin the browser).

I'm still missing some moving parts, then I plan to put that into a WM
hotkey.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZrBUbAAKCRAFyCz1etHa Rsv2AJ4iluBdVmepYQuyMCsqSNcRvEtKbwCfXrPgm1s0m2+Ol90fPLSEwY7KSd0=
=Cxg2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5 Aug 2024 05:31 +0800, from wesley@mxcloud.eu.org (Wesley):

OT question, can debian desktop run a simulator for phone app?

If OP thinks a password manager is "more complicated than needed",
then what isn't running a hardware emulator + whole operating system +
Who knows what?

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 4 Aug 2024, tomas@tuxteam.de wrote:

On Sun, Aug 04, 2024 at 05:44:07PM +0100, Mick Ab wrote:

I have a Debian Bullseye desktop PC.

I am looking for a 2fa authenticator that works on my desktop, without
using a smartphone or tablet.

I don't know what an "authenticator app" is. If what you need is TOTP, oathtool (in the same-named Debian package) might be your friend.

I use this too, and it gives the same numbers as FreeOTP which I have
installed on my phone.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

August 5, 2024 at 10:35 PM, "Tim Woodall" <debianuser@woodall.me.uk> wrote:

oathtool (in the same-named Debian package) might be your friend.

I use this too, and it gives the same numbers as FreeOTP which I have

installed on my phone.

Me second with oathtool which just works for me.

regards.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Aug 05, 2024 at 10:22:35PM +0000, Corey Hickman wrote:

August 5, 2024 at 10:35 PM, "Tim Woodall" <debianuser@woodall.me.uk> wrote:

oathtool (in the same-named Debian package) might be your friend.

I use this too, and it gives the same numbers as FreeOTP which I have

installed on my phone.

Me second with oathtool which just works for me.

TOTP is a standard (rfc6238 [1]) so it actually /should/ give the same
numbers regardless of the application.

(This is what miffs me most: those marketing departments always sell you
some unspecified snake oil -- "authenticator app", "2FA" -- instead of
telling you what's technically behind it. On the surface, it's to not
confuse the poor stupid user with too much technical mumbo jumbo. The real intention is to keep the user poor and stupid, and thus, dependent).

Cheers

[1] https://datatracker.ietf.org/doc/html/rfc6238
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZrGojgAKCRAFyCz1etHa RihTAJ0V8rjUcDwMLPSUFNLoTfCiWj6g5wCeKLtrTMncodw+OWPUy1VCurmZVmM=
=b9rV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Mick, dear all:

Am 05.08.24 um 09:06 schrieb Michael Kjörling:

On 5 Aug 2024 05:31 +0800, from wesley@mxcloud.eu.org (Wesley):

OT question, can debian desktop run a simulator for phone app?

Absolutely yes. But that's not going to help anyone in this thread.

If OP thinks a password manager is "more complicated than needed",
then what isn't running a hardware emulator + whole operating system +
Who knows what?

I suspect that some contributors to this thread might have gotten Micks original question wrong, which is about 2FA, to require a passphrase
_and_ a one-time (TOTP) token. And that you, dear Mick, might have
gotten the purpose of 2FA wrong. No offense intended. Let's all take a
step back, and take a broader look. So please bear with me and read me
out. I'm up for any challenge to be proven wrong. (because presumably I am)

2FA is intended to raise the bar of stealing your login from just one
leaked known secret (username/passphrase) to two _strictly_ separate
bars. The latter must not be yet another secret, but might be physical
custody of some given device. In that way, a merely leaked passphrase
won't give immediate access to your login, neither would that device, if
only that was stolen.

Still those two factors ought to be secure each by themselves.
Passphrases are supposed to be un-guessable even by brute-force, so they
better be very complex; also they're not supposed to be re-used for
multiple accounts. For that very reason, passphrase "managers" (vaults)
exist. They must be strongly encrypted, and local only. But for
reasonable security, they don't suffice. Why not?

Their weak points are: Blackhats might either:
1. intercept your passphrase while authenticating, or
2. steal them from your passphrase-encrypted vault, if your local
account or machine has been compromised, or
3. steal them from where you're authenticating against, if stored there insecurely.

For 3., that should be salted strong hash algorithms. More often than
not, that's not the case. You can never know. All three of the above
shouldn't happen, but all of them have happened, do happen, and will
continue to happen. Take your guess where all the passphrase lists on
the darknet are coming from. Some might be MD5 or SHA1 hashed, both of
which are weak, or the salt might be poorly chosen. Unless you know for certain, assume each of your passphrases to be potentially compromised,
or compromisable.

That's where 2FA kicks in: Your passphrase alone, which might've been compromised, won't unlock your authentication, but requires you to possess/provide an independent factor, that would ideally not be
compromised simultaneously with your passphrase or with your local
account. That might well be a cellphone receiving a text message, or an
app that performs TOTP. (both of which is not inherently secure, but
much better than nothing) Or maybe, much better, a hardware token.

If I understand you correctly, Mick, you're considering to move your
TOTP factor out of an independent device towards your local debian
machine for convenience, so you'd be giving away the second
authentication factor to anyone who's compromised your local account,
that you were defending against in the first place. Please tell me
you're not shooting yourself in the foot.

It's your choice, Mick. Debian includes several programs that do TOTP.
But for 2FA to have any meaningful effect, the factors need to be
independent, or else you might as well ditch 2FA altogether.

Are you seeking security, or are you seeking convenience? Both maybe?
Then keep your credentials separate. Feel free to use your debian
machine as an encrypted passphrase vault, and make another separate
device your 2nd factor. Or vice-versa. Just know what you are doing.

Now on my own behalf, thanks to anyone for reading this far and for
trying to understand my point. I'd love to see any flaws in my argument
being challenged. Your security decisions are inherently yours. I'm not
a lawyer. Keep your security up, and take care. Despite that I'm German:
Keep smiling. :) I'll smile back (:
Even we do cheer sometimes, if necessary ;)

Have a nice day
--
Kevin Price

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 06, 2024 at 07:10:38AM +0200, Kevin Price wrote:

Dear Mick, dear all:

[...]

So far, agreed.

If I understand you correctly, Mick, you're considering to move your
TOTP factor out of an independent device towards your local debian
machine for convenience, so you'd be giving away the second
authentication factor to anyone who's compromised your local account,
that you were defending against in the first place. Please tell me
you're not shooting yourself in the foot.

This is misleading. Still it will protect you from password leaking
(e.g. by a website impersonating the server you want to authenticate
against, or by a stupid service keeping your clear text password).

It's your choice, Mick. Debian includes several programs that do TOTP.
But for 2FA to have any meaningful effect, the factors need to be independent, or else you might as well ditch 2FA altogether.

...and here's the false conclusion.

Of course, if your manage your secrets, you should know what you are
trying to achieve (the "threat model").

If you want to be safe "at rest", encrypting your disk will be enough;
if you encrypt your OTP key, it's one layer more (i.e. while your particular application is "at rest").

If the threat is that your application is taken over while it's running, well... no "2FA" will protect you from that. The attacker will just surf
on your application's coattails after *you* have done the auth thing.

I would even argue to leave the smartphone out of the loop: in times
of Pegasus [1] et al, it's a security nightmare, anyway.

(A secure token is another thing: for myself I've decided it's not
worth the hassle, but it does offer a layer more. I wouldn't rely
on one which is not documented -- even better: strongly prefer open
hardware).

What finally gets me is when your bank urges (forces) you to do 2FA
with your smartphone, but then is fine with you doing your banking
with a browser *on the same phone*. That's what Bruce Schneier calls
"security theater".

cheers

[1] https://en.wikipedia.org/wiki/Pegasus_(spyware)
--
tomás

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZrHEAwAKCRAFyCz1etHa Rr7IAJwKrJvEBoBQmrMmJ+51txyVQKM+VACeNG7jLXq7ObvCmWuLIvTsqptZDZQ=
=qC7O
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 06, 2024 at 11:07:14PM +0700, Max Nikulin wrote:

On 06/08/2024 11:37, tomas@tuxteam.de wrote:

TOTP is a standard (rfc6238 [1]) so it actually/should/ give the same numbers regardless of the application.

(This is what miffs me most: those marketing departments always sell you some unspecified snake oil -- "authenticator app", "2FA" -- instead of telling you what's technically behind it.

It is mostly true, however authenticator applications may use
vendor-specific protocols that relies on network connection instead of displaying TimeOTP code to confirm login. The worst case is when TOTP is disabled for specific service and alternative applications can not be used.

I just today set up one more: it /was/ TOTP, after all. The instructions,
of course didn't say so, but talked a lot about scanning the QR code with
your smartphone (there is the TOTP key beneath this ready for c&p, but no mention of it).

That's what I call nudging.

While passwords are salted and hashed to make it harder to steal them from servers,

...but of course they must be stored in plain text in your password "vault". (OK, technically they may be encrypted, but usually the "vault" has a key)

the same approach is not applicable for TimeOTP. The same secret
must be available on client and server to derive a code valid for the
current (half of) minute.

I am not recommending against TOTP. Just be aware that enabling and using it may require more efforts than for application specific to particular vendor.

Nor am I. It is a specific tool for a specific job -- my point is, that most
of the time it's being pushed without really understanding what it affords.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZrJRSwAKCRAFyCz1etHa RuDDAJ44ehT1tSK+UScampyma0+3nplDeACfY5VA1YlvKJIahMBauCkcCRjuA3s=
=d+bM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 07, 2024 at 10:11:08AM +0700, Max Nikulin wrote:

Hi, Max,

Thanks for your quite extensive (and, as always, insightful) reply.

Most of the points have been touched on in this long thread. The
insecurity of the X protocol, etc.

In my threat model, if I already have an application running under
my own user ID, I call XKCD 1200 [1] on it. Any mitigation helps,
of course, but I have to assume the worst has happened.

[...]

But for me, you expressed the core concern beautifully:

Educating people is quite expensive.

...that's what I'm about: I, as "people", don't want to be treated
as a disposable resource. I don't want any of my colleagues, customers, providers, visitors, users... treated as a disposable resource.

Call me weird for that :-)

Cheers

[1] https://xkcd.com/1200/
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZrL6twAKCRAFyCz1etHa RuGLAJ9JJnhg8qtZhvpp7FCqi8v2mo885wCfbS+B1Pl+EUJBY6d0bElbc4SRGzg=
=+nVK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7 Aug 2024 10:11 +0700, from manikulin@gmail.com (Max Nikulin):

https://lists.debian.org/msgid-search/ZrBUdBR0nUozNwW6@tuxteam.de
On 05/08/2024 11:26, tomas@tuxteam.de wrote:

On Sun, Aug 04, 2024 at 09:19:33PM +0200, Detlef Vollmann wrote:

gpg --decrypt --quiet key.asc | oathtool -b --totp -

[...]

The xclip part just saves me the clickery.

Ideally clipboard should be avoided to avoid exposure codes to sniffers.
Some kind of input method might be better. X11 XTest extension allows to
send key events to applications (see xdotool and xvkbd), but it is
considered as an insecure feature per se and may be disabled.

Anything running on X11 can monitor events from anything. So if
something can monitor the clipboard, it can also monitor keystrokes.
This is a six of one, half a dozen of the other situation.

X11 is many things, but it's decidedly not an isolated environment for
running untrusted code.

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Aug 08, 2024 at 09:21:45AM +0700, Max Nikulin wrote:

On 07/08/2024 11:40, tomas@tuxteam.de wrote:

In my threat model, if I already have an application running under
my own user ID, I call XKCD 1200 [1] on it.

Browser JavaScript API allows to read and write clipboard. It is protected
to some extent by user prompts. On the other hand in ChromeOS most of applications are running in browser, so I will not be surprised if policy becomes more permissive some day despite developers are aware of related security issues.

I'm aware of the browser expansivity (it wants ever more and more).

Currently I protect against that by having very restricted profiles:
my "default" browser can't even Javascript.

This forces me to think, when I see a page which can't render: "do
I really need it?". The answer is often "nah".

For each specific application which needs it, I have a specific browser profile.

This is not enough, mind you: some of those specific applications could
turn malicious at any time (given the "npm deployment model" even without
the application maker's knowledge).

Are you sure that you have never accidentally granted clipboard read permission to some frequently used web site?

I know, I know. Sometimes I dream of running browsers in their VMs
(with their own X server). But that would be over my budget :-)

So a threat may be outside of "traditional" local processes.

As to X11 protocol, it allows to grab focus, e.g. xterm supports it. Several years ago GNOME designers decided that their password prompt must be full screen modal dialogue that does not allow even mouse interaction with other applications (e.g. 3rd party password managers). On the other hand it does not protect against xinput debug tools running at lower level.

Definitely. That's one reason I left GNOME behind. It's definitely a
tradeoff at this point: the X model provides the concept of a "window
manager", and the window manager is *my* ally. The trend is that the application is the boss (client-side decorations anyone?), and the
application is the ad's industry's ally. Now I do prefer the first one,
even if old and creaky :-)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZrRMrQAKCRAFyCz1etHa Ri4eAJ4t3J2CEgkB/o3zU8A8VPL4W/2u6gCfeRKbET5nIpNJ3uZx8FYlu+Fpg9w=
=WkIy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)