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_TOOLNow if only *oath*tool would support all the *OATH* standards, up to and including OCRA ... :-3
Thanks again, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
