Re: Putting OPIE to rest
- In reply to: Joe Schaefer : "Re: Putting OPIE to rest"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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. >> >>