Re: Next steps for accessible authentication

Hi Janina,

I think we are in agreement, but discussing different perspectives.

I'll attempt a visual metaphor here, as a means to illustrate my concern.

As I read Lisa's comment, I visualize a single slider widget, with security
on the left, and ease-of-use on the right (imagine a left-right panning
slider), based upon this comment: "People will need to take the security
alternative that give the right balance between security and easy of
implementation for their scenario." - with a focus on the word *balance*.

In actual fact, I believe the correct visual metaphor is that there are
*two* sliders - one for security, the other for ease of use, with each
horizontal slider ranging from "minimal" to "maximum". The goal as I
understand it is to move the ease-of-use slider to a place that
accommodates as many users as possible - however we cannot move the
security slider in a direction that would make the application "easier" to
use at the cost of security, which is how I am reading Lisa's comment
today.

There cannot be a trade-off here, the requirements (accessibility *AND*
security) need to be kept separate.

Lisa then wrote:

> What I said was people will pick the alternative based on their scenario
and security needs.

Hi Lisa,

I'm not sure who you mean by "people" - authors or end users?
​

End users today have no choice but to use the method(s) provided by the
authors, and I am hard-pressed to find a content author who today is
choosing an authentication scheme that is harder than it needs to be, just
for the sake of making it harder​: in fact many banking sites I know of
here in the US are now also offering software tokens and bio-metric
 alternatives
​
​
already
​
(fingerprint on cell devices)
​
, despite the fact that those "solutions" still leave some users out in the
cold.

JF

On Tue, Jun 20, 2017 at 10:14 AM, Janina Sajka <janina@rednote.net> wrote:

> 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
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion