Re: Putting OPIE to rest

From: Joe Schaefer <joesuf4_at_gmail.com>
Date: Fri, 16 Sep 2022 17:46:25 UTC
Answering my own question: yes it can, but there's no "challenge" string
for TOTP nor HOTP.
If you want sha-1 in an "opie" framework, check out
https://github.com/SunStarSys/orthrus


On Thu, Sep 15, 2022 at 7:31 PM Joe Schaefer <joesuf4@gmail.com> wrote:

> google-authenticator-libpam works for sudo controls?
>
> On Thu, Sep 15, 2022 at 7:01 PM grarpamp <grarpamp@gmail.com> wrote:
>
>> On 9/15/22, Dag-Erling Smørgrav <des@des.no> wrote:
>> > I will be removing OPIE from the main branch within the next few days.
>> > It has long outlived its usefulness.  Anyone still using it should look
>> > into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).
>> > https://reviews.freebsd.org/D36592
>>
>> At least so long as PAM remains available, OPIE should be
>> maintained as a PAM option, and be updated.
>>
>> OPIE is the only PAM that allows printing out the future
>> secure tokens. Old school, secure, it just works.
>>
>> HOTP requires hardware, TOTP requires time,
>> neither are printable, both of those require some other
>> [hackable] hw/sw device that costs $$$ money, and
>> those devices all have different threat/failure/admin models
>> than simple paper.
>>
>> If people don't like...
>> - The hash algo, a volunteer committer can update it to sha256.
>> - The list of words, a volunteer committer can update it to
>> read from a list of admin supplied words in:
>> /etc/opie_words.txt
>> - The number of words, a volunteer committer can add an
>> option to the config for that.
>> - The writeable state breaking in a read-only root, a volunteer
>> committer can add a config option to point that elsewhere.
>> - The randomness, a volunteer committer can update it
>> to modern randomness.
>>
>> And if people still don't like it, then commit those simple updates,
>> and push it out to ports, instead of killing users use of it.
>>
>>