Mailing List Archive

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?


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

On 23/08/2022 14: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?

You mean something like SCRAM implemented as a PAM module?  I can't
think of one off hand, but there's always pam_exec which is pretty easy
to plug into.

It might be possible to use pam_sasl
<http://www1.maths.leeds.ac.uk/~pmtvlm/pam-sasl.html> together with a
SASL challenge-response auth method
<https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html>
like SCRAM.

You mentioned Yubikeys.  Depending on the flavour of key, they implement
a range of different auth methods, 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
<https://developers.yubico.com/yubico-pam/Authentication_Using_Challenge-Response.html>
and http://www.average.org/chal-resp-auth/. 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.

Aside: I did once play with a PAM module which allows manual U2F
challenge/response over ssh keyboard-interactive authentication. What
happened was, you'd connect via ssh and it would spit out a long
challenge. You paste this into a local client app, and press the button
on your U2F key.  The client spits out a long response, and you paste it
back into the ssh session.  Bingo.

It did actually work - but unfortunately the strings were way too long
to be practical over a KVM without copy-paste.

Ah yes... even documented it on github :-)

https://github.com/Yubico/pam-u2f/issues/33#issuecomment-195419924

Cheers,

Brian.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Aug 23, 2022, at 6:15 AM, Jochen Bern <Jochen.Bern@binect.de> wrote:
> Hello everyone, I hope that it is acceptable to post an only *halfway* relevant request to the OpenSSH mailinglist ...
>
> These days, I was sent to do on-site maintenance on one of the Linux based appliances we make. The local admin led me to a rack and pointed to the KVM unit, with the screen showing the appliance's login prompt - no network access for my laptop, no physical access to the appliance (nowhere to be seen), please type your appliance's maintenance password into our hardware. Didn't much like that, and the surveillance camera a foot and a half above the keyboard didn't help any, either.
>
> So now I'm looking for a new (additional), replay-attack-safe authentication method to add to the product. Searched the web for "challenge-response" and "PAM" (so that it'll also work with sshd if needed), and so far, everything remotely acceptable seems to go back to three basic principles:
>
> -- Tokens like Yubikeys, which wouldn't have worked here thanks to no physical access.
>
> -- HOTP, which would lack the *single* strictly-(de|in)creasing counter to be replay safe (snarf response used on a "well worn" appliance, replay it on one with a "younger" counter, unless we start shipping appliances with *individual* secrets to boot).
>
> -- TOTP, which *would* be replay safe - if only our appliances weren't meant to sync against the customers' own NTP servers, so that their time can trivially be off or downright manipulated.
>
> 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?


What you’re describing sounds like an RSA SecurID token with a keypad. Originally, these were hardware tokens with a small display and keypad. You’d enter the challenge presented by the server in via the keypad and the token would display a response to enter. There was also a time-based component to it, and explicit protection against using a response more than once. I don’t have much experience with the back-end part of this but I believe it required some kind of SecurID server that took care of initializing tokens. I’m not sure if that server also performed the challenge/response generation and validation, or if that could be done independently on the servers requesting the authentication once things were set up.

These days, I think you can get either hardware or software tokens, the latter of which could run on a smart phone or laptop, if you didn’t want to have to carry around a separate physical token. These should work with standard SSH challenge/response authentication, once you have the SecurID software installed.
--
Ron Frederick
ronf@timeheart.net



_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 8/23/22 15:15, Jochen Bern wrote:
> -- HOTP, which would lack the *single* strictly-(de|in)creasing counter
> to be replay safe (snarf response used on a "well worn" appliance,
> replay it on one with a "younger" counter, unless we start shipping
> appliances with *individual* secrets to boot).
>
> -- TOTP, which *would* be replay safe - if only our appliances weren't
> meant to sync against the customers' own NTP servers, so that their time
> can trivially be off or downright manipulated.
>
> 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.

OCRA?
(also one of the OATH standards)

https://www.rfc-editor.org/rfc/rfc6287

Ciao, Michael.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

How about having a background job that just changes the root password regularly to a new random value, encrypts it with some gpg key, and presents the encrypted data as qr on a virtual console?

You just read it in via the notebook webcam, use your private key to decrypt it, and enter it - no PAM changes needed at all.


You can easily choose the length, validity period and complexity to whatever you want or require; and it won't repeat.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

On Tue, 23 Aug 2022 at 23:23, Jochen Bern <Jochen.Bern@binect.de> wrote:
[...]
> So now I'm looking for a new (additional), replay-attack-safe
> authentication method to add to the product.

