{"id":778,"date":"2018-08-24T08:44:17","date_gmt":"2018-08-24T06:44:17","guid":{"rendered":"https:\/\/blogs.gentoo.org\/mgorny\/?p=778"},"modified":"2018-08-24T09:28:53","modified_gmt":"2018-08-24T07:28:53","slug":"securing-google-authenticator-libpam-against-reading-secrets","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/mgorny\/2018\/08\/24\/securing-google-authenticator-libpam-against-reading-secrets\/","title":{"rendered":"Securing google-authenticator-libpam against reading secrets"},"content":{"rendered":"

I have recently worked on\u00a0enabling 2-step authentication via SSH on\u00a0the\u00a0Gentoo developer machine. I have selected google-authenticator-libpam<\/a> amongst different available implementations as\u00a0it seemed the\u00a0best maintained and\u00a0having all the\u00a0necessary features, including a\u00a0friendly tool for users to\u00a0configure it. However, its design has a\u00a0weakness: it stores the\u00a0secret unprotected in\u00a0user’s home directory.<\/p>\n

This means that if\u00a0an\u00a0attacker manages to\u00a0gain at\u00a0least temporary access to the\u00a0filesystem with user’s privileges \u2014 through a\u00a0malicious process, vulnerability or\u00a0simply because someone left the\u00a0computer unattended for a\u00a0minute \u2014 he can trivially read the\u00a0secret and\u00a0therefore clone the\u00a0token source without leaving a\u00a0trace. It would completely defeat the\u00a0purpose of\u00a0the\u00a0second step, and\u00a0the\u00a0user may not even notice until the\u00a0attacker makes real use of\u00a0the\u00a0stolen secret.<\/p>\n

<\/p>\n

In\u00a0order to\u00a0protect against this, I’ve created google-authenticator-wrappers<\/a> (as\u00a0upstream decided to\u00a0ignore the\u00a0problem<\/a>). This package provides a\u00a0rather trivial setuid wrapper that manages a\u00a0write-only, authentication-protected secret store for\u00a0the\u00a0PAM module. Additionally, it comes with a\u00a0test program (so you can test the\u00a0OTP setup without jumping through the\u00a0hoops or\u00a0risking losing access) and\u00a0friendly wrappers for\u00a0the\u00a0default setup, as\u00a0used on\u00a0Gentoo Infra.<\/p>\n

The\u00a0recommended setup (as\u00a0utilized by\u00a0sys-auth\/google-authenticator-wrappers<\/a> package) is to\u00a0use a\u00a0dedicated user for the\u00a0password store. In\u00a0this scenario, the\u00a0users are unable to\u00a0read their secrets, and\u00a0all secret operations (including authentication via the\u00a0PAM module) are done using an\u00a0unprivileged user. Furthermore, any operation regarding the\u00a0configuration (either updating it or\u00a0removing the\u00a0second step) require regular PAM authentication (e.g.\u00a0typing your own password).<\/p>\n

This is consistent with e.g.\u00a0how shadow operates (users can’t read their passwords, nor\u00a0update them without authenticating first), how most sites using 2-factor authentication operate (again, users can’t read their secrets) and\u00a0follows the\u00a0RFC\u00a06238<\/a> recommendation (that keys [\u2026] SHOULD be protected against unauthorized access and usage<\/q>). It solves the\u00a0aforementioned issue by\u00a0preventing user-privileged processes from\u00a0reading the\u00a0secrets and\u00a0recovery codes. Furthermore, it prevents the\u00a0attacker with this particular level of\u00a0access from disabling 2-step authentication, changing the\u00a0secret or\u00a0even weakening the\u00a0configuration.<\/p>\n","protected":false},"excerpt":{"rendered":"

I have recently worked on\u00a0enabling 2-step authentication via SSH on\u00a0the\u00a0Gentoo developer machine. I have selected google-authenticator-libpam amongst different available implementations as\u00a0it seemed the\u00a0best maintained and\u00a0having all the\u00a0necessary features, including a\u00a0friendly tool for users to\u00a0configure it. However, its design has a\u00a0weakness: it stores the\u00a0secret unprotected in\u00a0user’s home directory. This means that if\u00a0an\u00a0attacker manages to\u00a0gain at\u00a0least temporary … Continue reading “Securing google-authenticator-libpam against reading secrets”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[10],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/778"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=778"}],"version-history":[{"count":6,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/778\/revisions"}],"predecessor-version":[{"id":785,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/778\/revisions\/785"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=778"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=778"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=778"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}