Re: Mikes request that we identify an upper limit on the number of digits

Comments inline




I've been following the discussion in the minutes and online as much as possible. It appears to me that there are a number of problems with requiring this SC.


* It's very hard to do in a secure way
LS: there are lots of ways to do this securely. such as a securty app with rc code (used by the EU commission) two step authentication with Bluetooth such as https://saaspass.com/about/bluetooth-ble-two-factor-authentication.html,
conforming to Web Authentication: An API for accessing Public Key Credentials, with biometics or a token or token CRM being allowed options. 


* There is a lack of maturity of methods available, and lack of implementation support
LS: there are thousands of conforming sites. examples of conforming sites That I use only yesterday include:  the w3c and the EU site for research funding which allows multiple log in methods, all of which have high level of security (and a dating site that I would rather not disclose ...). ANyway...Please let me know how many sites examples you need to put your mind at rest on this and we will find them for you.


* It is a requirement for security departments and they don't tend to have a lot of flexibility when it comes to accommodations that interfere with security.
ANy level of security can be reached. including use of tokens and dongles , smartcards etc. 


* There is not a lot of evidence of threshold levels of characters to copy, which would be acceptable to people with disabilities.
LS: we had no intention of setting a threshold levels. this is Mikes Gowers proposal, but yes, we do not have a number we are happy with for his proposal. however our working assumption is this will always exclude people so why go in this direction? My experience of disabilities such as dementia is that trouble will start at 2 or 3 digits, for people who can still use sites like youtube or netflixs so researching this proposal doesnt really appeal to me unless there is a strong consensus to go here. 


* Practically speaking, if a user cannot copy a 5 digit code, would they be able to use a mainstream website, such as a news site etc...
LS: Well I often mess up 5 digit codes and I can use sites . Other task force members report similar effect


LS: the issue with copping discussed in https://www.w3.org/TR/coga-user-research/in different user groups.  We will also give the issue paper on https://w3c.github.io/coga/issue-papers/privacy-security.html 




Cheers,
David MacDonald
 
CanAdapt Solutions Inc..
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
http://www.can-adapt.com/
  
  Adapting the web to all users
            Including those with disabilities


If you are not the intended recipient, please review our privacy policy






 
On Tue, Nov 28, 2017 at 5:02 AM, Alastair Campbell <acampbell@nomensa.com> wrote:
   Hi Lisa,
  
 In this case I think showing the feasibility is more important. Mike might disagree, but it would certainly make the requirements easier to sell if there were one or two simple solutions.
  
 I think there are 3 main scenarios that cover a good range of situations for web content. It has been difficult to work out what should/would work as those questions generate a lot of possibilities, and then we go in circles about what works or doesn’t. I know the SC is asking for ‘alternatives’ to the standard, but there still have to be ways to implement these alternatives, and that is not clear yet.
  
 If we can show a reasonable method of implementation for these 3, it will go a long way to putting people at ease. 
  
 Here’s what I’ve worked out so far, the main questions start with an asterisk (*):
  
  A site that currently does a simple username/password.
  
 My understanding is that an email-reset works for this scenario. Ideally it would auto-log you in from the link in the email, but at a minimum you set a new password (even if you never intend to save it) and can login. 
  
 * Is the intent that the email reset logs you in automatically? A typical implementation would have you copy the new password into a username/password form to login.
  
  
  A site that does username/password plus a second factor, such as an app that generates a 6 digit number every 30 seconds (like  Google Auth).
  
 I assume that transferring 6 digits across from a phone app to your computer with a time-limit is a big problem, but is there a feasible alternative? (You can put SMS methods in this category as well, although  they are considered less secure.)
  
 For hardware / biometrics, the only standards based way to enable that on a website (that I know of) is the  Web Authentication JavaScript API to a “Universal Second Factor” (based on  FIDO I think). We shouldn’t worry about the hardware side as there are many possibilities, but we do need to worry about whether they work with browsers.
  
 The current browser support is Chrome-only, and that is desktop-only as the U2F devices generally use USB.
  
 * Is there another way that I’m missing? Otherwise I can’t see how we could get 2 implementations (which is probably why WebAuth is still in draft).
  
 Also, how do you get past the username/password bit? You can set the second factor to remember your device for a set time (usually 30 days), but at some point you would still have to login with a password and with the 2nd factor, otherwise there is no security.
  
  
  A site like scenario 2 (username/password + 2FA), but provides your email so you can’t use a email-reset loop.
  
 E.g. if you are logging into Gmail / Outlook (web), this is another level of complexity on scenario 2.
  
 So it has all the issues from scenario 2, but with the added complication that you cannot rely on an email-reset loop.
  
 * I can’t see any solution to this one, so perhaps that would need an exception?
  
 Overall:
 I think answering the scenarios here would cover these comments on github: 354, 440, 441, 473, 503, 542, 553.
 If we can work it out, I’ll put in the responses.
  
 However, it appears to me that the implementations (in the browsers) are not ready yet, and it should be delayed until that changes.
  
 Kind regards,
  
 -Alastair