A critical component of our security strategy at Dwolla is the relationship we form with our clients and partners. To align our security expectations, we perform onboarding assessments on basic components of the security practices that are incorporated into applications integrating with our platform. One part of this that often prompts additional discussion is our stance on password authentication and complexity. Dwolla has previously required all integrating applications not using single sign-on to use password authentication, with at least a password of eight characters including a letter, number and symbol. While this remains a common and defensible standard from a standards-compliance point of view, we have strongly encouraged clients to go above and beyond this and to implement multi-factor authentication as well.
Dwolla itself uses higher-strength standards on sensitive internal systems, and the zxcvbn library (by Dropbox) to measure the strength of passwords for accounts.dwolla.com. The zxcvbn library incorporates the considerations in this post while providing a more flexible metric around password strength.
BUT WAIT! you say. This is old-fashioned advice. What about that XKCD comic? What about sites using magic links? What about passphrases and multi-factor authentication and biometrics? What about the evolving guidance from NIST? Not to mention the many forums and mailing lists where these issues are being discussed and debated.
Glad you asked, and you’re not alone.
Long story short: passwords are not something that anyone is crazy about. We’ve spent pretty much the entire history of the internet pleading with users to pick secure passwords and not share them. So proposals to replace passwords with something better are sorely needed. There are some common misconceptions regarding these proposals, which we will illuminate below.
Dwolla has evaluated many onboarding clients and listened to many unique and interesting use cases. To better allow for flexibility in the authentication schemes used by our clients—and the many ways in which their applications may be used—Dwolla is evolving our standard on this topic. Our standard for client authentication requirements is now the following:
Actions that result in the movement of money in or out of the Dwolla Network, or that allow access to highly sensitive information such as social security numbers or bank account numbers are required to use strong authentication. Strength equivalent to 12 characters with a letter, number and symbol is required. An attacker must never be able to obtain both a primary and secondary authenticator by compromising a single channel.
How did we arrive at this stance and what does it mean for you? Keep reading to learn more.
Password Length and Complexity
A common misconception surrounds password complexity and length. A solid argument can be made that length is just as important to password strength as complexity. The following table makes this a bit more clear. In it, the left column indicates the length of a candidate password and each additional column is a different requirement for which types of characters are required. The values represent the total number of possible passwords in that space. This is a decent proxy for password strength, because if you assume randomly generated passwords it tells you the scale of effort for an attacker to try to guess them all.
Scroll to view. *Indicates Dwolla’s baseline requirement for externally-integrating applications.
|Length||Digits Only||Letters Only||Symbols Only||Letter/Digit||Upper/Lower/Digit||Upper/Lower||Letter/Digit/Symbol||Upper/Lower/Digit/Symbol|
In order to say anything intelligent about this table, we have to make a couple of assumptions. First, we assume that users will pick a password that is easy for them to remember. Sure, many of us have good password hygiene and use password managers. But as we have seen in repeated breaches, poor password hygiene is still the norm. So for the sake of argument, let’s say that users only use the types of characters they’re required to.
Second, we will assume that an attacker is also aware of the complexity scheme. Some sites now make this more difficult to find, but many still make it explicit so users can pick compliant passwords without a lot of back and forth. So if an attacker knows the scheme you’re using he or she can now target a brute force attempt against just those characters. This is one argument to use a library such as zxcvbn that uses a calculated strength versus a static character-set requirement.
These are worst-case assumptions, to be sure. But in security there are many variables and unknowns, so starting from a less pessimistic foundation is a risky maneuver. Security is only as good as the weakest link—these two assumptions ensure we reach a conclusion that is as all-encompassing as possible. We security people like to think in worst-case scenarios because it puts a ceiling on the possible risk.
If you’re having trouble parsing this table, here are some visuals to help. First, if we plot it on a linear scale, you can see that it’s completely dominated by the 16-character Upper/Lower/Digit/Symbol strength:
Dropping that high level of complexity out of the running doesn’t help make the picture any clearer. However, it does help affirm why complexity can still be important, as even letter/digit/symbol (i.e., no uppercase/lowercase requirement) can be seen to still be much stronger than passwords of the same length without complexity.
To make this a bit easier to see, let’s look at it on a logarithmic scale. If you’re not familiar with what that means, think of it this way: instead of graphing the values in the way we count (1, 2, 3, …) we graph them by relative size. In other words, each line you go up on the graph is a multiple of the line below it. This is a bit less visually compelling as it makes the difference between password classes appear less dramatic. However, it makes it possible to see the full range of values.
Keep in mind, the difference between 1E10 (that is, 10 billion) and 1E16 (i.e., 10,000,000,000,000,000; 10 quadrillion), is a factor of one million. Thus, each value on the vertical axis is one million times stronger than the line below it.
With this data and these assumptions, what can we say? Let’s say we wish to make the argument that we will require a 10-character password but not enforce any complexity. What’s the first 10-character string that comes to mind? Is it, perhaps, “1234567890?” “0008675309?” “3141592653?” “2718281828?” Again, let’s assume at least some users will follow the path of least resistance. So as an attacker, if I know that at least some of your users are likely using fully numeric passwords, how many passwords do I have to try to find at least one?
At five billion guesses, I’ve tried half the space and have a 50% chance of finding one if I’m guessing at random. At 10 billion I’ll have tried them all. Modern systems, especially factoring in GPUs, can try millions of password hashes per second. This does not account for work-factor-based hashing schemes, which are also a Dwolla requirement; but again—worst-case. See this related blog post about password hashing for details.
That aside, if we’re concerned with an offline attack (and we should be, given recent breaches of password databases), we should be aware that an attacker may be able to try every possible password hash in just a few hours. Note, in the table above, that a 10-character digit-only password isn’t even as strong as a six character alphabetic password and around 2,000 times weaker than a six-character letter/digit/symbol password by this measure of strength.
Obviously, this can be mitigated by further increasing the length. A 16-character password without complexity could, following the logic above, be argued to have equivalent strength to something like an eight-character upper/lower/number/symbol password. What can trip people up is getting caught in the “complexity is dead” side of the argument. We occasionally are asked to make exceptions for password schemes that do away with complexity but do not meaningfully increase length to match. It’s true that complexity alone won’t make for a secure password. But it is still a great way to increase password strength. If you’re going to drop complexity requirements, you had better ratchet up your length to account for this.
Alternative Schemes – Magic Links & One-Time Passwords
A less common question—but one that has started trending upwards—is whether Dwolla will allow for alternative schemes.
Several well-known sites have begun to make use of “magic links” by which a user clicks on a link to log in, is sent an email or text message with a login code and logs in with this code instead of a password. The argument goes like this: how do you get into a site if you’ve forgotten your password? By initiating an email with a link that allows you to do a reset. So then, if we’re allowing this to happen, what’s the difference in just cutting out the middleman and using an emailed or texted link each time? This could improve usability by doing away with the need to create, store and remember passwords—which we know is the crux of many security issues. This sounds good in theory, but there are several considerations.
First and foremost is that it assumes the security of the channel over which you’re sending the link. Email is not universally encrypted and SMS messages have repeatedly shown to be interceptable. Additionally, even if encrypted end-to-end, such messages may still reside unencrypted on the recipient’s server or device. If we assume total security of the recipient’s email server and all devices containing it, then this isn’t an issue. However, there are a wide variety of servers, devices and applications that may end up exposing the authentication link or code to someone other than the intended user. In corporate environments, administrators likely are able to read the email of any user, even if they make it a matter of practice not to do so.
“Okay,” you say, “but isn’t this the same for password reset links?” Yes, it is! And that’s why password resets should always perform some sort of secondary confirmation of a user’s identity before allowing a reset to proceed. For example, while security questions aren’t perfect, they can allow for such passwordless backup authentication. Knowledge-Based Authentication (KBA) is commonly used in the financial sector to authenticate users where a password is not known or hasn’t been created.
But is this splitting hairs? Yes, secondary authentication for resets would be ideal but in reality many sites don’t do secondary authentication for resets, right? Well, there are still some reasons we care about this. First and foremost, just because many sites do it doesn’t mean it’s appropriate for and in alignment with Dwolla’s threat model and risk profile. At Dwolla, we help facilitate the movement of money and are trusted by a large community of clients, partners and end users to protect that capability (and their money). We take this responsibility seriously and align our security posture accordingly. By ensuring that all integrating applications meet the same standard, we ensure that we don’t lock the doors just to leave a window open.
Here are a few other points worth considering. First, password resets and changes should be, and often are, rate limited. This has traditionally been done to prevent users from getting around password history requirements. However, it also means that an attacker targeting a site configured this way would be limited in the number of password reset emails that could be generated. A site using a passwordless authentication scheme may not have similar protection. How would an attacker abuse this? Well, security is a game of what-ifs, and so this is left somewhat as an exercise to the reader. However, one argument would be that an attacker with an unlimited rate of magic link emails could bury the user in them and thus increase his or her chances of getting to one before the legitimate user can.
Similarly, if the attacker is able to use the login link and delete the email from the user’s inbox before it’s otherwise seen, the user might have no indication that their account has been compromised. If an attacker abuses a password reset link, the user will then be unable to log in on their next attempt and know that something is up. Some sites provide notification of logins from new locations, a login history or require secondary authentication when using a new browser (or other changes in profile), but many do not or do not make this functionality obvious.
Likewise, it is less likely that system administrators and security teams will be monitoring for abnormal numbers of successful logins. Should they? Yes, probably. However, it’s more likely that they will monitor for or audit unusual password reset activity. Unless every successful login is going to be monitored to the same level of paranoia as password reset emails, this may bury threat intelligence below the radar of defenders.
However, there is a middle ground. If we’re concerned about the potential compromise of email or SMS, what about splitting the risk between them? Sure, an attacker could have taken over a device that contains both email and SMS messages, but then it’s likely that they may also have access to the user’s password manager (you are using a password manager, right?). By this logic, magic link-style authentication schemes may be justifiable if care is taken to either a) only use them for low-value data and then require a password to re-authenticate before doing more sensitive functions, or b) use a second token (limited to a single use and short period of time) sent to the opposite device from which a user first logged in. That is, if the user logged in with an email-based token, send them a token via SMS (or, even better, use a hardware or software two-factor token or push notification to an app).
We feel that this latter, while a bit harder to analyze, brings the risk of account compromise into the same ballpark as a password-based scheme. However, it must be noted that passwords are a standard and time-tested scheme.They have their challenges but we mostly know what these are and how to manage them. When you move away from them, it’s critical that you think very carefully to ensure that you are implementing a scheme that provides you and your customers an equivalent level of protection.
From Here to Policy
In order to reduce all of this to a policy statement, we are going to make some assumptions:
- Top-end hardware within the reach of most attackers is capable of one million to one billion hashes per second.
- Quantum supremacy is on the horizon, if not already achieved (requiring a quadratic increase in strength).
- The password scheme in use should protect equally against online and offline attacks. Since internet latency introduces tens to hundreds of milliseconds of round-trip latency for an online attack, we will use a hashing time target of 0.1 to 1.0 seconds to resist offline attacks.
- We want 99.9% confidence that an attacker will not randomly guess a password during its lifetime.
- We will use 10 years as the effective lifetime on a non-expiring password.
- The password is not easily guessed via dictionary-based attacks.
Thus, our policy statement:
Actions that result in the movement of money in or out of the Dwolla Network, or that allow access to highly sensitive information such as social security numbers or bank account numbers, are required to use strong authentication. Strength equivalent to 12 characters with a letter, number and symbol is required. An attacker must never be able to obtain both a primary and secondary authenticator by compromising a single channel.
How did we arrive at this? First, 10 years is 315,360,000 seconds. If we want to ensure a one in 1,000 chance of guessing, we want to multiply that by a thousand for the password space (one hash per second), which gives us a target of 315 billion passwords. With the quadratic speedup of quantum computing, we must square this number and shoot for approximately 1E23 hashes. With a letter, number and symbol requirement, we can see in the table above that we will need a length of a little more than 12 to hit this target.
If you are not using a work-factor-based hashing scheme, choose not to require complexity or any of the other assumptions above don’t hold, you will need to adjust this accordingly.
Taken together, it can be seen that there are definitely arguments to be made for making passwords more user friendly and evaluating alternative login schemes to remove them entirely.
At Dwolla, we believe that innovation is key to both the success of our product and combating the threats we face every day. We continually evaluate our security recommendations, requirements and policies to ensure they align with risk—while maintaining the best possible experience for our users. Part of this is balancing new ideas against tried and true methods and ensuring we are thoughtful and intentional about making changes to these.
Because when it comes to security at Dwolla, we are never done.