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

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>

On Wed, 24 Aug 2022, Demi Marie Obenour wrote:
> 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.
very much agree with everything Demi says here.

years ago I implemented the Defender challenge/response protocol as a pam 
plugin. It had a per-user secret (see discussion above on how you could have a 
per device one) and then generated a random number and presented it to you. you 
entered it into a handheld calc type thing which encrypted it with the secret 
(this is old enough it used DES), and a portion of the result was the password 
(6-8 characters of challenge, 8 characters of hex output, not unreasonable to 
type)

just don't implement it as a phone app or you become only as secure as that
app

but again, why so customer hostile?

David Lang
-------------- next part --------------
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 8/23/22 22:11, Demi Marie Obenour wrote:
>
> - 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.
>
I have to second? on this, as it's been my experience so far that vendors
who try to lock customers out of systems are either trying to hide some
seriously weak system builds, or some shady ethical/technical practices the
customer would veto if they could see them or knew about them.? I'm fighting
this in my workplace all the time, as we have systems that (if they fail or are
compromised) will cause human harm, and that's just not a negotiable item
for us any more.

-- 
# include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott at GMail.com> */