Closed Bug 374591 Opened 18 years ago Closed 17 years ago

User prompted for PIN for PKCS#11 token with CKF_PROTECTED_AUTHENTICATION_PATH support

Categories

(Core :: Security: PSM, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 119500

People

(Reporter: adam.augustyn, Assigned: KaiE)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

I have PKCS#11 smartcard module with PINpad support. The module presents CKF_PROTECTED_AUTHENTICATION_PATH flag. NSS library asks me for PIN and I have to enter it twice - firstly on PIN dialog, secondly on PINpad. It is a bit annoying.

Reproducible: Always

Steps to Reproduce:
1. Run Device Manager in FireFox
2. Add PKCS#11 module with CKF_PROTECTED_AUTHENTICATION_PATH support
3. Login to token with CKF_PROTECTED_AUTHENTICATION_PATH support
Actual Results:  
NSS PIN Dialog requires PIN even for CKF_PROTECTED_AUTHENTICATION_PATH compatible token

Expected Results:  
I think it would be better to show Dialog with information about PINpad.

The bug is located in file "security\manager\ssl\src\nsPK11TokenDB.cpp" in function "NS_IMETHODIMP nsPK11Token::Login(PRBool force)". "setPassword()" method should be called for token without CKF_PROTECTED_AUTHENTICATION_PATH flag only.

---- cut ----
/* void logout (in boolean force); */
NS_IMETHODIMP 
nsPK11Token::Login(PRBool force)
{
  nsNSSShutDownPreventionLock locker;
  if (isAlreadyShutDown())
    return NS_ERROR_NOT_AVAILABLE;

  nsresult rv;
  SECStatus srv;
  PRBool test;
  rv = this->NeedsLogin(&test);
  if (NS_FAILED(rv)) return rv;
  if (test && force) {
    rv = this->LogoutSimple();
    if (NS_FAILED(rv)) return rv;
  }
  rv = setPassword(mSlot, mUIContext);
  if (NS_FAILED(rv)) return rv;
  srv = PK11_Authenticate(mSlot, PR_TRUE, mUIContext);
  return (srv == SECSuccess) ? NS_OK : NS_ERROR_FAILURE;
}
---- cut ----
I believe the reason for this call to the function that requests a PIN 
is to tell the user "Hey, go do something with your PIN pad now".
Otherwise, the user has no indication that the program is waiting for 
him to enter his pin.  

IIRC, at one time, the browser displayed a different prompt than the 
usual PIN prompt in this case.  It said something like "press enter
here, then enter your PIN on your device's PIN pad."  

In any case, I'm pretty sure that it doesn't actually pay any attention
to what you enter in the window at the software prompt.  You don't have
to enter your PIN there.  You could just enter "x".
Assignee: nobody → kengert
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: libraries
Summary: The PIN code is required for PKCS#11 token with CKF_PROTECTED_AUTHENTICATION_PATH support → User prompted for PIN for PKCS#11 token with CKF_PROTECTED_AUTHENTICATION_PATH support
You are absolutely right – current implementation does not mean that PINpad is not functioning at all. I have reported this ugly behavior because I would like for Moziila based applications to work smoothly and to be as much user friendly as possible. Regarding technical ideas – I think, that it would be better to implement separate thread to show dialog with information about PINpad. This thread should wait for the end of authentication process. Similar solution we have in our smartcard middleware (CSP) and smart card management software. I think, that such approach is convenient and user friendly - and of course does not mislead users.
Kai,

There was a bug and a patch that fixed this issue a number of years ago, did that patch ever get applied?

We should try to get some protected pin path devices. This complaint has been around for a while.

bob
Two older bugs about this problem have been marked resolved/fixed, 
but the problem remains.  They are bug 110062 and bug 119500.
Both bugs are now 5+ years old.

They were originally a pair of bugs, one for NSS and one for PSM,
but the PSM bug got transformed into an NSS bug, and it seems that 
the PSM part may never have been done.  :(
Depends on: 110062, 119500, 282437
QA Contact: psm
(In reply to comment #3)
> Kai,
> 
> There was a bug and a patch that fixed this issue a number of years ago, did
> that patch ever get applied?

Nelson just pointed me to 119500.
I had not done any work on that bug yet.
I just tried to update the patch to work with current trunk, please see bug 119500.


> We should try to get some protected pin path devices. This complaint has been
> around for a while.

I guess we can not test the patch without such devices?
(In reply to comment #4)
> Two older bugs about this problem have been marked resolved/fixed, 
> but the problem remains.  They are bug 110062 and bug 119500.
> Both bugs are now 5+ years old.
> 
> They were originally a pair of bugs, one for NSS and one for PSM,
> but the PSM bug got transformed into an NSS bug, and it seems that 
> the PSM part may never have been done.  :(

Now that the PSM bug 119500 got reopened. I propose to mark this bug as a duplicate of bug 119500.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.