Re: Next steps for accessible authentication

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