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

David Lang 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?

David Lang
-------------- next part --------------
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org

More information about the openssh-unix-dev mailing list