Welcome back to Zapier month here at All Things Auth!

This series includes all of the fun details that we gathered during our review of Zapier that we didn’t have nearly enough time to talk about during the Zapier screencast episode.

This article talks all things passwords with a small discussion on email thrown into the mix too. Password policies, improvements to those policies, changing existing passwords, small UX improvements, important security enforcements, and more.

Let’s get into it!

Fun with password creation during signup

I'll start off fresh on the Zapier home page and try to create an account using the password "a":

Fortunately, that horrible password isn't accepted. Zapier requires passwords to be between 6 and 512 characters in length and to contain at least 1 alpha character.

In their Digital Identity Guidelines, NIST recommends requiring user created passwords to be a minimum of 8 characters and a maximum of at least 64 characters. They also outline that service providers should not impose other composition rules, such as requiring mixtures of different character types. Similar recommendations are echoed by the Microsoft Identity Protection Team and the UK's NCSC.

❗ Improvement: Zapier should increase the password minimum character limit from 6 to 8. Though less important than the length requirement, removing the arbitrary requirement to include at least one alpha character would be nice too.

⭐ Excellent: Zapier allows passwords up to 512 characters in length, which is plenty high enough for ridiculously secure passwords. It supports the use of long passwords automatically generated by password managers and long passphrases manually created using dice.

NIST also recommends allowing all ASCII characters (e.g. what I can type on my normal US keyboard) and all unicode characters.

⭐ Good: Zapier does not appear to restrict the use of any characters in user created passwords!

They allow lower-case, upper-case, special, space, numeric, and even unicode characters. Yup, that means I can use emojis in my password!

For example, I successfully used the poop emoji to set my password to: 💩💩💩a💩💩💩. Obviously, you shouldn't use such a shitty password. (Sorry... I couldn't resist.)

I was also able to set my password to an emoji representation of the first verse of "Let It Go" from Frozen. How fun!

The ❄️ 🌟 🔦 ⚪ on the mountain 🌙 🌠. 🙅🏻 a👣 to 🐝 👀. A 🏰 of 😢, and it 👀 like☝️️ the 👑. The 💨 is 🐺 like this 🌀 ❄️ ☔️ 🏠. 🙅🏻 keep it in, ☁️ 💡 ☝️️ tried.

Zapier allows users to create really strong passwords, which is excellent, but how will a user know whether the password they have chosen is actually strong or not?

Password strength meters

It is relatively common practice for services to display a password strength meter during the account creation process with the goal of helping users select strong passwords. However, use of a password strength meter is not actually a universally recommended practice.

NIST does recommend using a password strength meter:

[Service providers] SHOULD offer guidance to the subscriber, such as a password-strength meter, to assist the user in choosing a strong [password].

NCSC acknowledges that password strength meters can be useful to "steer users away from the weakest passwords, but often fail to account for the factors that can make passwords weak (such as using personal information, and repeating characters or common character strings)."

Security researcher Troy Hunt wrote a compelling article "Password Strength Indicators Help People Make Ill-Informed Choices" in which he expands on this idea and explains that password strength meters usually only perform a mathematical analysis of password strength and often do not consider human behavior that frequently results in weak passwords.

There are many other high quality resources exploring whether password strength meters should be used or not.

Depending on the implementation, I believe password strength meters are a useful tool to guide users away from weak passwords. As I talk about in the next section, password meters are not the only solution to avoiding weak passwords, but the visiual indicator can be a very helpful cue for users and one that is universally understood.

It is possible that Zapier is well aware of this already and has made the decision to not provide a password strength meter during account creation. However, Zapier engineers, if you haven't yet read some of the research out there, check it out so that you can make an informed decision whether a password strength meter will provide additional security to your users.

Next, I'll explain an update that Zapier absolutely should make regarding password creation.

Reject compromised passwords to help avoid credential stuffing attacks

I've previously written about the common and horribly problematic issue of password reuse. Reused passwords make it possible for hackers to launch credential stuffing attacks. OWASP explains:

Credential stuffing is the automated injection of breached username/password pairs in order to fraudulently gain access to user accounts. This is a subset of the brute force attack category: large numbers of spilled credentials are automatically entered into websites until they are potentially matched to an existing account, which the attacker can then hijack for their own purposes.

