#4: Fails to set PAM_AUTHTOK correctly

Andreas, hi,
[please Cc me on replies]

Andreas Jellinghaus wrote:
> thanks. I think smart card pins are too important to be
passed to other
> modules. so I removed that code completely.
I have to disagree here. Smart card pins are indeed
sensitive but I
think that PAM is trustworthy enough to handle it.
After all, it handles plain user passwords -even root's- on
pretty much
every Unix system. And passwords are *more* sensitive than
PINs because
they are sufficient for authentication, without the barrier
of
"what-you-have" that a smart card provides.
pam_unix and almost every PAM module out there save the
authentication
token so subsequent modules can read it. I really can't see
the reason
why pam_p11 should be an exception.

Passing the authentication token may be useful in certain
scenarios.
Think for example a situation when you want to decrypt
something (e.g. a
file or even your ~) when logging in. Prompting *twice* (or
more!) for
the PIN is user unfriendly -- not to mention security
implications.
Moreover, such a security "measure" is easy to
work-around -- you can
have another pam module to do the conversation and pass the
token to
pam-p11 for authentication.

Granted, this code hasn't been used -it was buggy and I'm
the first who
noticed- but that doesn't mean it shouldn't be there in the
first place.

I really hope you'll reconsider since I'm already using the
feature.

Best regards,
Faidon
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On 21.12.2006, at 0:25, Faidon Liambotis wrote:
> [please Cc me on replies]

This brings us back to the biggest problem in trying to
'instantly  
support' pinpad readers: applications (in this case pam
modules)  
think that smart cards evolved like this:

