ThomasHabets
commented
3 years ago If your threat model is that people change their ga config file, then you should change their location and make them not editable by the user. Using options secret & user.
There are too many things the user could do to a config to make it useful to treat them as an adversary.
For a blocklist of passwords, that could probably better be done as a separate PAM module. That way it could be used more generically as well.
mjkenyon
Let me start by saying how useful this PAM module is.
I did note, however, that I can add very simple sequences of numbers to the scratch list. For example '12345678' and '11111111' both work (though '00000000' seemingly does not).
Humans being what they are, I'd worry that a lazy user might script something which appends an entirely guessable scratch code to their ~/.google_authenticator file each time they log in.
Is something like a passcode-strength validator viable? The result would be that we only generate and accept passcodes of a certain complexity - in the same way that many online services won't allow me to use the password '111111' or 'abcdef'.
It may be that the simplest solution is a hard-coded dictionary of forbidden passcodes, but that'd at least provide some level of protection.
Cheers Mike.