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)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
