Two-factor auth for social service clients

[daguar]

BLUF: 2-factor authentication (e.g., you receive a text message with a code when you try to log in) may well be both (a) more secure and (b) more usable for social service clients than the status quo (hard-to-remember security questions, difficult registration processes involving email which many people don't have.) We should test to see if this is true.

Project Needs:

• Usability lit review (one article here: http://arxiv.org/pdf/1309.5344.pdf )
• Tiny prototype for user testing
• Hands-on user testing of a prototype with real social service clients (preferably comparison-based against existing online systems)

Status: discovery/idea/exploratory

Other details: This is mostly a stub — more to come. The hunch is this: from understanding our users to-date, receiving a text or phone call will be easier than the status quo (security questions, registration processes.) This could potentially be a generalizable pattern across government services.

cc @cydharrell @konklone

[Raseman]

Important and really difficult problem. Another avenue to consider: cities and other entities as ID verifiers. Some cities have created ID cards, for examples. (http://www.cityofnewhaven.com/csa/newhavenresidents/). This could be an important component of solutions for populations who do not have cell phones.

[yesezra]

Do you want to add a second factor for auth (i.e. email + sms token) or just replace email with a better first factor (email => sms token)?

[daguar]

...or just replace email with a better first factor (email => sms token)?

I think you've hit the nail on the head @ahhrrr. I think I was using 2-factor auth too loosely when I really meant "better factors" (which is a harder thing, I think, for folks to understand — 2FA they have often experienced already as "oh! that text thing")

But yeah! I totally think this is what I'm getting at: can we have a factor that somehow improves usability with minimal/no security sacrifice relative to the status quo?

(Other good question to ask: what are the risks of a breach? If they are very low, what's the optimal minimal barrier?)

[konklone]

I know some places are moving to "passwordless" systems, where they essentially use the "reset password" workflow as the sole login path. So, put in your email, click the email you get sent to log in.

I think a device as the only factor would also be a big improvement, if your users are prepared and suited for that. On non-smartphones, that's SMS -- for smartphones, Google Authenticator or Authy are better options (though offering an SMS fallback can be very helpful if you lose your phone -- while also increasing the attack surface).

Here's an idea: a city could buy all its affected residents FIDO keys, which are a new and totally wonderful standard token for logging in to things. Google is the first place to launch with support for it. They can be quite cheap. But of course, purchase, delivery, replacement, etc. are all concerns, and not as simple as using people's existing phones.

[Raseman]

I really like @konklone 's idea - this feels like something that NSTIC grants could pilot. Here are the current grantees: http://www.nist.gov/nstic/pilot-projects.html. Maybe Jeremy Grant from NIST could work with cities CFA identifies to explore pilot potential.

[greggish]

This also sounds similar to the GDS's recent advances on digital identity in the UK? https://gds.blog.gov.uk/2014/01/23/what-is-identity-assurance/

[migurski]

I’m a bit of an anti-vaxxer for 2FA, and I like the idea of the passwordless flow that @konklone describes. Is security the right thing to worry about here, in contrast to accessibility? Do we know how often social service users lose phones or change numbers?

[konklone]

I’m a bit of an anti-vaxxer for 2FA, and I like the idea of the passwordless flow that @konklone describes.

It's definitely a big improvement over a password. It's still completely susceptible to phishing and abuse.

Is security the right thing to worry about here, in contrast to accessibility?

I've gotten hacked emails, tweets, even snapchats from my mother, from other relatives, from friends, from old professional acquaintances. Google is working on FIDO keys because their users get phished so viciously. Phishing is an epic issue, and depending on what kind of city services we're talking about here, the audience may be more vulnerable to it than most. They'll certainly be more vulnerable than you or I. Don't sacrifice security.

Of course, making something hard to use or easy to mess up is also a form of insecurity. It's probably worth talking with users to figure out what works best for them.

[Raseman]

I would second that security is a huge issue - critical benefits are stolen all the time. 2FA doesn't necessarily fix that, of course.

On Fri, Nov 21, 2014 at 11:35 AM, Eric Mill notifications@github.com wrote:

I’m a bit of an anti-vaxxer for 2FA, and I like the idea of the passwordless flow that @konklone https://github.com/konklone describes.

It's definitely a big improvement over a password. It's still completely susceptible to phishing and abuse.

Is security the right thing to worry about here, in contrast to accessibility?

I've gotten hacked emails, tweets, even snapchats from my mother, from other relatives, from friends, from old professional acquaintances. Google is working on FIDO keys because their users get phished so viciously. Phishing is an epic issue, and depending on what kind of city services we're talking about here, the audience may be more vulnerable to it than most. They'll certainly be more vulnerable than you or I. Don't sacrifice security.

Of course, making something hard to use or easy to mess up is also a form of insecurity. It's probably worth talking with users to figure out what works best for them.

— Reply to this email directly or view it on GitHub https://github.com/codeforamerica/project-ideas/issues/47#issuecomment-64025412 .

[migurski]

Of course, making something hard to use or easy to mess up is also a form of insecurity. It's probably worth talking with users to figure out what works best for them.

That’s what I’m asking, yeah. Wacky password rules lead to passwords written on post-its and stuck to monitors. Is a client’s phone a reliable part of the loop?

[daguar]

Wonderful conversation — lots of points I want to digest and discuss more.

For a concrete example of what I think of as a "better factor" — maybe (1) phone factor with (2) password?

(This replaces email+password, which is a real barrier for lots of clients in social services.)

[konklone]

(1) phone factor with (2) password

I think in practice that'd just boil down to one factor anyway, because if you're not depending on email, how would you reset your password except through your phone?

(This replaces email+password, which is a real barrier for lots of clients in social services.)

If email is the barrier here, then I think you're looking at using SMS, TOTP (e.g. Authy) or token (e.g. Yubikey) as the sole factor. SMS is not as secure as a FIDO token, but has the benefit of transferring smoothly from device to device, and already being deliverable to basically everyone.

I don't think any of the people on this thread are security experts, and some consultation would be warranted before shipping anything.

[benjaminstrahs]

I don't have a ton of context here, but have experience with various authentication mechanisms. Some high level thoughts:

Passwordless authentication

• Passwordless authentication are not more easy to compromise than a password base flow (if the password based flow has an email reset feature). If an attacker controls the email for an account, they can just reset the password. The victim would eventually realize something was wrong when they couldn't log back in, but most people would just reset the password and not think they may have been compromised. If the email address isn't controlled by an attacker, they can't get the login link.
• Passwordless flows can cause serious confusion when people enter the wrong email address. For example, if a user has john@yahoo.com but accidentally enters john@gmail.com which another user has, that second user gets an unrequested login link and might think they have been compromised. It's important to have really clear messaging saying "if you didn't request this login, you can safely ignore this email"
• Email flows are lossy. Emails get spam filtered or lost, which are hard to debug issues. Passwordless flows exacerbate that.

Email vs SMS

• Email addresses get reused, which can compromise accounts. Make sure any email based authentication (included password reset) implements RRVS (RFC 7293) to mitigate that.
• Phone number get reused, but there isn't a technical solution. This means lockout for the original user, and access for whoever gets the number. How frequently do social service clients change numbers? What happens if the client's account has SMS disabled due to non-payment or monthly limits?
• Requesting a login token via SMS needs to be rate limited - otherwise you can drive up someone's cell phone cost by sending hundreds of requests.

Authentication is a hard problem. Depending on the service, you may be able to get around it (i.e. for checking an EBT balance, you don't need additional authentication, just the credit card). I wonder if you couldn't use some 3rd party login service (Google, Facebook, any OAuth provider really) which has handled a lot of these issues (including creating accounts without email addresses). If that's not acceptable, I would try to build this modularly enough that anyone could use it - or even run it as an OAuth service. Doing a security review/code audit would also be a good idea (I can help with that, and have other security minded friends that could probably chip in).

[fureigh]

+1ing the question @migurski raised above:

Is a client’s phone a reliable part of the loop?

I recall meeting a woman in Long Beach who was homeless and wanted to access medical services but mentioned, when asked for contact information, that her cell phone had recently been stolen. People who are experiencing homelessness or otherwise have unstable housing are likely more exposed to risk of theft than are other demographics. Hopefully it's possible to find a solution that doesn't impose another barrier to accessing services at a time when someone might most need them.