* We have a username and a password
* Now we invented RSA keys and certificates. We have a
certificate  
file with a key and a password for the key ("hey, you
do want to keep  
the key encrypted with a password, don't you?").
* developer enables the PKI part in his application and
replaces  
"username" with "path to
certificate/key" and "password" with  
"private key password". Some cases still use the
username for  
identification and PKI capabilities for authentication only.
(you  
specify a username, a path to a private key, and optionally
(if  
you're smart and security oriented) a password to decrypt
the private  
key file)
* Now we invent smart cards. The "best"
applications just don't  
support this ("how come you can't specify a file from
where to read  
the private key?"). Others support it somewhat better
and do allow  
'key references' and do a search-replace on the codebase:
"password" - 
 > "pin". The idea is 'hmm, well, our
application already supports  
all asymmetric crypto and stuff. Thus - yes we do support
smartcards,  
smartcards are like hardware based private key files, right?
So we  
rename the password to PIN, block for asking a username + a
password  
pair and then send them both 'down to the libraries dealing
with  
smartcards' like we used to send them 'down to openssl'
before to get  
the response'
* Now we invent pinpad readers (or WPKI alias keys that live
on your  
SIM card and inside your GSM phone for example) All the
historical  
knowledge is useless, as the only abstraction the
application should  
be using is 'we have a key pair somewhere and we want to do
some  
crypto operations with them. We only have references to the
keys, and  
we REALLY don't know how the access to the key is authorized
or how  
and where the signature operations happens. We only know
that calling  
this API we get a signed hash back'.

I thought about making a 'test pkcs11 module' for testing.
Which, if  
it finds an enabled pinpad, rejects all software pins. That
would be  
a great software compatibility testing utility.

The point here is: whenever you REQUIRE a PIN in your
application,  
you're probably doing something wrong. Or you must have a
really,  
really good reason for it. PIN is not like a password you
should pass  
around. Your application, if smartcard enabled, should not
in ideal  
case even have GUI elements with 'PIN' in it. The best way
to  
approach 'hardware tokens' such as smart cards is to think
about  
issues as pinpads as early as possible.

Somebody proposed a 'smart card compatibility checklist for 

'certificated' applications. I think this text deserves a
permanent  
position in the 'How to enable smart cards in your
application stack'  
guide.

-- 
Martin Paljak


_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On 21/12/06, Martin Paljak <martinpaljak.pri.ee> wrote:
> On 21.12.2006, at 0:25, Faidon Liambotis wrote:
> > [please Cc me on replies]

> The point here is: whenever you REQUIRE a PIN in your
application,
> you're probably doing something wrong. Or you must have
a really,
> really good reason for it. PIN is not like a password
you should pass
> around. Your application, if smartcard enabled, should
not in ideal
> case even have GUI elements with 'PIN' in it. The best
way to
> approach 'hardware tokens' such as smart cards is to
think about
> issues as pinpads as early as possible.

You are right Martin. But PAM was not designed with smart
cards in
mind. If PAM provides a mechanism to pass the
PIN/password/whatever to
subsequent PAM module and this feature is used we should not
disable
it just because it is not possible with a pinpad reader.

So I propose to add the "offending" code again and
let people benefit
of the feature if they want.

An improvement may be to save the PIN only if PKCS11_login()
succeeds?

bye,

-- 
  Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On 21.12.2006, at 15:04, Ludovic Rousseau wrote:
> So I propose to add the "offending" code
again and let people benefit
> of the feature if they want.
OK. But I would still like to hear about this given scenario
- why  
and how the pin is
(re-)used.

Faidon ?



-- 
Martin Paljak


_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On 21.12.2006, at 15:04, Ludovic Rousseau wrote:

> You are right Martin. But PAM was not designed with
smart cards in
> mind.

IMHO the main selling feature of PAM has been 'whenever you
want to  
upgrade to serious authentication like smartcards or
biometrics,  
you'll need PAM and you'll learn that PAM is the proper
method'.

It might be a false perception as well.

-- 
Martin Paljak


_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On Thu, 2006-12-21 at 15:50 +0200, Martin Paljak wrote:
> On 21.12.2006, at 15:04, Ludovic Rousseau wrote:
> 
> > You are right Martin. But PAM was not designed
with smart cards in
> > mind.
> 
> IMHO the main selling feature of PAM has been 'whenever
you want to  
> upgrade to serious authentication like smartcards or
biometrics,  
> you'll need PAM and you'll learn that PAM is the proper
method'.
> 
> It might be a false perception as well.
> 
Hrm.. I have just recently been following this, but PAM
doesn't require
any sort of password/etc.  Apps using PAM are supposed to
register
functions for 'conversation' for retrieving information from
the user.
So for the case of PIN reader, you just don't have your PAM
plugin ask
for the PIN.
However... many app writers assume that a password is needed
and
hard-wire that into the UI.
-- 
Thomas Harning Jr.
Authentication Engineer  Identity Alliance
http://www.trustbearer.co
m/

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

> IMHO the main selling feature of PAM has been 'whenever
you want to 
> upgrade to serious authentication like smartcards or
biometrics, you'll 
> need PAM and you'll learn that PAM is the proper
method'.

no, I think it is "reconfigure / add module in one
central place".
earlier you would have needed to change and recompile login,
sshd, xdm,
xscreenlock and other apps, and that isn't nice.

but to be honest: I think smart cards are too complex to be
handled
with pam. sure, a simple limited pam module works, but for
advanced
features a special chooser would be much nicer.

examples of advanced features:
  * list smart card readers and card status
  * let people know about the secure input led, so they
check it is on
    (i.e. with pinpad readers, make sure people enter the
pin to the
    card, and not with "INPUT" commands read by
the pc).
  * display card info like name, photo id, whatever.
  * allow people to select the account they want to login
(list thoses
    the cards is valid for - some people might see that as a
security
    issue, if it is done before authentication).
  * allow people to unblock the pin - blocked pins happen
and it is a
    problem if people can't unblock it with the puk.
  * (optional) leave the card in verified state, so network
connections,
    crypto partitions and other stuff can be used without
re-entering
    the pin.
  * lock screen if card is removed.
  * same features in xdm&friends and xlock&friends.

pam is not suited to these advanced features. but neither is
pkcs#11
I fear, nor the opensc code, not the "library
model" (as opposed to
a daemon/agent model).

back to the original issue: what can we (easily) add to the
pam_p11 
module to make max. number of users happy? please file new
tickets.
will try to implement (mostly as options).

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Faidon Liambotis wrote:
> Andreas, hi,
> [please Cc me on replies]
> 
> Andreas Jellinghaus wrote:
>> thanks. I think smart card pins are too important
to be passed to other
>> modules. so I removed that code completely.
> I have to disagree here. Smart card pins are indeed
sensitive but I
> think that PAM is trustworthy enough to handle it.

this is irrelevant. PINs, like all sensitive information,
should
be handled on a need-to-know basis. So the question is not
if
pam is trustworthy enough or not, the question is: do other
pam
modules really need to know the PIN.

> Passing the authentication token may be useful in
certain scenarios.
> Think for example a situation when you want to decrypt
something (e.g. a
> file or even your ~) when logging in. Prompting *twice*
(or more!) for
> the PIN is user unfriendly -- not to mention security
implications.

well most cards let you do as many private key operations as
you like
if this has been specified in the card profile (well, this
of course
requires that the card won't be reseted ...).
If the card explicitly requires a PIN verification before
each operation
caching the PIN is not a good idea and you should perhaps
use another
card (profile).

> I really hope you'll reconsider since I'm already using
the feature.

how do you use it ?

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel