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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
On 17 June 2016 at 22:45, Nuno Gonçalves <nunojpg@xxxxxxxxx> wrote:
On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev <alon.barlev@xxxxxxxxx> wrote:
On 17 June 2016 at 20:58, Nuno Gonçalves <nunojpg@xxxxxxxxx> 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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
