Andreas Jellinghaus wrote:
> well, a smart card might allow access to many machines. so I care a lot
> more about the single smart card (where I maybe only have one backup),
> than about a single machine - can be always reinstalled or restored.
That's correct but not relevant for this discussion. If one of your
machines gets compromised, your PIN is no longer safe.
If an attacker can _alter_ your PAM configuration to add a module
before/after pam-p11 then he could as well replace pam-p11 with his own
evil version altogether that mails your PIN to his e-mail address.
compromised root == compromised used PINs
Setting AUTHTOK or not doesn't change that.
> entering the wrong password will give you a delay on a normal machine.
> entering the wrong pin will block the card. so cards are a lot more fragile
> even with normal use, and need additional protection. thats why I also
> think a smart card module should never accept the password already given
> to some other module - it is ok to give the same password to two
> databases (nis, ldap, pwent), but if one of the things you try is a
> smart card, that is a recipe to lock it up fast.
That's a very different thingQ
You removed the call to pam_set_item(pamh, PAM_AUTHTOK, password) which
*sets* the entered password (i.e. PIN) as an authentication token so it
can be used from subsequent modules. This is a thing that most, if not
all, authentication modules do.
pam-p11 also reads PAM_AUTHTOK (by the means of pam_get_item(pamh,
PAM_AUTHTOK, &password), line 180) that was set by previous PAM modules.
Most PAM modules don't do that automatically; instead, they have a
configuration option use_first_pass/try_first_pass (which are documented
as "generic PAM arguments") that instructs the module to use the
password from the preceding authentication module and optionally ask for
a new password if the supplied one fails.
> but I'm by far no expert on writing pam modules. I would like to make
> all of this configureable and would appreciate any help in doing that.
> "secure by default" should be a configuation that protects the card,
> as it can lock up much faster than the machine it is used with. but
> there is no reason not to offer options e.g. for accepting passwords
> entered for other modules, to forward passwords to other modules,
> to not print the user / label of the pin to be entered, and other
> things we could have as option.
To summarize, I really can't see a reason for not passing the PIN to
*subsequent* modules.
I agree however that reading the PIN from preceding modules should be
optional by using the generic PAM arguments {use,try}_user_pass I
described above. This is indeed a bug and I will try to code up a patch.
If you want I could open a ticket to have this as a TODO item.
Best regards,
Faidon
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
