29

I’m applying for a mortgage, and found a potential lender from a referral from my real estate agent. The initial application process seemed normal and very similar to what I’ve experienced with other banks. I expected to verify my assets by providing documentation such account statements, but was instead asked to link my bank accounts with them using a third party website (The domain name is finicity.com - so I’m fairly sure it’s this).

The lender set my expectations with this via email:

What we don't do:

  1. We don't ever see or have access to your login information.
  2. We don't use your information for any other reason than to process your loan.
  3. We don't have access to take any actions in your accounts - we access read-only information, just like the documents you'd otherwise have to send.

I have a checking account with Chase and linking the account with the lender was done by redirecting to Chase.com (where my password manager automatically filled in my username and password) and enabling some permissions. Chase sent me an email and the lender appears as a linked application. This strikes me as entirely legitimate.

However, I have a brokerage account with Vanguard, and the service is asking for my username and password. I am VERY uncomfortable with this.

enter image description here

Is this a reasonable request nowadays? Or should I push back and insist on verifying my assets with account statements?

  • 3
    Is that the same login as Vanguard Investment? Did it appear in a popup? (Don't be alarmed by the login being in a popup, it should) – Mars Dec 18 '19 at 12:06
  • How did the page look, where you browser filled in the log in credentials automatically for chase? Was it no pop up? When the Vanguard log in appears in a pop up, how does the address look like? – Bernhard Döbler Dec 18 '19 at 12:21
  • 2
    My SOP is that when site Y asks me for a password, I provide Site Y's password. I disregard any instructions to provide Site X's password, because that violates Site X's TOS which I agreed to follow. If this doesn't work, I regard Site Y as broken. Which it is. – Harper - Reinstate Monica Dec 18 '19 at 22:21
  • 4
    @BernhardDöbler, The Chase login was a pop up and the popup had chase.com as the domain. The Vanguard Investment form was hosted by the 3rd party - I am 100% certain the form was not from Vanguard. Upon closer inspection, the inputs asking for usernames and passwords are generated by finicity.com (that is, they are not iframes referencing Vanguard) – HPierce Dec 18 '19 at 23:22
  • 4
    "Should I provide my password" -> No, never, under any circumstances, to anyone. – njzk2 Dec 19 '19 at 4:46
31

The interaction you described is a common and routine part of Internet applications today, but it can sometimes be challenging for non-technical users to figure out what's going on. In simple terms, here's what happens:

  • An information provider (Google, Facebook, Twitter, your bank) includes a mechanism in its software for third parties to perform some sort of operations, such as seeing your list of friends or your account balances. This mechanism is called an API.

  • To use the API to access your information, the other site (the mortgage lender here) has to get your permission. The way that this happens is that it sends your browser to the hosting site (Chase) with a request for permission. Chase verifies your identity (usually through a normal login), asks you if you want to allow the access, and then sends you back to where you started with a token that the mortgage lender can use to make API requests.

  • The mortgage lender then uses the API that Chase published, along with the token you authorized, to retrieve your balances.

  • Whenever you like, you can go to a site that has issued a token for you and review or cancel the permissions. Here are the management links for a Google Account, Facebook, and Twitter.

It's likely that you use this kind of access all the time without recognizing it; for example, I log into about 20 different sites for work using a Google Account associated with a company, and I even use my personal Gmail account to log in to this site! Any time you use a link that says "Log in with ...", this is what's happening. (Next time, you might notice that when logging in to a new site you see something like "This site will be able to see your name and e-mail address.")

The most important practical question is the one that is the foundation of your post here: How do I know that I'm really on my bank's Web site? This is the same as any other time that you're logging in. In fact, if you were already logged in, most sites won't ask you to re-authenticate if there's a token request. (Your bank might anyway because of the sensitivity and rarity of the request.) There have been tons of electrons spilled over this, but the best way is to use a password manager that auto-detects the site, which is exactly what you're already doing. (In fact, one of the reasons to use a popup for something like this is specifically so that a password manager will more reliably detect the true site address.)

In the case of the Vanguard prompt that you showed, if this is on the lender's site, then something is in fact fishy. I know of some legitimate sites that do this because SomeBankCo doesn't provide an API; Mint did this for years before it became common. (I'd still steer clear personally, though.) However, the lender's statement that they don't see your login credentials means that you should absolutely expect them not to ask for them. If the screenshot you showed is from Vanguard's site (it doesn't look like it), then all would be okay, but the combination of the lender's assurance and the fourth-party prompt would send me back to paper (and complaining loudly to the lender).

  • 4
    This answer really downplays the dangers and (by design!) deceptiveness of OAuth about the difference between authentication and authorization, and how little actual ability you have, even if you did understand the technical aspects, to trust that the parties involved will behave as they say they will. Don't do this. Send paper documents. – R.. GitHub STOP HELPING ICE Dec 19 '19 at 4:08
  • 2
    @R.. Deceptiveness? Capability security models aren't new, buddy, and annoying details about the protocol implementation aside, OAuth is better than any federation system we've had to this point. Trusting the resource server to conform to its contract is an unavoidable baseline in any cross-party integration, and I'd expect a banking system to be substantially more trustworthy (because paranoid auditors) than most out there. – chrylis -on strike- Dec 19 '19 at 4:17
  • 1
    @chrylis-onstrike-: OAuth conflates the acts of "requesting party A to vouch for your identity to party B" and "authorizing party B to access your account with party A" in ways that are confusing even to domain experts, and did so intentionally (i.e. replacing OpenID which did not do this) because its creators wanted to facilitate the results. – R.. GitHub STOP HELPING ICE Dec 19 '19 at 4:25
  • 2
    And banks are only paranoid about (1) avoiding monetary losses they might be held accountable for, and (2) complying at least superficially with applicable regulations. They are not paranoid about sharing access to your private information for profit. – R.. GitHub STOP HELPING ICE Dec 19 '19 at 4:27
  • 2
    This answer is inaccurate for most banking applications (unfortunately). They tend to use third-party services like Plaid or Finicity since most financial companies don't have OAuth/APIs implemented. Your last paragraph touches on this, but I think that's much more important to the question than the remainder of your answer. – hichris123 Dec 19 '19 at 8:07
58

If more than one person knows something, it isn't a secret.

There is no legitimate circumstance under which you should provide your personal password to anyone. Ever.

Anyone that asks for your password is either scamming you or incompetent.

(This answer is completely independent of the "mortgage lender" in the question. It applies to everyone in all situations.)

EDIT:

"milk" points out that "redirecting to Chase.com (where my password manager automatically filled in my username and password)" could mean that they aren't directly asking you for your password.

Instead, they are asking you to simply prove that you can sign onto your other account to confirm who you are. This means that the requesting site will not see your password and cannot claim to be you.

In addition to your personally verifying that the information is going to the correct site, knowing that your browser trusted it enough to automatically supply your password is a good indication that the other site isn't spying.

So, what I said above is true in general, but in this case you would be using your password to sign into your account; the other company would not be able to see it. The login simply establishes an identification of you between the two companies.

  • Brokerage to Mortgage: Confirm identity of person X: ask them to login.
  • Mortgage to person X: Please login
  • Mortgage to Brokerage: From now on, when you talk about person X, we'll know who you mean.

It should be safe for you to go ahead.

  • 8
    If the auth prompt comes from Vanguard themselves then it could be legit (the prompt should be a new page like the OP mentioned with Chase and you should verify the url, not inline in another app, which might be what's happening here, I'm not sure). There are definitely APIs that require authentication and they can't get that authentication unless they open an auth prompt. – milk Dec 18 '19 at 1:58
  • 8
    In this case, it doesn't seem like Vanguard is the one doing the authentication, so I'd be weary of this. This looks more like you are, in fact, handing them your username and password. – Mars Dec 18 '19 at 12:06
  • 3
    (The Chase one sounded legit though, as I would expect them to provide that sort of API) – Mars Dec 18 '19 at 12:18
  • 10
    @Mars "wary", not "weary" unless you're just tired of the whole thing. – Spehro Pefhany Dec 18 '19 at 17:25
  • 2
    Also, if this is a standard auth process, you should be able to go to your banking website in another tab, login so you have an active session, then click on the link that originally asked you for your password. If you have an active session in chase, then the auth should happen automatically without needed to supply your password – Reimus Klinsman Dec 18 '19 at 18:23
12

No, this is terrible security practice. But it is surprisingly common among banks, see e.g., this related question.

Your decision here is going to come down to how much you trust Finicity to do what they say. (I did once with a similar site, not long ago, and it hasn't come back to get me.)

But again, this is terrible security practice, and the companies shouldn't be doing it.

EDIT: This is the analogy that comes to mind: it's like teaching children to play a game where you try to find a hidden gun and then play Russian roulette with it when you do. Even if it's not guaranteed death, it's still inculcating atrocious and dangerous habits in users. The user who types their credentials into Finicity is more likely to type them in for the next phishing email they receive.

  • 1
    This should be the accepted answer. Just because legitimate businesses use this does mean it isn't an incredibly stupid practice. – Nosajimiki Dec 19 '19 at 23:13
5

If you trust the site that is requesting it, then it's probably fine. Unfortunately it's becoming commonplace now for various applications to legitimately ask you to login with your username and password into third party applications. One obvious example is accounting software, which can request and store your credentials for all of your banks so that it can sync your accounts automatically. This is a great convenience, but you must trust that the mechanism and location used to store your credentials is secure. When websites request your credentials for third party applications, typically they don't need to store your credentials for future use, but you'll have to take their word for it that they aren't storing it, or again if they are storing that they are using a mechanism and location that is secure. Even well-intentioned sites that use standard best practices for their storage of user credentials are still vulnerable to attack, both from external sources or possibly even rogue internal employees.

The main downside to this trend is we can no longer preach the absolute rule that no one should ever ask for your password. Now we all have to make decisions about who is legit and who might be trying to scam us. As soon as people are forced to make decisions, mistakes will inevitably be made.

There are however simple counter measures we can take, at least to stay safe when using the one-time request for passwords such as the scenario in this question of verifying a single bank statement. Either of these will suffice:

  1. Before providing your username and password to a third party application, change your password. Once the application is finished with it, change your password back to one you like.
  2. (Better) After giving your password out to someone you don't want to know it long term, change it shortly after to a new random password.

I strongly encourage everyone to use a password manager, and with few exceptions even you don't need to remember your passwords. Let them all be long, complex, and random, and you can change them anytime you wish without having to worry about remembering a new one. Just make sure that you store your encrypted master password file in a place you can access from anywhere. For example, I store mine (KeePass) in a cloud (Google Drive) account, and I have cached copies of it on my phone and all my laptops in case I'm not online when I need it. (Though it's extremely rare that you would need it when you aren't online!) Once you have this you only need to actually remember two passwords: the login to your cloud storage account, and the long and complex password to your master password file. Another nice thing about this is you don't have to remember your usernames either, and you can even put unique bogus answers in for your security answers, as long as you record them in your password file. One time someone kept trying to login to my Bank of America account and locked me out multiple times. I simply changed my username to something no one else would try (and I actually don't remember what it is, nor do I have to) and it never happened again.

  • 4
    it's NEVER fine for anyone to demand your login credentials to anything. The sole exception MIGHT be law enforcement officials and then only with a court order. And even then I'd be highly suspicious about their motivation, as it'd enable a bad cop or investigator to do things like create incriminating evidence at my peril and there'd be no way to prove it wasn't my doing. – jwenting Dec 18 '19 at 11:02
  • 1
    @jwenting do note that even site we're discussing on there are google, facebook login options even though this is neither facebook or google... is that equally suspicious? – eis Dec 18 '19 at 14:52
  • @jwenting "demand" no, "request" sure, and you can decide if you want to provide it. Everytime I've had a third party site ask me to enter my bank credentials I've always been presented with another option. – TTT Dec 18 '19 at 14:58
  • 1
    Nothing legitimate about it. Go look at the site's TOS, I guarantee there are 2 clauses: one not to share your password, and another not to scrape the site for content or account info. And yes, we can still preach that rule. And no, not even law enforcement. Law enforcement can contact the ISP and get a special account login that lets them inspect/surveil the user account. – Harper - Reinstate Monica Dec 19 '19 at 1:36
  • 1
    @Harper-ReinstateMonica the comment I replied to used this formulation: "it's NEVER fine for anyone to demand your login credentials to anything.". I would think, especially for non-technical user, even with oauth the site is "demanding your login credentials to anything" - it is demanding them to do authentication somewhere, even if using another site. It is not demanding them to site itself, but it is asking you to supply them to "somewhere" to be able to use the site. This was my point. – eis Dec 19 '19 at 15:15
4

Basically, it comes down to this.

Sites that provide ways to access the needed information, such as Chase, will allow services such as Finicity to follow something called an "implicit grant" resource access pattern.They make a request to Chase for some info, Chase asks you to login and (then probably) give permission. In such a case, Finicity never sees your login info at all.

It looks like Vanguard doesn't have that kind of service, so Finicity has to resort to something called the "ROPC" pattern (in other words, the "password" pattern). This involves getting your login info and logging in on their end.

EDIT: ROPC implies granting limited access, through the username/password and a client/application id. If Vanguard doesn't have that sort of service (and there's no reason to expect them to), then this is likely just a password login, in which they load some screens and scrape the data from them. In this direct login case, the scope of what they can do programmatically increases, but I don't think it particularly increases the danger. The worst case is still the same and it still requires a bad actor.

If they're following best practices, they'll never log any of your info and clear it immediately after gaining the access that they need. No dev or observer should ever see your info.
But there is no way to guarantee that they follow best practices.

If you don't trust them, there should be no issues with providing the info to the lender in another manner. They may say no, in which case you'll have to decide if you wish to trust them or not.

The changing your password part is a good idea if you do decide to submit your info to them, but note that if you do it too soon, it may invalidate the login and you'll have to do the process all over again.

Worst case scenarios:
・Scam site. Likely? I didn't look at them, but if required by your bank, probably not.
・Poor logging or caching practices. Certainly possible, but not an issue unless someone internal decides they want to retire in the Bahamas, or their logs leak somewhere.

Likely business usecase:
The program logs in, gets the info it needs, then clears the login info.

  • 2
    If "ROPC" is sharing your Site X password with site Y... and site Y logging in as you, the only "best practice" is not to do it. It is a brazen, obvious TOS violation for all parties, and of course it's a phantasmagorical security hole, which is why it's a TOS violation. It puts unfair security burden on site X. I grasp the business usecase for site Y, but this is classic "ends justify the means". Likely bad scenario: site is hacked, and hacker adds code to surveil credentials passing through. – Harper - Reinstate Monica Dec 18 '19 at 22:03
  • 1
    @Harper-ReinstateMonica TOS violation? Citation needed (although it's probably likely. But at best it's case-by-case). Also, that "likely bad scenario" applies to any site ever. I'll admit that the fact that site Y uses Site X and Site A-F makes site Y a better target – Mars Dec 19 '19 at 0:14
  • "You are responsible for maintaining the confidentiality of any account information, user names, logins, passwords, and security questions and answers that you use to access any page or feature on this Site" TOS If a website overlooked saying such a thing, they'd quickly rectify it. Even Citation Needed says that... – Harper - Reinstate Monica Dec 19 '19 at 0:23
  • 3
    Also Vanguard: you may not (or enable others to): Copy any reports or data on this Site... scan any accounts related to this Site, or attempt to gain unauthorized [by Vanguard] access to accounts associated with this Site through data mining, or any other means of circumventing any access-limiting, user authentication or security device of any servers or accounts related to this Site; So the verifier violates TOS by scraping, and the accountholder violates TOS by enabling. – Harper - Reinstate Monica Dec 19 '19 at 0:30
  • 1
    Since Vanguard presumably complies with their side of the contract, enforcement is relevant to user non-compliance. I would expect this to come up when a loss occurs, and user and Vanguard are arguing over who eats the loss. It's apparent a third party obtained user's credentials. Vanguard deposes both parties, and one or both admit passwords were shared. User and third party are in breach, or doing tortious interference. And culpable for all Vanguard's losses as a result. – Harper - Reinstate Monica Dec 19 '19 at 3:01
0

No.
Do not provide YOUR login to ANYone, not even your dog.
Broker statements are sufficient proof of your holdings, as they would contain your ID as well.
Any settlements or transfers between your brokerage account & bank account could be additional proof when reconciled with your bank statements.

0

I am not going to answer based on the technology. Other answers have focused on that.

Instead I am going to focus on what information you have to provide. You only need to establish that you have the income to service the debt, that your required monthly payments are manageable and you have the money in cash or near cash to pay the down payment and the closing costs.

If you have money in a 401(k) or IRA, the lender doesn't need that information to make a loan decision, unless you are using those funds for the down payment. If you have money in a taxable investment account, and aren't using it for the down payment they don't need to know the balance.

Again if the money in that account is not a source for the amount you are putting down, then they don't need to know. This will limit your exposure. It also prevents you from having to provide full login information when a financial institution doesn't have a way of granting read only access of the value, if that account is not relevant to your loan approval.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.