Summary

  • Designed new ActBlue account Security hub, nudges, and account action notifications in close collaboration with engineering and security colleagues
  • Designed complex device onboarding and switching flow for a more secure two-factor (2FA) authentication method
  • Navigated a variety of technical and security constraints with engineers and security specialists
  • Increased adoption of Time-Based One-Time Passwords (TOTP) among campaign users
  • Led the development of a 2FA playbook with our Application Security Engineer and Customer Service

Goals

  1. A clear TOTP upgrade or enrollment user experience
  2. The ability to easily upgrade from SMS and switch devices
  3. A backup option in the case of a lost device that reduced the need for manual de-enrollment by staff
  4. Establish a pattern for notifications to users of actions being taken on their account
  5. Develop staff protocols that reduced our vulnerability to social engineering as a result of this new functionality
  6. Elevate security as a concept within the application

Background

ActBlue offered SMS-based two-factor authentication at the time to campaign and organization users as well as ActBlue staff.

Two-factor authentication via SMS was discovered to have significant vulnerabilities due to SMS messages not being encrypted.

Because security was and continues to be a foundational need and core value proposition of ActBlue, security- oriented engineers at the time felt that implementing Time-based One-Time Passwords (TOTP) was important to the security posture of ActBlue and large clients in particular.

In order to migrate away from SMS-based two-factor authentication, we needed a better, more secure, and easier-to-use option.

Problem

Two-factor authentication enrollment involves taking multiple steps on both a primary device and another device such as a phone, resulting in significant barriers to adoption.

In addition...

  • In order for adoption to be achieved, upgrading must be easy and provide clear benefits without compromising the perception of existing security
  • Because TOTP codes are received on a secondary device which can be lost, a non-device emergency alternative is required
  • In order to reduce the likelihood of attackers using social engineering to pose as a beleaguered users, new ActBlue staff protocols were required before a user could de-enroll from TOTP once enrolled
  • In order to intercept potential attacks, the user needed to be notified of actions taken on their account.

Scope & constraints

A requirement from App Sec Engineer was no radical interface changes from existing app. People get used to an app and can be more easily tricked if they get used to it changing arbitrarily.

  1. Match the style of existing authentication flows while introducing as few new visual elements as possible
  2. Email design also needed to largely match existing transactional email design at the time
  3. Alerts and validation messages were largely baked into the TOTP library we were using, so were worked-out with the engineer during design review

Solution

As a result of the constraints and goals, primary design solutions involved clear flow and CTAs, clear copy, and progressive disclosure, all while remaining consistent with existing authentication flows.

Video walkthrough

Security hub and alerts

This new authentication feature also introduced the concept within ActBlue of a "Security" hub as a top-level navigation item, and the concept of "account activity" in the form of email alerts and a "latest activity" feed.

Email alerts for key account activity are a critical tool for keeping accounts secure by helping users identify suspicious activity on their accounts. I designed, coded, and tested the email notifications for this feature.

Progressive disclosure

As you can see in the video walk-through above, I tried to make every step as simple as possible and only show the information needed to complete the task at hand. If there was an intermediate step required of authenticating with a password or authentication code, the interface focused on that and had a single clear CTA.

In addition, security "nudges" would appear in the main navigation displaying the next step a user could take to make their account even more secure.

Importance of cross-functional collaboration

My design work didn't stop at how things looked or even how they worked. I collaborated closely with an engineer and security expert to make sure every edge case was covered in the clickable prototype.

Collaboration with the Customer Service team was critical to the success of this feature. In consultation with the security expert, I worked with Customer Service to develop a "Two-Factor Authentication Playbook". The playbook gave the CS team clear guidance on how to authenticate users who wrote or called into support, ensuring this new level of account authentication couldn't be gamed by social engineering attacks.

Outcomes & reflections

Two-factor adoption increased substantially after the feature was released, as did switching from the deprecated authentication method.

Designing for security involves a lot more constraints than blue-sky product development or even developing new features for an existing product or product area. Interface habituation is a powerful tool for enhancing security and building awareness that something is “off” when it is. Breaking that continuity can be disastrous.