Caching PIN

Caching PIN

Hi,

I am wondering if there is a specific call made to a CSP when a card
is removed from the reader?

I need to know when the card is removed from the reader in order to
invalidate the cached PIN.

Also, can somebody give me a hint how I can obtain the logonID which
is supposed to be associated with every cached PIN? Should it be
unique for a given thread or a process? I've had troubles making it
unique for a thread since multiple threads (2) refer to one token and
the cached PIN is considered valid for only one of them.

Thanks,
Marek

date: Tue, 10 Jun 2008 05:33:34 -0700 (PDT) author: unknown

RE: Caching PIN

Hi Marek,

There is no such a CSP call when a card is removed. It is the code inside 
the CSP who is responsible for managing the smart cards states and deals with 
there events accordingly. For example, if you try to use a SCARDHANDLE of a 
card that has been removed and inserted back, you'll get the error 
SCARD_W_REMOVED_CARD. In this case you should invalidate your cache and 
reconnect to the card.
For your last question, it appears to me that it's very specific to your 
implementation. 

Cheers,
-- 
Mounir IDRASSI
IDRIX
http://www.idrix.fr

to reach : mounir_idrix_fr (replace the underscores with the at and dot 
characters respectively)

"m.pawlak@wasko.pl" wrote:

> Hi,
> 
> I am wondering if there is a specific call made to a CSP when a card
> is removed from the reader?
> 
> I need to know when the card is removed from the reader in order to
> invalidate the cached PIN.
> 
> Also, can somebody give me a hint how I can obtain the logonID which
> is supposed to be associated with every cached PIN? Should it be
> unique for a given thread or a process? I've had troubles making it
> unique for a thread since multiple threads (2) refer to one token and
> the cached PIN is considered valid for only one of them.
> 
> Thanks,
> Marek
>

date: Tue, 10 Jun 2008 06:09:02 -0700 author: Mounir IDRASSI am

Re: Caching PIN

Hi Mounir,

> For your last question, it appears to me that it's very specific to your
> implementation.

Microsoft's CSP Cookbook (http://msdn.microsoft.com/en-us/library/
ms953432.aspx) says: "The PIN should be stored internally within the
CSP per process." So it appears to me that at some point every CSP
needs to address this problem and identify the process. I am just
wondering if using the id obtained for GetCurrentProcessId() is a good
approach.

Cheers,
Marek

date: Tue, 10 Jun 2008 23:20:53 -0700 (PDT) author: unknown

Re: Caching PIN

Hi Marek,

The usual approach taken by smart card CSP's implementors is to cache the 
PIN in the context of the CSP dll, thus you don't need to care about the 
process ID or what ever because each process will load its own copy of the 
CSP dll. Personally, in the CSP's I have developed in the past where the PIN 
is cached, I had a list of available readers on the system and the PIN is 
cached for each reader.
From what you write, I understand that you will have some sort of global 
repository on the system for cached PIN (like a service) and that you need 
the process ID to identify which PIN belongs to which process. In my opinion, 
 this is not a good approach and it is useless. I advice you to consider the 
way I explained in the begining of this message, thus you will not have to 
care about the process ID.

Cheers,
-- 
Mounir IDRASSI
IDRIX
http://www.idrix.fr

to reach : mounir_idrix_fr (replace the underscores with the at and dot 
characters respectively)

"m.pawlak@wasko.pl" wrote:

> Hi Mounir,
> 
> > For your last question, it appears to me that it's very specific to your
> > implementation.
> 
> Microsoft's CSP Cookbook (http://msdn.microsoft.com/en-us/library/
> ms953432.aspx) says: "The PIN should be stored internally within the
> CSP per process." So it appears to me that at some point every CSP
> needs to address this problem and identify the process. I am just
> wondering if using the id obtained for GetCurrentProcessId() is a good
> approach.
> 
> Cheers,
> Marek
> 
>

date: Wed, 11 Jun 2008 01:53:01 -0700 author: Mounir IDRASSI am

Re: Caching PIN

I think I will move to the type of solution you suggested. Thank you.

Marek

date: Thu, 12 Jun 2008 01:27:38 -0700 (PDT) author: unknown

Re: Caching PIN

Hi,
Is it possible to know the smart card module associated with a card 
identified by an ATR string?

I know how a CSP name associated with a card be identified.But after getting 
the CSP ,is it possible to just verify the PIN alone ?If yes,could you please 
outline how can I do that?

Thanks in advance
-- 
-Novice
"To unlearn is to learn"


"Mounir IDRASSI" wrote:

> Hi Marek,
> 
> The usual approach taken by smart card CSP's implementors is to cache the 
> PIN in the context of the CSP dll, thus you don't need to care about the 
> process ID or what ever because each process will load its own copy of the 
> CSP dll. Personally, in the CSP's I have developed in the past where the PIN 
> is cached, I had a list of available readers on the system and the PIN is 
> cached for each reader.
> From what you write, I understand that you will have some sort of global 
> repository on the system for cached PIN (like a service) and that you need 
> the process ID to identify which PIN belongs to which process. In my opinion, 
>  this is not a good approach and it is useless. I advice you to consider the 
> way I explained in the begining of this message, thus you will not have to 
> care about the process ID.
> 
> Cheers,
> -- 
> Mounir IDRASSI
> IDRIX
> http://www.idrix.fr
> 
> to reach : mounir_idrix_fr (replace the underscores with the at and dot 
> characters respectively)
> 
> 
> "m.pawlak@wasko.pl" wrote:
> 
> > Hi Mounir,
> > 
> > > For your last question, it appears to me that it's very specific to your
> > > implementation.
> > 
> > Microsoft's CSP Cookbook (http://msdn.microsoft.com/en-us/library/
> > ms953432.aspx) says: "The PIN should be stored internally within the
> > CSP per process." So it appears to me that at some point every CSP
> > needs to address this problem and identify the process. I am just
> > wondering if using the id obtained for GetCurrentProcessId() is a good
> > approach.
> > 
> > Cheers,
> > Marek
> > 
> >

date: Tue, 26 Aug 2008 12:46:02 -0700 author: Novice