[Bug 1506] rationalize agent behavior on smartcard removal/reattachment

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Mon Aug 18 14:28:24 EST 2008


https://bugzilla.mindrot.org/show_bug.cgi?id=1506





--- Comment #2 from Daniel Kahn Gillmor <dkg at fifthhorseman.net>  2008-08-18 14:28:20 ---
Yeah, we definitely don't want to lock people out of their cards with
the agent.

Given that the attached patch only retries if the error message is
SC_ERROR_READER_DETACHED, i don't think it will actually register two
strikes against the card's count of excessive retries.  It would
register one if the stored PIN was bad, but it should do that anyway,
whether or not the card was detached or re-attached.

However, if the user inserts a different card with a different PIN, the
proposed patch would trigger one count against that card.

OTOH, the most common use case is the one where the user gets up to go
to the bathroom and takes card and/or reader with him or her. 
Requiring re-authentication at each step (when the user probably
already had to re-authenticate somehow to unlock hir screensaver) seems
like a pain.

Of course, the current behavior is worse than either alternative,
particularly if the device wasn't added to the agent with -c, and the
authentication steps are happening without user approval.  You could
try to connect to a half-dozen hosts (using cssh, for example), and
immediately disable your card if you have a cached-but-wrong PIN.

What if the stored PIN (and the reference to the public key) were
entirely removed from the agent at any failure *other* than the initial
SC_ERROR_READER_DETACHED?  That way, we can protect the card against
destruction by the agent, and we clear the PIN if the agent is used
when the card is actually absent.  But we also doesn't cause annoyance
in the most common case (where people have to use the bathroom).

Does that seem reasonable?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list