openssh unix dev - Aug 2022 - Looking for Special Challenge-Response Auth PAM Module, or Similar

Hello everyone, I hope that it is acceptable to post an only *halfway* 
relevant request to the OpenSSH mailinglist ...

These days, I was sent to do on-site maintenance on one of the Linux 
based appliances we make. The local admin led me to a rack and pointed 
to the KVM unit, with the screen showing the appliance's login prompt - 
no network access for my laptop, no physical access to the appliance 
(nowhere to be seen), please type your appliance's maintenance password 
into our hardware. Didn't much like that, and the surveillance camera a 
foot and a half above the keyboard didn't help any, either.

So now I'm looking for a new (additional), replay-attack-safe 
authentication method to add to the product. Searched the web for 
"challenge-response" and "PAM" (so that it'll also work
with sshd if
needed), and so far, everything remotely acceptable seems to go back to 
three basic principles:

-- Tokens like Yubikeys, which wouldn't have worked here thanks to no 
physical access.

-- HOTP, which would lack the *single* strictly-(de|in)creasing counter 
to be replay safe (snarf response used on a "well worn" appliance, 
replay it on one with a "younger" counter, unless we start shipping 
appliances with *individual* secrets to boot).

-- TOTP, which *would* be replay safe - if only our appliances weren't 
meant to sync against the customers' own NTP servers, so that their time 
can trivially be off or downright manipulated.

What I'm looking for is a solution where the appliance would prompt with 
a *randomly chosen* challenge, random enough to make it unfeasible to 
try and wait for the challenge to repeat, the technician types the 
challenge into some device of his own (laptop, if need be), types the 
response displayed back into the appliance, and hey, nice camera you 
have there making an *entirely useless* recording.

Would anyone here happen to know of such a beast?

Thanks in advance,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220823/decd4d31/attachment.p7s>

How about a cronjob that prints a new random text-qr on a virtual console every
minute or so, which can be scanned by your smartphone and is used to derive some
root password?


As a completely different idea, if the applicance has a camera or other input
(IR), you could run IP via QR or over an optical serial connection...

On 23/08/2022 14:15, Jochen Bern wrote:
> What I'm looking for is a solution where the appliance would prompt 
> with a *randomly chosen* challenge, random enough to make it 
> unfeasible to try and wait for the challenge to repeat, the technician 
> types the challenge into some device of his own (laptop, if need be), 
> types the response displayed back into the appliance, and hey, nice 
> camera you have there making an *entirely useless* recording.
>
> Would anyone here happen to know of such a beast? 
You mean something like SCRAM implemented as a PAM module?? I can't 
think of one off hand, but there's always pam_exec which is pretty easy 
to plug into.

It might be possible to use pam_sasl 
<http://www1.maths.leeds.ac.uk/~pmtvlm/pam-sasl.html> together with a 
SASL challenge-response auth method 
<https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html> 
like SCRAM.

You mentioned Yubikeys.? Depending on the flavour of key, they implement 
a range of different auth methods, some of which are suitable for 
keyboard use; that is, you don't need to plug them directly into the 
target system.

You've already ruled out Yubi OTP mode and HOTP mode, but there is also 
a HMAC-SHA1 type of challenge-response.? I found two modules: the 
official module 
<https://developers.yubico.com/yubico-pam/Authentication_Using_Challenge-Response.html>
and http://www.average.org/chal-resp-auth/. Both are stateful to avoid 
storing the secret in cleartext on the server, so may suffer from the 
same replay attacks you discussed - but I haven't investigated in 
detail.? It might be possible to use the same secret on all targets, but 
seed them with different challenges.

Aside: I did once play with a PAM module which allows manual U2F 
challenge/response over ssh keyboard-interactive authentication. What 
happened was, you'd connect via ssh and it would spit out a long 
challenge. You paste this into a local client app, and press the button 
on your U2F key.? The client spits out a long response, and you paste it 
back into the ssh session.??Bingo.

It did actually work - but unfortunately the strings were way too long 
to be practical over a KVM without copy-paste.

Ah yes... even documented it on github :-)

https://github.com/Yubico/pam-u2f/issues/33#issuecomment-195419924

