Discussion:
ssh-pkcs11.c
(too old to reply)
Nuno Gonçalves
2016-06-17 17:58:40 UTC
Permalink
Hi,

It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.

This is caused at pkcs11_rsa_private_encrypt:

snprintf(prompt, sizeof(prompt),
"Enter PIN for '%s': ", si->token.label);
pin = read_passphrase(prompt, RP_ALLOW_EOF);
if (pin == NULL)
return (-1); /* bail out */

Actually a zero-length PIN will not cause a NULL to be returned, so it
will still try to authenticate and fail the PIN login!

Also, I think it would be great to support the CKF_* flags to provide
some feedback to the user regarding PIN tries left remaining,
something like this:

if (info.flags & CKF_USER_PIN_COUNT_LOW)
printf("WARNING: User PIN count low\n");
else if (info.flags & CKF_USER_PIN_FINAL_TRY)
printf("WARNING: User PIN final try\n");
else if (info.flags & CKF_USER_PIN_LOCKED) /* Maybe we should bail out
here, or just try to continue? */
printf("WARNING: User PIN reported locked\n");

Thanks,
Nuno
Alon Bar-Lev
2016-06-17 18:57:59 UTC
Permalink
Post by Nuno Gonçalves
Hi,
It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.
Hi,

Empty PIN is valid case, not sure why you want to avoid supporting it.

Alon
Nuno Gonçalves
2016-06-17 19:45:12 UTC
Permalink
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Hi,
It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.
Hi,
Empty PIN is valid case, not sure why you want to avoid supporting it.
Alon
I didn't know it was valid but the reasoning still applies. I don't
really know the standard use cases, but I think it could eventually be
useful for the user, when asked for the PIN, to decide not enter it.
Currently it can only be done by killing ssh. If empty PIN is valid,
but eventually not usual, maybe we should ask if the user really wants
to try a empty pin or just continue to another authentication option?


Regarding the CKF_USER_PIN flags, do you think it is a good idea to
implement the warning messages?

Thanks,
Nuno
Alon Bar-Lev
2016-06-17 20:04:21 UTC
Permalink
Post by Nuno Gonçalves
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Hi,
It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.
Hi,
Empty PIN is valid case, not sure why you want to avoid supporting it.
Alon
I didn't know it was valid but the reasoning still applies. I don't
really know the standard use cases, but I think it could eventually be
useful for the user, when asked for the PIN, to decide not enter it.
Currently it can only be done by killing ssh. If empty PIN is valid,
but eventually not usual, maybe we should ask if the user really wants
to try a empty pin or just continue to another authentication option?
Not sure what best solution, but ignoring empty PIN is the same as
ignoring "cancel" or similar constants, which is more explicit.
What's wrong with plain <Ctrl>-C, as without PIN there is no use to
continue session anyway.
Post by Nuno Gonçalves
Regarding the CKF_USER_PIN flags, do you think it is a good idea to
implement the warning messages?
Most implementations do not support these.

Regards,
Alon
Nuno Gonçalves
2016-06-17 20:09:55 UTC
Permalink
Post by Alon Bar-Lev
Not sure what best solution, but ignoring empty PIN is the same as
ignoring "cancel" or similar constants, which is more explicit.
What's wrong with plain <Ctrl>-C, as without PIN there is no use to
continue session anyway.
The session could continue with other publickey auth or even password,
that could be asked after. Anyway I was confuses by the behaviour as a
user, such that it eventually locked my card. I agree there is no
clear cut solution, so I'll just live with it as it is.
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Regarding the CKF_USER_PIN flags, do you think it is a good idea to
implement the warning messages?
OpenSC does. I have no idea what is the OpenSC quota for ssh users.
Anyway the libraries can be waiting for the clients to support it!
I'll provide a patch and hope it is acceptable.

Thanks for the replies!

Nuno
Nuno Gonçalves
2016-07-25 06:56:01 UTC
Permalink
Hi Alon,

