ssh-pkcs11.c

[Jakub Jelen]

On 07/25/2016 09:38 AM, Alon Bar-Lev wrote:
> 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

> On 25 July 2016 at 09:56, Nuno Gonçalves <nunojpg at gmail.com> wrote:
>> 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
>>
>> On Fri, Jun 17, 2016 at 10:04 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>>> On 17 June 2016 at 22:45, Nuno Gonçalves <nunojpg at gmail.com> wrote:
>>>> On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>>>>> On 17 June 2016 at 20:58, Nuno Gonçalves <nunojpg at gmail.com> wrote:
>>>>>> 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.
>>>
>>>> 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
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat