Re: Next steps for accessible authentication

John:

I have to disagree with you.

When APA met with the Web Authentication Working Group during TPAC in
Lisbon, perhaps the key point the security folks wanted us to understand
is that every login attempt is evaluated against some scale of
confidence. They do not think in terms of 100% confident, or the
opposite. It's always some kind of inbetween level based on whatever
factors they use, how the data appears (e.g. what IP it comes from),
etc.

Some sites will have stricter confidence requirements, others not so
much.


hth

Janina


John Foliot writes:
> Lisa wrote:
> 
> > People will need to take the security alternative that give the right
> balance between security and easy of implementation for their scenario.
> 
> Hi Lisa,
> 
> With respect, I think this may be part of the problem
> ​.
> 
> When I read what you just wrote, it appears to indicate that you believe
> there is a trade-off possible here between accessibility and security -
> that there is a balance question here that needs to be addressed at scale.
> 
> There isn't such a balance, and I strongly suspect that at some level there
> never will be, certainly not for high-security ​situations such as banking
> and medical services (to name two critical / high-security situations). The
> closer we get to "ease of implementation", the easier it becomes to spoof
> or automate (hack) the required authentication task, which then weakens the
> security, not only for the individual user, but perhaps of an entire system
> - which no high-security application will accept at any cost.
> 
> I can appreciate that this isn't a great answer, but it remains part of our
> larger problem. That is one of the reasons why I have previously asked
> about splitting this into 2 SC - one for low-security needs (for example
> commenting on a blog) versus high-security needs (doing my banking online).
> We've previously drawn that distinction before, with SC #
> 3.3.4 Error Prevention (Legal, Financial, Data)
> ​ - https://www.w3.org/TR/WCAG20/#minimize-error-reversible and thinking
> about the problem statement at two levels of security requirements may help
> us achieve something here, if not all that you seem to be asking for now.
> 
> 
> > they have been reviewed by security experts
> 
> This is interesting, have you shared that feedback with the larger group?
> ​
> (I apologize in advance if yes, and I missed it).
> ​ If not, could you do so please?​
> 
> 
> 
> Meanwhile, Jason wrote:
> 
> > It’s clear that...
> ​
> we need more secure, and less demanding, authentication mechanisms.
> 
> ​Amen. This need transcends persons with disabilities however, even if or
> when the impact is more significant to specific user-groups.
> 
> "Passwords" alone have proven too brittle and fragile for any number of
> reasons, including some of the issues this SC is attempting to address.
> Unfortunately, some of the brightest minds on the planet, at companies
> ranging from Google, Amazon, and IBM, to Microsoft, Apple, Facebook and
> more (and I didn't even mention high-security players like the banking
> industry, who trust me are all over this as well) have still not come up
> with an​ equitable solution that addresses all of these known problems.
> 
> In the case of browsers, the best they have managed to offer us to date
> appears to be built-in password managers inside of the browser, which also
> raises a question: if a password manager "remembers" a password, which
> presumably takes a lot of pressure off of the end user with short-term
> memory issues, then does that (the PW manager) meet the functional
> requirement(s)? How do we as evaluators then test for that? How do we even
> take that into account when drafting the normative SC language?
> 
> Research and experience confirms that this is a serious problem - and I can
> appreciate that for the COGA TF this was likely one of the more critical
> concerns looking to be addressed. However, given the backdrop and current
> state of technology today, I cannot see this SC succeeding as written
> today, at least not without addressing the high-security scenario at a
> minimum.
> 
> And for that I am saddened.
> 
> JF
> 
> 
> On Mon, Jun 19, 2017 at 1:23 PM, Gregg C Vanderheiden <greggvan@umd.edu>
> wrote:
> 
> > +1 to Jason’s concern about security of these.  Have they been vetted by a
> > security specialist?
> >
> >
> > Also — are these supposed to be easier than copying something ?
> >
> > All of these appear to be cognitively much more complicated than copying
> > information from one place into the field.   As such - is this something
> > where the solution requires more cognitive skills than the problem?
> >
> > Has anyone demonstrated that someone who cannot copy information — can do
> > any/all of these?     That these are indeed simpler?
> >
> > If not - then is there any grounds for assuming that any of these will
> > reduce the cognitive demands on a person…..
> >
> > These all sound complicated to me….
> >
> > *g*
> >
> > Gregg C Vanderheiden
> > greggvan@umd.edu
> >
> >
> >
> >
> > On Jun 19, 2017, at 1:48 PM, White, Jason J <jjwhite@ets.org> wrote:
> >
> >
> >
> > *From:* lisa.seeman [mailto:lisa.seeman@zoho.com <lisa.seeman@zoho.com>]
> > *Sent:* Monday, June 19, 2017 1:30 PM
> >
> > We are allowing multiple alternatives, such as:
> >
> >    -  two step authentication that has a link to press as an alternative
> >    to entering a code
> >
> > *[Jason] What are the security implications, if any? The server comprising
> > the destination of the link could be attacked (e.g., by trying different
> > values for the data carried in the link in succession).*
> >
> >    -  two step authentication using devices that sends a tokens via
> >    Bluetooth
> >
> > *[Jason] These are promising as an idea, but without standardization, the
> > user may end up having to use several different devices with different Web
> > sites – not a desirable outcome. I think these could only be required in
> > WCAG when the standards are in place.*
> >
> >    -  Email resetting is an option for most places,  including google if
> >    people have an alternative address
> >
> > *[Jason] This isn’t suitable for high security applications, since anyone
> > who gains access to the e-mail account can compromise the security of the
> > system.*
> >
> >    - login in via something like facbook
> >
> > *[Jason] This involves trusting/relying on a third party to perform the
> > authentication. If I remember correctly, this is known to have serious
> > security shortcomings.*
> >
> >    - conformance to the web authentification specification at
> >    https://www.w3.org/TR/webauthn/ <https://www.w3.org/TR/webauthn/>
> >
> > *[Jason] This is the most promising of your alternatives. Will it be
> > practically available by the time WCAG 2.1 enters Candidate Recommendation?*
> >
> > In short, I think most of the options are at least suspect from a security
> > point of view.
> >
> >
> > ------------------------------
> >
> > This e-mail and any files transmitted with it may contain privileged or
> > confidential information. It is solely for use by the individual for whom
> > it is intended, even if addressed incorrectly. If you received this e-mail
> > in error, please notify the sender; do not disclose, copy, distribute, or
> > take any action in reliance on the contents of this information; and delete
> > it from your system. Any other use of this e-mail is prohibited.
> >
> > Thank you for your compliance.
> >
> >
> >
> 
> 
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
> 
> Advancing the mission of digital accessibility and inclusion

-- 

Janina Sajka, Phone: +1.443.300.2200
   sip:janina@asterisk.rednote.net
  Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Tuesday, 20 June 2017 15:21:50 UTC