Looking for Special Challenge-Response Auth PAM Module, or Similar

[Demi Marie Obenour]

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>