Security researcher Troy Hunt runs a service called Have I Been Pwned, which aggregates data breaches in order to notify users via email when their passwords (and other data) have been compromised. He is an expert when it comes to passwords and has written extensively about credential stuffing attacks.

In an effort to avoid these types of attacks, NIST requires service providers to reject known weak passwords, which includes those from other data breaches:

Microsoft, NCSC, and many other security researchers agree that blacklisting weak and common passwords is a good idea. Troy wrote a great article highlighting many best practices from NIST's guidelines, including the specific importance of rejecting known bad passwords.

Zapier does not currently do this. For example, I can set my Zapier password to "password", "password123", and "aaaaaa".

❗ Improvement: Zapier should reject user created passwords which have been previously compromised from data breaches at other service providers.

It is all well and good to tell service providers to reject compromised passwords, but back when NIST released their guidance in June 2017 this was easier said than done. There were few commonly available tools to allow service providers to incorporate such a process into their account creation workflows. Fortunately, Troy realized that he was uniquely positioned to help solve this problem given his work on Have I Been Pwned and released a tool in August 2017 called the Pwned Password API to do just that!

Just last month in February 2018, Troy released Pwned Passwords V2. This critical update, that is still free for public usage, contains more data and significantly increases the privacy posture of the service. It has been adopted a lot: Cloudflare, 1password password manager, and dozens of tools created by developers in all kinds of programming languages and technologies.

The underlying data that powers the Pwned Password API is also freely available for download, so Zapier could integrate compromised password checking directly into their service on their own infrastructure.

Regardless of how they implement it, Zapier should definitely leverage the Pwned Password service (or something similar) to reject passwords which have been previously compromised. Not doing so leaves their users at significantly higher risk of having their account compromised by a credential stuffing attack.

Account enumeration problems

I'm going to take a quick diversion from passwords for a moment to focus on a related privacy issue.

Account enumeration is an often overlooked problem where anyone can determine whether or not an email address has a valid account with a given service provider.

When a user provides an incorrect password on the Zapier login page, the error message correctly reports that either the email address or the password were incorrect. This does not reveal whether or not the email address has a valid account on Zapier.

Unfortunately, the "Forgot Password" page reveals this exact information. When you enter an email address that does not have a Zapier account, the error message confirms the account does not exist.

When you enter an email address that does have a Zapier account, the error message confirms the account does exist.

❗ Improvement: Zapier should update the "Forgot Password" error message to avoid confirming whether an email address has a Zapier account or not.

Why is this even a real problem? Well, for one thing it is a privacy concern if anyone can confirm that I have accounts on random services online. Secondly, an attacker could actually use that information to cause me quite a bit of hassle by temporarily locking my account without my knowledge. Let's explore how in the next section.

Preventing brute force attacks on the login page

Unsurprisingly, it is best practice for service providers to implement a rate limiting scheme to prevent hackers from brute force guessing user passwords via the login page.

NIST requires service providers to "implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account."

⭐ Good: Zapier has a rate limiting scheme in place to prevent guessing passwords via brute force attacks.

After 7 incorrect password guesses, Zapier locks my account and requires me to reset my password via the "Forgot Password" workflow. This both effectively prevents hackers from guessing my password many times in a row and also forces me to confirm that I am still in control of the email address on file with my account.

Unfortunately, this account lock rate-limiting scheme can also easily be abused by anyone who knows that I have a Zapier account. As we discussed in the previous section, anyone who knows my email address can confirm whether I have a Zapier account using that email address or not.

Some readers might be thinking "ok, so they can lock your account and force you to reset your password via email. Big deal! That is better than letting them guess passwords forever and eventually get into your account, right?" First, there are other rate limiting approaches that do not lock accounts. Second, it kind of is a Big Deal because it is essentially denial of service via password reset.

Surprisingly, Zapier does not send me a security notification email when they lock my account.

❗ Improvement: If Zapier chooses to use account locking as a rate limiting mechanism, it should send a security notification email anytime it locks an account to inform users of what happened.

This means that the next time I go to log into my Zapier account and use a password I know to be valid, I will get an error informing me that my account is locked. Obviously, I will be surprised by this since I didn't do anything to get the account locked; some random person on the internet caused it to get locked by trying to guess my password! I will now need to go through the unnecessary Forgot Password workflow to reset my password, which has not been compromised, all the while I still don't know why my account was locked in the first place.

