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

[Jochen Bern]

On 23.08.22 15:15, Jochen Bern wrote:
> 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?

Thanks for the suggestions, let me answer in more detail below ...

On 23.08.22 15:32, Philipp Marek wrote:
> How about a cronjob that prints a new random text-qr on a virtual console
> every minute or so, which can be scanned by your smartphone and is used to
> derive some root password?

... I'll keep that in mind in case the challenges get too long to *type* 
them off the screen into my own device. (Otherwise, and assuming that 
extra prompts through PAM aren't feasible, I'd probably have such a cron 
job edit /etc/issue instead, so that an up-to-date (textual) challenge 
appears as you refresh the login prompt.) My problem rather is, however, 
that I'd like to have a proven *algorithm* for such a challenge-response 
mechanism, rather than to roll my own security/cryptalgorithms (and risk 
myself and my employer ending up in Bruce Schneier's doghouse) ...

> As a completely different idea, if the applicance has a camera or other
> input (IR), you could run IP via QR or over an optical serial connection...

In my experience, if I can get close enough to use IR communication, I 
could plug a NIC/token/keyboard/whatever into a USB port as well. (That 
rack - assuming that the appliance *was* somewhere in there - had 
neither doors nor side walls, which sure helped my using the rack KVM's 
keyboard ...)

On 23.08.22 16:56, Brian Candler wrote:
> You mean something like SCRAM implemented as a PAM module?

Looks promising from the algorithm POV ... !

> It might be possible to use pam_sasl [...] together with a SASL challenge-
> response auth method [...] like SCRAM.

cyrus-sasl-scram seems to be available from standard OS repos, pam_exec 
comes with the default PAM installation. pam_sasl (or a SASL client to 
use with pam_exec, I don't see testsaslauthd allowing for presenting and 
processing a challenge first) I'll have to look into ...

> You mentioned Yubikeys.  Depending on the flavour of key, they implement
> a range of different auth methods

(Please don't remind me ... I still have the task of surveying available 
tokens for potential additional functionality we might want to have, 
like secure storage for SSH user keypairs and/or SSH certificates - to 
name but what I *expect* to find.)

> some of which are suitable for keyboard use; that is, you don't need to
> plug them directly into the target system.
> 
> You've already ruled out Yubi OTP mode and HOTP mode, but there is also
> a HMAC-SHA1 type of challenge-response.  I found two modules: the official
> module [...] and [...]. Both are stateful to avoid storing the secret in
> cleartext on the server, so may suffer from the same replay attacks you
> discussed - but I haven't investigated in detail.  It might be possible
> to use the same secret on all targets, but seed them with different
> challenges.

The explanation in your second link, where it says "This approach is 
used by the PAM module provided by Yubico", makes me suspicious. It says 
that the expected response for the *next* authentication "is transferred 
in cleartext in the current session" - and in my use case, said 
"session" is some guy retyping stuff into a keyboard, with all the 
possibilities of shoulder surfing and typos that brings.

(Apart from that, I'm under the impression that *both* methods require 
*all* tokens to maintain some sort of ongoing sync with *all* servers ... ?)

On 23.08.22 16:57, Ron Frederick wrote:
> What you’re describing sounds like an RSA SecurID token with a keypad.

Never used one, but I *think* I *saw* those back in the days. Though I'd 
probably forego the hardware aided security part (hey, we're using a 
*password* right now) and use something a lot like oathtool on my laptop 
instead.

On 23.08.22 17:08, Michael Ströder wrote:
> OCRA?
> (also one of the OATH standards)

I had run into OCRA during my web search, and dismissed it after 
repeated mention of it being based on "HOTP", but that might've been 
premature; after all, the RFC lists "OCRA-1:HOTP-SHA1-4:QH8-S512" as an 
example suite which supposedly uses "a random hexadecimal challenge up 
to 8 nibbles and a session value of 512 bytes" but *not* C(ounter) or 
T(imestamp) inputs to the challenge.

Unfortunately, the only FOSS implementations I can find any *mention* of 
are pam_ocra and ocra_tool from FreeBSD, and even there, there seems to 
be no mention of what OCRA suites they *actually* support/allow ... ?

https://www.gsp.com/cgi-bin/man.cgi?section=8&topic=pam_ocra
https://www.gsp.com/cgi-bin/man.cgi?section=8&topic=OCRA_TOOL

Now if only *oath*tool would support all the *OATH* standards, up to and 
including OCRA ... :-3

Thanks again,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220823/3735dbfc/attachment-0001.p7s>