I confirmed with pkcs11-tool (from OpenSC) and I can confirm that
pressing return when asked for the pin causes the login to stop (and
not to try a empty pin).

Can you confirm if a empty pin is actually a valid pin, and if not,
can the patch be accepted?

Once again, the problem is that from a user experience, *some/most*
users would expect they can skip pkcs11 token authentication just by
pressing return and trying then other authentication method, like
password.

But currently that is not what happens, and users can find out too
late that they have instead tried a wrong pin too many times and
locked their token...

Regards,
Nuno
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Hi,
It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.
Hi,
Empty PIN is valid case, not sure why you want to avoid supporting it.
Alon
I didn't know it was valid but the reasoning still applies. I don't
really know the standard use cases, but I think it could eventually be
useful for the user, when asked for the PIN, to decide not enter it.
Currently it can only be done by killing ssh. If empty PIN is valid,
but eventually not usual, maybe we should ask if the user really wants
to try a empty pin or just continue to another authentication option?
Not sure what best solution, but ignoring empty PIN is the same as
ignoring "cancel" or similar constants, which is more explicit.
What's wrong with plain <Ctrl>-C, as without PIN there is no use to
continue session anyway.
Post by Nuno Gonçalves
Regarding the CKF_USER_PIN flags, do you think it is a good idea to
implement the warning messages?
Most implementations do not support these.
Regards,
Alon
Alon Bar-Lev
2016-07-25 07:38:33 UTC
Permalink
Hi,

I am not the maintainer of openssh pkcs11 module, so I cannot accept anything :)

However, I do believe that empty PIN is a valid PIN in PKCS#11 spec.

Regards,
Alon
Post by Nuno Gonçalves
Hi Alon,
I confirmed with pkcs11-tool (from OpenSC) and I can confirm that
pressing return when asked for the pin causes the login to stop (and
not to try a empty pin).
Can you confirm if a empty pin is actually a valid pin, and if not,
can the patch be accepted?
Once again, the problem is that from a user experience, *some/most*
users would expect they can skip pkcs11 token authentication just by
pressing return and trying then other authentication method, like
password.
But currently that is not what happens, and users can find out too
late that they have instead tried a wrong pin too many times and
locked their token...
Regards,
Nuno
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Hi,
It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.
Hi,
Empty PIN is valid case, not sure why you want to avoid supporting it.
Alon
I didn't know it was valid but the reasoning still applies. I don't
really know the standard use cases, but I think it could eventually be
useful for the user, when asked for the PIN, to decide not enter it.
Currently it can only be done by killing ssh. If empty PIN is valid,
but eventually not usual, maybe we should ask if the user really wants
to try a empty pin or just continue to another authentication option?
Not sure what best solution, but ignoring empty PIN is the same as
ignoring "cancel" or similar constants, which is more explicit.
What's wrong with plain <Ctrl>-C, as without PIN there is no use to
continue session anyway.
Post by Nuno Gonçalves
Regarding the CKF_USER_PIN flags, do you think it is a good idea to
implement the warning messages?
Most implementations do not support these.
Regards,
Alon
Jakub Jelen
2016-07-25 11:22:29 UTC
Permalink
Post by Alon Bar-Lev
Hi,
I am not the maintainer of openssh pkcs11 module, so I cannot accept anything :)
However, I do believe that empty PIN is a valid PIN in PKCS#11 spec.
PKCS#11 tokens provide ulMinPinLen and ulMaxPinLen fields. So the
enforced length is token-specific [1] and nothing what would be enforced
by the specification.