Cheers,

Brian.

On Aug 23, 2022, at 6:15 AM, Jochen Bern <Jochen.Bern at binect.de>
wrote:
> Hello everyone, I hope that it is acceptable to post an only *halfway*
relevant request to the OpenSSH mailinglist ...
> 
> These days, I was sent to do on-site maintenance on one of the Linux based
appliances we make. The local admin led me to a rack and pointed to the KVM
unit, with the screen showing the appliance's login prompt - no network
access for my laptop, no physical access to the appliance (nowhere to be seen),
please type your appliance's maintenance password into our hardware.
Didn't much like that, and the surveillance camera a foot and a half above
the keyboard didn't help any, either.
> 
> So now I'm looking for a new (additional), replay-attack-safe
authentication method to add to the product. Searched the web for
"challenge-response" and "PAM" (so that it'll also work
with sshd if needed), and so far, everything remotely acceptable seems to go
back to three basic principles:
> 
> -- Tokens like Yubikeys, which wouldn't have worked here thanks to no
physical access.
> 
> -- HOTP, which would lack the *single* strictly-(de|in)creasing counter to
be replay safe (snarf response used on a "well worn" appliance, replay
it on one with a "younger" counter, unless we start shipping
appliances with *individual* secrets to boot).
> 
> -- TOTP, which *would* be replay safe - if only our appliances weren't
meant to sync against the customers' own NTP servers, so that their time can
trivially be off or downright manipulated.
> 
> What I'm looking for is a solution where the appliance would prompt
with a *randomly chosen* challenge, random enough to make it unfeasible to try
and wait for the challenge to repeat, the technician types the challenge into
some device of his own (laptop, if need be), types the response displayed back
into the appliance, and hey, nice camera you have there making an *entirely
useless* recording.
> 
> Would anyone here happen to know of such a beast?

What you?re describing sounds like an RSA SecurID token with a keypad.
Originally, these were hardware tokens with a small display and keypad. You?d
enter the challenge presented by the server in via the keypad and the token
would display a response to enter. There was also a time-based component to it,
and explicit protection against using a response more than once. I don?t have
much experience with the back-end part of this but I believe it required some
kind of SecurID server that took care of initializing tokens. I?m not sure if
that server also performed the challenge/response generation and validation, or
if that could be done independently on the servers requesting the authentication
once things were set up.

These days, I think you can get either hardware or software tokens, the latter
of which could run on a smart phone or laptop, if you didn?t want to have to
carry around a separate physical token. These should work with standard SSH
challenge/response authentication, once you have the SecurID software installed.
-- 
Ron Frederick
ronf at timeheart.net

On 8/23/22 15:15, Jochen Bern wrote:
> -- HOTP, which would lack the *single* strictly-(de|in)creasing counter 
> to be replay safe (snarf response used on a "well worn"
appliance,
> replay it on one with a "younger" counter, unless we start
shipping
> appliances with *individual* secrets to boot).
> 
> -- TOTP, which *would* be replay safe - if only our appliances weren't 
> meant to sync against the customers' own NTP servers, so that their
time
> can trivially be off or downright manipulated.
> 
> What I'm looking for is a solution where the appliance would prompt
with
> a *randomly chosen* challenge, random enough to make it unfeasible to 
> try and wait for the challenge to repeat, the technician types the 
> challenge into some device of his own (laptop, if need be), types the 
> response displayed back into the appliance, and hey, nice camera you 
> have there making an *entirely useless* recording.
OCRA?
(also one of the OATH standards)

https://www.rfc-editor.org/rfc/rfc6287

Ciao, Michael.

How about having a background job that just changes the root password regularly
to a new random value, encrypts it with some gpg key, and presents the encrypted
data as qr on a virtual console?

You just read it in via the notebook webcam, use your private key to decrypt it,
and enter it - no PAM changes needed at all.


You can easily choose the length, validity period and complexity to whatever you
want or require; and it won't repeat.

On 23.08.22 15:15, Jochen Bern wrote:
> What I'm looking for is a solution where the appliance would prompt
with
> a *randomly chosen* challenge, random enough to make it unfeasible to 
> try and wait for the challenge to repeat, the technician types the 
> challenge into some device of his own (laptop, if need be), types the 
> response displayed back into the appliance, and hey, nice camera you 
> have there making an *entirely useless* recording.
> 
> Would anyone here happen to know of such a beast?
Thanks for the suggestions, let me answer in more detail below ...

On 23.08.22 15:32, Philipp Marek wrote:
> How about a cronjob that prints a new random text-qr on a virtual console
> every minute or so, which can be scanned by your smartphone and is used to
> derive some root password?
... I'll keep that in mind in case the challenges get too long to *type* 
them off the screen into my own device. (Otherwise, and assuming that 
extra prompts through PAM aren't feasible, I'd probably have such a cron
job edit /etc/issue instead, so that an up-to-date (textual) challenge 
appears as you refresh the login prompt.) My problem rather is, however, 
that I'd like to have a proven *algorithm* for such a challenge-response 
mechanism, rather than to roll my own security/cryptalgorithms (and risk 
myself and my employer ending up in Bruce Schneier's doghouse) ...
> As a completely different idea, if the applicance has a camera or other
> input (IR), you could run IP via QR or over an optical serial connection...
In my experience, if I can get close enough to use IR communication, I 
could plug a NIC/token/keyboard/whatever into a USB port as well. (That 
rack - assuming that the appliance *was* somewhere in there - had 
neither doors nor side walls, which sure helped my using the rack KVM's 
keyboard ...)

On 23.08.22 16:56, Brian Candler wrote:
> You mean something like SCRAM implemented as a PAM module?
Looks promising from the algorithm POV ... !
> It might be possible to use pam_sasl [...] together with a SASL challenge-
> response auth method [...] like SCRAM.
cyrus-sasl-scram seems to be available from standard OS repos, pam_exec 
comes with the default PAM installation. pam_sasl (or a SASL client to 
use with pam_exec, I don't see testsaslauthd allowing for presenting and 
processing a challenge first) I'll have to look into ...
> You mentioned Yubikeys.  Depending on the flavour of key, they implement
> a range of different auth methods
(Please don't remind me ... I still have the task of surveying available 
tokens for potential additional functionality we might want to have, 
like secure storage for SSH user keypairs and/or SSH certificates - to 
name but what I *expect* to find.)
> some of which are suitable for keyboard use; that is, you don't need to
> plug them directly into the target system.
> 
> You've already ruled out Yubi OTP mode and HOTP mode, but there is also
> a HMAC-SHA1 type of challenge-response.  I found two modules: the official
> module [...] and [...]. Both are stateful to avoid storing the secret in
> cleartext on the server, so may suffer from the same replay attacks you
> discussed - but I haven't investigated in detail.  It might be possible
> to use the same secret on all targets, but seed them with different
> challenges.
The explanation in your second link, where it says "This approach is 
used by the PAM module provided by Yubico", makes me suspicious. It says 
that the expected response for the *next* authentication "is transferred 
in cleartext in the current session" - and in my use case, said 
"session" is some guy retyping stuff into a keyboard, with all the 
possibilities of shoulder surfing and typos that brings.

(Apart from that, I'm under the impression that *both* methods require 
*all* tokens to maintain some sort of ongoing sync with *all* servers ... ?)

On 23.08.22 16:57, Ron Frederick wrote:
> What you?re describing sounds like an RSA SecurID token with a keypad.
Never used one, but I *think* I *saw* those back in the days. Though I'd 
probably forego the hardware aided security part (hey, we're using a 
*password* right now) and use something a lot like oathtool on my laptop 
instead.

On 23.08.22 17:08, Michael Str?der wrote:
> OCRA?
> (also one of the OATH standards)
I had run into OCRA during my web search, and dismissed it after 
repeated mention of it being based on "HOTP", but that might've
been
premature; after all, the RFC lists "OCRA-1:HOTP-SHA1-4:QH8-S512" as
an
example suite which supposedly uses "a random hexadecimal challenge up 
to 8 nibbles and a session value of 512 bytes" but *not* C(ounter) or 
T(imestamp) inputs to the challenge.

Unfortunately, the only FOSS implementations I can find any *mention* of 
are pam_ocra and ocra_tool from FreeBSD, and even there, there seems to 
be no mention of what OCRA suites they *actually* support/allow ... ?

https://www.gsp.com/cgi-bin/man.cgi?section=8&topic=pam_ocra
https://www.gsp.com/cgi-bin/man.cgi?section=8&topic=OCRA_TOOL

Now if only *oath*tool would support all the *OATH* standards, up to and 
including OCRA ... :-3

Thanks again,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220823/3735dbfc/attachment-0001.p7s>

On Tue, 23 Aug 2022 at 23:23, Jochen Bern <Jochen.Bern at binect.de>
wrote:
[...]
> So now I'm looking for a new (additional), replay-attack-safe
> authentication method to add to the product.
This sounds like S/Key[0] or OPIE[1].  There are PAM modules available
for at least OPIE, and (to drag this moderately back on topic), those
should work with sshd's ChallengeResponseAuthentication.

If you're worried about the compromise of an appliance disclosing a
fleet-wide shared secret you could make a per-device shared secret by
hashing a fleetwide secret with a per-appliance identifier before
storing it on the appliance.  In the field you would
hash(secret|deviceid) to derive the per-device secret, then feed it
and the challenge from the device into opiekey to compute the one time
password.

[0] https://en.wikipedia.org/wiki/S/KEY
[1] https://en.wikipedia.org/wiki/OPIE_Authentication_System

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On 8/23/22 09:15, Jochen Bern wrote:
> Hello everyone, I hope that it is acceptable to post an only *halfway* 
> relevant request to the OpenSSH mailinglist ...
> 
> These days, I was sent to do on-site maintenance on one of the Linux 
> based appliances we make. The local admin led me to a rack and pointed 
> to the KVM unit, with the screen showing the appliance's login prompt -
> no network access for my laptop, no physical access to the appliance 
> (nowhere to be seen), please type your appliance's maintenance password
> into our hardware. Didn't much like that, and the surveillance camera a
> foot and a half above the keyboard didn't help any, either.
> 
> So now I'm looking for a new (additional), replay-attack-safe 
> authentication method to add to the product. Searched the web for 
> "challenge-response" and "PAM" (so that it'll also
work with sshd if
> needed), and so far, everything remotely acceptable seems to go back to 
> three basic principles:
> 
> -- Tokens like Yubikeys, which wouldn't have worked here thanks to no 
> physical access.
> 
> -- HOTP, which would lack the *single* strictly-(de|in)creasing counter 
> to be replay safe (snarf response used on a "well worn"
appliance,
> replay it on one with a "younger" counter, unless we start
shipping
> appliances with *individual* secrets to boot).
> 
> -- TOTP, which *would* be replay safe - if only our appliances weren't 
> meant to sync against the customers' own NTP servers, so that their
time
> can trivially be off or downright manipulated.
> 
> What I'm looking for is a solution where the appliance would prompt
with
> a *randomly chosen* challenge, random enough to make it unfeasible to 
> try and wait for the challenge to repeat, the technician types the 
> challenge into some device of his own (laptop, if need be), types the 
> response displayed back into the appliance, and hey, nice camera you 
> have there making an *entirely useless* recording.
> 
> Would anyone here happen to know of such a beast?
From a more meta perspective:

- Having a shared secret used by all appliances is a really bad idea.
  Root or even physical access to one appliance should not harm the
  security of any other appliance.

- A determined attacker with physical access *will* be able to get
  root on the box, so plan accordingly.  You do not want the iOS
  situation where researchers hoard exploits because they cannot do
  their work without them.

- It seems that you are trying to prevent your customer (who presumably
  owns the product) from being able to log in to their own devices.
  Generally, this is considered rather consumer-unfriendly, so I
  would like to know what the underlying reason for it is.

- Challenge-response will not prevent an attacker from injecting
  their own data into the already-authenticated session.  However,
  given that you should be assuming that whoever has physical access
  can get root (see above), this should not be a serious problem.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 4885 bytes
Desc: OpenPGP public key
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220824/98d4c3d3/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220824/98d4c3d3/attachment-0001.asc>