Motivation...

Even though I'm not writing engineering documentation for work, I feel the undying urge to write a "background" section. I don't want to make it sound too formal though, so "motivation"? 😬

Anywho, I came across a Reddit post the other day where there was an individual who was concerned (rightfully so!) about linking their bank accounts to YNAB for auto-import. That's because it looked something like:

If the age of internet has taught us any lessons, I think one of them would be to not enter your username and password on random pages and prompts. So, if you're skeptical like the fellow Redditor, it might interest you to stick around!

I'm going to give my dollar (inflation, thanks JPow) in this post.

The Verdict

Ok, so I hate scrolling all the way to the bottom of pages to get conclusions... here you go:

I'm not worried and it is my perspective that it is mostly safe.

Some bank account linkings are safer than others due to implementing and using the OAuth 2.0 authorization code grant (when you get redirected to your bank to login instead).

In other cases, Plaid (handling your bank connection in place of YNAB) encrypts our credentials when they store it and implement security best practices when using it to connect to our bank.

Lastly, in the extremely rare case that there is a breach, I'm protected by 2FA (two factor authentication) at all my banks and the attacker needs access to my phone/authenticator to access my account.

In summary:

• OAuth 2.0 with the auth code grant is safest (redirect to your bank), password never leaves your browser and bank
• Anything else: Plaid might have access to your password and it's less safe, but it's encrypted
• If there's a breach, I'm protected by 2FA

The Details

I'm going to be a little more formal with this now since I'll be explaining everything in depth in this section. Thanks for reading this far. Here's a meme to refresh your attention span.

Jargon

OAuth2.0: an industry standard protocol for handling authorization
Grant Type: in OAuth2.0, a grant type is how the client plans on getting an access token
Client: the entity requesting access to your bank account, in this case Plaid
Access Token: somewhat like a secret phrase that is short-lived and needs to be refreshed; it can be used to talk to your bank instead of your username/password and often comes with a scope
Scope: what you can do with the token; in all the cases here, the token Plaid has is likely read-only (they can only read your balance and transactions)
Plaid: a company/product that helps facilitate connections to financial accounts/data
Authorization Code: a grant type in OAuth2.0 that allows the client to retrieve an access token without ever touching your username/password
Password Grant Type: allows the client to retrieve an access token using the user's username/password
Refresh Grant Type: used to retrieve an access token using an existing refresh token (often comes with the access token)

OAuth2.0

With the jargon/terminology out of the way, let's talk the various ways Plaid (and therefore YNAB) obtains access to your account information.

Authorization Code

You know when you're using this grant type when Plaid (or any client) doesn't ever ask you for your password. Instead, you get redirected to your bank's website.

When I press continue, I'm at Chase's login page!

So what really happens here?

1. Plaid says "Hey, Bob wants to connect to Chase" and stores information in the URL so that it knows this is Bob, e.g. state=<this-is-bob>
2. Plaid redirects to Chase with a client id that represents Plaid, in this case you can see it being client_id=PLAID_YNAB
3. There's also typically a scope parameter, e.g. scope=read-only
4. After Bob logs into Chase's site, Chase will redirect Bob back to Plaid with the same state alongside a code (we can pretend it's something like code=bob-code)
5. Plaid then takes the state to identify that this is for Bob and then goes and makes a secure (pre-established server-to-server) request to Chase saying "Hey, we got this code that you gave us when Bob logged in. Can we have a token?"
6. Plaid stores the token that will typically expire within an hour (so if someone steals it, it likely would've expired by then)
7. Plaid uses that token to access all of your data without ever needing your password and you can likely tell Chase to stop accepting that token by revoking access
8. When that token expires, Plaid will go and use the refresh grant to get a new one

This is definitely the most secure way and I 100% love when banks support this.

Password Grant

Unfortunately, a lot of banks do not support that flow and might instead support a password grant, so you end up with some username/password field on a page you don't fully trust.

As a refresher, this is the page you'll get in YNAB specifically.

In the best case scenario, Plaid might use your username/password in exchange for a token like in the Authorization Code grant and then never need it again. It would look something like this...

1. Plaid takes Bob's username/password and then goes and makes a secure (pre-established server-to-server) request to Chase saying "Hey, can we have a token?"
2. Plaid stores the token that will typically expire within an hour (so if someone steals it, it likely would've expired by then)
3. Plaid uses that token to access all of your data without ever needing your password and you can likely tell Chase to stop accepting that token by revoking access
4. When that token expires, Plaid will go and use the refresh grant to get a new one

Disclaimer: I don't know what Plaid does, but I do trust their judgment (barring any mistakes, which do tend to happen) given user's security in mind. I'm simply taking an educated guess based on my working experience with OAuth2.0 and authorization/authentication as well as articles posted by YNAB and Plaid.

Raw Credentials

The other option, if the bank does not even support the password grant type, is to just use raw credentials. In this case, Plaid will likely encrypt your username/password when they store it (encrypting will make it next to impossible to crack even if someone stole it).

There is no magic sauce here. Whenever they need data from your bank, they'll likely send the username/password somewhere in the request (like the header) so they can import it for you.

This is clearly the least secure option.

My Opinion/Conclusion (Again)

Sorry, now I'm just being repetitive, but I'd like to reiterate my stance.

Overall, using Plaid does have some risks in exchange for financial quality-of-life.

Opinion #1: If you're using a bank that supports OAuth2.0 authorization code, then you can rest assured that your account is safe. Neither Plaid nor YNAB is storing your credentials.

Opinion #2: If you're using a bank that only supports username/password, then Plaid is likely storing your (encrypted) credentials. I personally trust the security practices at Plaid, but you are indeed taking on some risk. This is personal preference and comfort.

Opinion #3: For me personally, I trust the security practices at Plaid, but also am protected by 2FA across all my accounts. An attacker would have to steal my credentials from Plaid and also my phone/authenticator to access my bank account. But again, this is personal preference and comfort.

Fin

I hope this article was helpful in understanding the risk you are taking when using YNAB (but specifically Plaid since YNAB links through Plaid).

If you enjoyed, please consider subscribing to be notified of new articles! I plan on writing about tech and personal finance with dashes of random thoughts 🙂