[1] http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Hi Alon,
I confirmed with pkcs11-tool (from OpenSC) and I can confirm that
pressing return when asked for the pin causes the login to stop (and
not to try a empty pin).
Can you confirm if a empty pin is actually a valid pin, and if not,
can the patch be accepted?
Once again, the problem is that from a user experience, *some/most*
users would expect they can skip pkcs11 token authentication just by
pressing return and trying then other authentication method, like
password.
But currently that is not what happens, and users can find out too
late that they have instead tried a wrong pin too many times and
locked their token...
Regards,
Nuno
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Hi,
It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.
Hi,
Empty PIN is valid case, not sure why you want to avoid supporting it.
Alon
I didn't know it was valid but the reasoning still applies. I don't
really know the standard use cases, but I think it could eventually be
useful for the user, when asked for the PIN, to decide not enter it.
Currently it can only be done by killing ssh. If empty PIN is valid,
but eventually not usual, maybe we should ask if the user really wants
to try a empty pin or just continue to another authentication option?
Not sure what best solution, but ignoring empty PIN is the same as
ignoring "cancel" or similar constants, which is more explicit.
What's wrong with plain <Ctrl>-C, as without PIN there is no use to
continue session anyway.
Post by Nuno Gonçalves
Regarding the CKF_USER_PIN flags, do you think it is a good idea to
implement the warning messages?
Most implementations do not support these.
Regards,
Alon
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat
Douglas E Engert
2016-07-27 14:26:00 UTC
Permalink
Post by Nuno Gonçalves
Hi Alon,
I confirmed with pkcs11-tool (from OpenSC) and I can confirm that
pressing return when asked for the pin causes the login to stop (and
not to try a empty pin).
Can you confirm if a empty pin is actually a valid pin, and if not,
can the patch be accepted?
By Empty pin do you mean pPin != NULL && ulPinLen = 0 or do you mean pPin == NULL?

If the card supports CKF_PROTECTED_AUTHENTICATION_PATH (may have a pin pad reader) , the a call to C_Login with pPin = NULL wil use the pin pad reader.

Without CKF_PROTECTED_AUTHENTICATION_PATH I would find it strange if a card would allow a zero length pin. If no pin is needed a C_Login would not be required either the CKS_RO_PUBLIC_SESSION would
work and the key one wants to use does not require PIN protection. (Does SSH check if the key requires the PIN?)

What return code does C_Login return if you try and use an "empty pin"?
Post by Nuno Gonçalves
Once again, the problem is that from a user experience, *some/most*
users would expect they can skip pkcs11 token authentication just by
pressing return and trying then other authentication method, like
password.
But currently that is not what happens, and users can find out too
late that they have instead tried a wrong pin too many times and
locked their token...
Regards,
Nuno
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Post by Alon Bar-Lev
Post by Nuno Gonçalves
Hi,
It seems there is a bug with the pkcs11 feature where a zero-length
PIN is accepted. I believe this is a bug, since the user might want to
press return when asked for the PIN to ignore that slot/key.
Hi,
Empty PIN is valid case, not sure why you want to avoid supporting it.
Alon
I didn't know it was valid but the reasoning still applies. I don't
really know the standard use cases, but I think it could eventually be
useful for the user, when asked for the PIN, to decide not enter it.
Currently it can only be done by killing ssh. If empty PIN is valid,
but eventually not usual, maybe we should ask if the user really wants
to try a empty pin or just continue to another authentication option?
Not sure what best solution, but ignoring empty PIN is the same as
ignoring "cancel" or similar constants, which is more explicit.
What's wrong with plain <Ctrl>-C, as without PIN there is no use to
continue session anyway.
Post by Nuno Gonçalves
Regarding the CKF_USER_PIN flags, do you think it is a good idea to
implement the warning messages?
Most implementations do not support these.
Regards,
Alon
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Douglas E. Engert <***@gmail.com>
Nuno Gonçalves
2016-07-28 08:25:31 UTC
Permalink
Post by Jakub Jelen
PKCS#11 tokens provide ulMinPinLen and ulMaxPinLen fields. So the
enforced length is token-specific [1] and nothing what would be enforced by
the specification.
Thanks for the info. And do you have any idea if the special case or a
0-length pin is acceptable/used in any application?

Thanks,
Nuno

Loading...