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
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