This sounds like S/Key[0] or OPIE[1]. There are PAM modules available
for at least OPIE, and (to drag this moderately back on topic), those
should work with sshd's ChallengeResponseAuthentication.

If you're worried about the compromise of an appliance disclosing a
fleet-wide shared secret you could make a per-device shared secret by
hashing a fleetwide secret with a per-appliance identifier before
storing it on the appliance. In the field you would
hash(secret|deviceid) to derive the per-device secret, then feed it
and the challenge from the device into opiekey to compute the one time
password.

[0] https://en.wikipedia.org/wiki/S/KEY
[1] https://en.wikipedia.org/wiki/OPIE_Authentication_System

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 8/23/22 09:15, Jochen Bern wrote:
> Hello everyone, I hope that it is acceptable to post an only *halfway*
> relevant request to the OpenSSH mailinglist ...
>
> These days, I was sent to do on-site maintenance on one of the Linux
> based appliances we make. The local admin led me to a rack and pointed
> to the KVM unit, with the screen showing the appliance's login prompt -
> no network access for my laptop, no physical access to the appliance
> (nowhere to be seen), please type your appliance's maintenance password
> into our hardware. Didn't much like that, and the surveillance camera a
> foot and a half above the keyboard didn't help any, either.
>
> So now I'm looking for a new (additional), replay-attack-safe
> authentication method to add to the product. Searched the web for
> "challenge-response" and "PAM" (so that it'll also work with sshd if
> needed), and so far, everything remotely acceptable seems to go back to
> three basic principles:
>
> -- Tokens like Yubikeys, which wouldn't have worked here thanks to no
> physical access.
>
> -- HOTP, which would lack the *single* strictly-(de|in)creasing counter
> to be replay safe (snarf response used on a "well worn" appliance,
> replay it on one with a "younger" counter, unless we start shipping
> appliances with *individual* secrets to boot).
>
> -- TOTP, which *would* be replay safe - if only our appliances weren't
> meant to sync against the customers' own NTP servers, so that their time
> can trivially be off or downright manipulated.
>
> 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?
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)

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

On 23/08/2022 22:42, Jochen Bern wrote:
> 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 ...
>
If this is just to protect a single account, say an "engineer" login,
you could just make the user's login shell be a small program which does
the challenge/response, and then execs the real shell if successful.

I rather like the QR code idea given by someone else:

* generate a small random value (e.g. 6-digit PIN)
* encrypt it with public key
* show the encrypted value as a QR code
* user decrypts it and types in the decrypted value
* permit login if they match

No secret information needs to be stored on the target system at all,
and they can all be identical.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 8/23/22 22:11, Demi Marie Obenour wrote:
>
> - 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.
>

I have to second  on this, as it's been my experience so far that vendors who try to lock customers out of systems are either trying to hide some seriously weak system builds, or some shady ethical/technical practices the customer would veto if they could see them or knew about them.  I'm fighting this in my workplace all the time, as we have systems that (if they fail or are compromised) will cause human harm, and that's just not a negotiable item for us any more.

--
# include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@GMail.com> */

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>> - 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.

> I have to second  on this, as it's been my experience so far that
> vendors who
> try to lock customers out of systems are either trying to hide some
> seriously
> weak system builds, or some shady ethical/technical practices the
> customer
> would veto if they could see them or knew about them.  I'm fighting
> this in
> my workplace all the time, as we have systems that (if they fail or are
> compromised) will cause human harm, and that's just not a negotiable
> item for
> us any more.

Yeah, I'm annoyed by (badly) working appliances all the time, too,
and would also prefer a way to see all logs, modify the behaviour, etc.
--
but that's because I believe that I can do a better job than the
manufacturer!


Whether that is true or not depends not only on the manufacturer,
but also on every single on of the customers' people who (may) have
access
to the box.

You surely don't want to get a box into your network that has _worse_
access
controls than your own boxes, right? Because that would provide
attackers
with an easy first point.
Extrapolating that, such white boxes should be as unbreakable as
possible
against _unauthorized_ access (yeah, I know about hardware access etc.).


But that is exactly the point --
"owning" the product also means "maintaining it".

And that's just not possible if any customer may "simply" log in
and change stuff at will.

[.[. Imagine someone modifying your email, fileserver,
or virus scan appliance to relay all "interesting" data
to some external service (or a local USB stick that
gets removed after the weekend!) ]]


IMO two issues are conflated here --

a) the basic security should be as good as possible,
to prevent unauthorized access;

b) but perhaps (some) customers should be given a wide-range
_read_ access to system logs as a debugging aid.


Just my ¢0,02.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev