Looking for Special Challenge-Response Auth PAM Module, or Similar
david at lang.hm
Wed Aug 24 15:46:43 AEST 2022
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
just don't implement it as a phone app or you become only as secure as that app
but again, why so customer hostile?
-------------- next part --------------
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
More information about the openssh-unix-dev