❗ Improvement: Zapier should implement a rate limiting mechanism that is less susceptible to abuse and does not cause end-users to unnecessarily reset their passwords.

For example, instead of account locking, Zapier could implement exponential backoff rate limiting. After a small number of incorrect guesses, an error message would say that there is a wait period of 1 second before trying again. After another incorrect guess, the wait time becomes 2 seconds. Then, 4 seconds, 8 seconds, 16, 32, 64, 128, etc.

Each incorrect password guess is exponentially more expensive for the hacker and quickly they are waiting minutes and hours in between each guess. This effectively shuts down any brute force attack and also does not require the account holder to reset their password unnecessarily. It is very likely that the wait time will have expired before the account owner next attempts to login. If the timeout hasn't yet expired, then it should always be an option for the user to immediately reset their password via email using the Forgot Password workflow.

Changing the current account password

The final scenario I want to look at is actually changing the current account password. I am able to change my password in the security settings by simply providing my current password and a new one.

⭐ Excellent: After successfully changing the account password, Zapier expires the current session, which requires the user to re-authenticate using the new password.

Assuming that Zapier expires all current sessions, this mechanism can be used to eject hackers from my account who might have gained access using a previously compromised password.

However, the current UX is a bit odd. After successfully changing my password, I see a success message and remain on the password settings page. In the background, Zapier has already expired my current session, so the very next time that I click on anything, I get redirected to the login page and shown a message that my current session has expired. Pretty confusing, right?

It would be much nicer UX if I saw a success message after changing my password and then saw a popup modal on the settings page itself which asked me to re-authenticate. This popup could explain that my session expired because I successfully changed my password and explain what is happening.

Zapier could also do a better job notifying me when my password is changed in case I was not the one to change it.

❗ Improvement: Zapier should send a security notification email to the user anytime the account password is changed.

If a hacker does access my account using a compromised password, they might change the account password in an attempt to permanently take control of my account. Fortunately, changing the password will not give the hacker permanent control of my account because I can reset the account password via email through the Forgot Password workflow. However, I would really like to know that someone has changed my password so that I can take corrective action sooner rather than later to regain control of my account and eject the hacker. This is why a security notification email is so important here.

Ray and I have both highlighted that most users likely don't interact with the Zapier website on a regular basis after their Zaps are setup and working as expected. This makes communication via email critically important, especially for security related notifications.

Luckily, the hacker won't be able to change the account email address because Zapier requires me to click a confirmation link in an email they send me asking whether I am the one attempting to change the account email address. Theoretically, the hacker won't have control of my email inbox, so they won't be able to click the confirmation link and permanently hijack my acocunt.

Wrap up

Zapier is doing some things really well in terms of passwords, but there is unquestionably room for improvement.

It is excellent that Zapier allows passwords up to 512 characters in length and allows all character types. This easily accommodates the use of password managers and other password best practices.

Zapier also requires the user to re-authentication after changing the account password, which currently has a funky UX, but does serve to eject unwelcomed guests who might have gained access via a compromised password.

Also, all signs point to Zapier following best practices for actually storing passwords in the database. Though I cannot confirm that just by using the website as an end-user, some service providers make glaring errors that strongly indicate that they are not following best practices for securely storing passwords, such as emailing the account password in plain text, artifically limiting the password length, etc. Only Zapier can confirm whether they are following best practices for password storage, but no public facing red flags is a good sign.

The most critical improvement that Zapier needs to incorporate is to reject passwords that are known to already be compromised. They can do this by leveraging Troy Hunt's free Pwned Passwords V2 API, or by downloading the source data and directly integrating it into their service.

Zapier should also address the account enumeration issues on the Forgot Password page, which can directly contribute to abuse of the rate limiting mechanism on the login page. A rate limiting mechanism other than account locking is could likely provide a better security UX for end-users as well.

If you’ve stuck it out til the end, then you should definitely join the email list below to make sure you don’t miss the last article in the Zapier series next week! We will wrap up by taking a look at the extremely useful Zapier help documentation.

Let Zapier know that you want to hear from them too! Send them a tweet!

Lawery disclaimer: All Things Auth is not associated with Zapier in any way. We decided on our own to write this article because we like Zapier. All views expressed here are those of the author based on use of the public Zapier service only.

Thanks to Jordan Fischer for reading drafts of this.