Date: Thu, 15 Sep 2022 19:31:18 -0400 From: Joe Schaefer <joesuf4@gmail.com> To: grarpamp <grarpamp@gmail.com> Cc: des@des.no, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-security@freebsd.org Subject: Re: Putting OPIE to rest Message-ID: <CAOzHqcJUoGXUzgTzCsAP2U=oy9OvhU-HH-MYLrw1OZpjHj3v5w@mail.gmail.com> In-Reply-To: <CAD2Ti2_AQCFJRWiwErEdn1hY0Qms0=znTx3T_CjDQ4kvoKG2OQ@mail.gmail.com> References: <86h718sqdx.fsf@ltc.des.no> <CAD2Ti2_AQCFJRWiwErEdn1hY0Qms0=znTx3T_CjDQ4kvoKG2OQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000012c19505e8bfa5be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=B8rgrav <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. > > --00000000000012c19505e8bfa5be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">google-authenticator-libpam works for sudo controls?</div= ><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">= On Thu, Sep 15, 2022 at 7:01 PM grarpamp <<a href=3D"mailto:grarpamp@gma= il.com">grarpamp@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le= ft-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On 9/15= /22, Dag-Erling Sm=C3=B8rgrav <<a href=3D"mailto:des@des.no" target=3D"_= blank">des@des.no</a>> wrote:<br> > I will be removing OPIE from the main branch within the next few days.= <br> > It has long outlived its usefulness.=C2=A0 Anyone still using it shoul= d look<br> > into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).= <br> > <a href=3D"https://reviews.freebsd.org/D36592" rel=3D"noreferrer" targ= et=3D"_blank">https://reviews.freebsd.org/D36592</a><br>; <br> At least so long as PAM remains available, OPIE should be<br> maintained as a PAM option, and be updated.<br> <br> OPIE is the only PAM that allows printing out the future<br> secure tokens. Old school, secure, it just works.<br> <br> HOTP requires hardware, TOTP requires time,<br> neither are printable, both of those require some other<br> [hackable] hw/sw device that costs $$$ money, and<br> those devices all have different threat/failure/admin models<br> than simple paper.<br> <br> If people don't like...<br> - The hash algo, a volunteer committer can update it to sha256.<br> - The list of words, a volunteer committer can update it to<br> read from a list of admin supplied words in:<br> /etc/opie_words.txt<br> - The number of words, a volunteer committer can add an<br> option to the config for that.<br> - The writeable state breaking in a read-only root, a volunteer<br> committer can add a config option to point that elsewhere.<br> - The randomness, a volunteer committer can update it<br> to modern randomness.<br> <br> And if people still don't like it, then commit those simple updates,<br= > and push it out to ports, instead of killing users use of it.<br> <br> </blockquote></div></div> --00000000000012c19505e8bfa5be--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOzHqcJUoGXUzgTzCsAP2U=oy9OvhU-HH-MYLrw1OZpjHj3v5w>