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. > > AlonI 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
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
On Fri, Jun 17, 2016 at 9:04 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:> 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.>> 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
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