A problem with doing that, is that anything that runs with the user's
permissions could trivially read the secret key from the user's home
directory. With SSH keys it's not a problem, since they are _public_
keys. Plus, a user could do something stupid, like resetting the OTP
counter on every login, so they wouldn't need to use a pesky changing
password, but instead use the same one always...
I think some unix-like systems have per-user password files under /etc,
so that they don't need setuid-root helpers to access them, but there
still is some program to sanity check the password the user tries to
set. (a setgid helper plus some trickery with file and directory
permissions.) Doing something like that would simplify the backend, but
of course you'd still need a helper application to access the files.
On 15.12. 7:23, Antoine Beaupré wrote:
Package: libpam-oath
Version: 2.4.1-1
Severity: wishlist
i find it problematic that the management of the OATH secrets is all
centralised in a single file. it seems to me it would be preferable to
delegate this management to users, the same way we have
`~/.ssh/authorized_keys`.
i suggest checking into `~user/.oath` for a similar format (obviously
ommitting the username, to avoid forging other people's credentials).
could that be considered?
-- System Information:
Debian Release: 8.2
APT prefers stable
APT policy: (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpam-oath depends on:
ii libc6 2.19-18+deb8u1
ii liboath0 2.4.1-1
ii libpam-runtime 1.1.8-3.1
ii libpam0g 1.1.8-3.1
libpam-oath recommends no packages.
libpam-oath suggests no packages.
-- no debconf information
--
Ilkka Virta <itvi...@iki.fi>
