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?

HPierce
  • 401
  • 1
  • 4
  • 5
  • 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
  • Typically when doing this their are alternative ways to provide verification. They are more work, but if you are uncomfortable with the electronic method, they will work just fine. – noslenkwah Dec 18 '19 at 15:35
  • That looks like plaid.com's interface. They're legit, and widely used, but it's still not something I'd be hugely comfortable with. – ceejayoz Dec 18 '19 at 15:42
  • 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
  • @HPierce Does the form have javascript do the authentication to vanguard's api to generate a token, which is then sent to the 3rd party's server? or is the id/password sent directly to the server of the 3rd party? – さりげない告白 Dec 19 '19 at 01:08
  • @さりげない告白 it looks like ROPC, meaning id/password are sent. Check my answer for a link to what ROPC is. – Mars Dec 19 '19 at 01:59
  • 4
    "Should I provide my password" -> No, never, under any circumstances, to anyone. – njzk2 Dec 19 '19 at 04:46
  • I just tried adding an external account to my ETrade account, and they prompted for my Capital One username/password. It's the first time I've ever seen this. Fortunately they also offered a "manually add account" option which allowed me to do it the traditional way by specifying the routing number and account number. – 7529 Mar 29 '20 at 17:34

7 Answers7

59

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.

Ray Butterworth
  • 1,566
  • 4
  • 7
  • 16
  • 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 01:58
  • (In case you saw my last comment, forget it. I'll instead offer suggestions). This service doesn't merely ask to confirm Identity, it likely asks for permission to access some "resources". In this case, the access is likely READ for your brokerage info (not login). – Mars Dec 18 '19 at 11:47
  • In this case, there are two things you probably want to look out for. 1) Does the site properly generate a popup to log in? If so, it's probably safely opening the login from the account (chase, brokerage) and waiting for a response from them. 2) After logging in, it's likely that chase or your brokerage will ask if you wish to give Finicity permission to view something (not write). If they do, you should check those permissions – Mars Dec 18 '19 at 11:50
  • If the popup shows your url, you should also check that too, to verify that it's the real site – Mars Dec 18 '19 at 12:02
  • 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
  • Even if Vanguard itself is not the one asking for the credentials, it is still very common for third party providers to directly ask for the credentials, and use them to access web services provided by the broker or bank. No, it is not as safe to do it this way, but unfortunately it is the only option available when most brokers and banks still do not offer Oauth (like Chase does in this case) as an option to log on to their systems. So this answer is fundamentally wrong, in most cases today, it IS legitimate to provide your password. –  Dec 18 '19 at 16:22
  • 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
  • 1
    @SpehroPefhany Thanks. I was weary when I wrote that :) – Mars Dec 19 '19 at 01:52
  • @AxiomaticNexus Harper pointed out on my answer that using the password is possibly against ToS, so it's wrong to to call it "legitimate." A better term would be "common" – Mars Dec 19 '19 at 02:01
  • @AxiomaticNexus this is "the ends justify the means" logic. Your third party site wants to surveil customer's account, the bank won't cooperate, therefore you're entitled to "ask the user for password" and "log in under false identity" and "use automated means to scrape bank's site". *Because your business objectives are more important than the law, eh?* The only correct option is "you don't do that thing". You are taking it as axiomatic that since it is done, it must be legal. Nosirree! – Harper - Reinstate Monica Dec 19 '19 at 02:53
  • @Harper-ReinstateMonica You're wrong in assuming this is all done without the bank's consent. This is how they explicitly designed their APIs for third-parties to access. Before OAuth, this is literally how all authentication worked. Did you not use to type in your username and password into your local e-mail client? There's nothing sinister about this, just outdated. –  Dec 19 '19 at 15:00
  • @Mars The method is still legitimate, even if also uncommon today. Now, if the third-party is violating its own ToS by using this method of authentication, then that's a whole different topic. –  Dec 19 '19 at 15:04
  • @AxiomaticNexus Equating ”an email client on a local PC" to "a third party website" is disingenuous. The security models are totally different, and that is obvious. Quite often these third party sites are not using an API but are doing a hard web scrape. So no, giving your creds to site X to scrape site Y is not "how it was always done". – Harper - Reinstate Monica Dec 19 '19 at 16:53
  • @Harper-ReinstateMonica The security risks you're taking by giving your credentials to an e-mail client are exactly the same as giving your credentials to a third-party website. You're trusting your credentials to the entity behind the development of the e-mail client, and hoping that they do not misuse them later on. Also, I'm not sure about the scraping vs API comment, but even if that is the case, the point I'm trying to make is that a site asking for your credentials for another site, on its own, is not sufficient reason to suspect anything nefarious is going on. –  Dec 19 '19 at 18:31
  • @Harper-ReinstateMonica Also, I never said that giving your credentials to site X to scrape site Y is how it was always done. Read closely; I don't even talk about scraping at all. –  Dec 19 '19 at 18:34
  • @AxiomaticNexus It's not the third party violating it's own ToS, it's you violating the service's ToS by using a third party. That's not "legitimate" – Mars Dec 20 '19 at 00:18
  • @AxiomaticNexus You didn't talk about scraping at all, and that' the point. It doesn't appear that an external API was created by Vanguard, hence the need to log in as the user. – Mars Dec 20 '19 at 00:22
  • @AxiomaticNexus And an email client is different. The credentials aren't stored on a third party server, can be cleared by you at any time, and don't create logs on a 3rd party server. In fact, there's likely no interaction with a third party at all, other than to download/update. And email services have don't forbid programmatic access of the data in their ToS. – Mars Dec 20 '19 at 00:24
  • @AxiomaticNexus A method that would equate to your email client example would be if Finicity gave you a downloadable in which you then sign in, it generates a text report, then you manually email that text file. But as stated above, even this would still be against the ToS, which forbids even screenshots – Mars Dec 20 '19 at 00:26
  • @Mars Yes, all of those things are true in the case of a good actor e-mail client, but remember, here we are concerned about bad actors, not good ones. A bad actor e-mail client can just as easily send the credentials to a third-party server without your consent. So, whether giving your credentials to an e-mail client or a third-party website, the risk is the same. It all comes down to this: do you or do you not trust that entity to handle your credentials? –  Dec 20 '19 at 01:53
  • @AxiomaticNexus Here we are not only concerned about bad-actors, we're also concerned about stupid-actors, and bad-4th-party-actors. – Mars Dec 20 '19 at 01:59
  • @AxiomaticNexus Also, with an email client, for those with the technical capability, we can know every single transmission going on. For those with the technical capability, it's not a complete blackbox. With an online service, technical capability or not, it's 100% a blackbox. We have no idea at all what they're doing – Mars Dec 20 '19 at 02:04
  • @Mars The developers of the e-mail client can be stupid actors as well, not just bad actors. Yes, with enough technical knowledge you can technically see every transmission from and into the client, but the average user does not have that knowledge, and if the vendor decides to encrypt the transmissions, even fewer have the skills to reverse-engineer the software to pull out the encryption keys. So again, to the average user, the risk is still the same. –  Dec 20 '19 at 14:48
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).

chrylis -cautiouslyoptimistic-
  • 509
  • 4
  • 9
  • @Mars If the screenshot you showed is from Vanguard's site (it doesn't look like it) As a note, you should link "ROPC" in your answer to some sort of documentation; I've never heard of the term and have written screen-scrapers in four languages. – chrylis -cautiouslyoptimistic- Dec 18 '19 at 13:04
  • Thanks for the tip! I edited it in. I just realized it probably isn't ROPC though. ROPC would be similar in that it can limit the resources accessed, but since you mentioned scrapers, I realized this may actually be a complete login-and-scrape job – Mars Dec 19 '19 at 02:05
  • 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 04: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 -cautiouslyoptimistic- Dec 19 '19 at 04: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 04: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 04: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 08:07
  • Many banks and other financial sites have an option for providing read-only access with a separate set of credentials to 3rd parties, like lenders or management tools, for this exact purpose. Great explanation. – brichins Dec 20 '19 at 17:24
  • OP describes two interactions: 1) the one involving chase - which they think is alright -, and 2) the one with vanguard - which they feel is fishy. Your answer largely focuses on 1), while OPs question is mainly about 2). Given this, I think it's a bit misleading to start off with 'this is common'. You might want to consider splitting your answer into two parts (eg with appropriate headings), to avoid leaving the impression that supplying your credentials directly to third parties is commonly accepted practice (as opposed to using oauth, etc). – tim Dec 20 '19 at 20:43
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.

adam.baker
  • 393
  • 2
  • 7
  • 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
4

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.

TTT
  • 47,155
  • 7
  • 99
  • 151
  • 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 01:36
  • @eis no, that's OAuth/OpenID or Facebook's proprietary equivalent. That was developed primarily as a SSO method, but secondarily to provide an alternative to password sharing. – Harper - Reinstate Monica Dec 19 '19 at 01:46
  • @Harper-ReinstateMonica I'm fairly certain the old version of OAuth on this site was integrated right into the page, instead of the current way of redirecting you to a G or FB page, and then redirecting back (which is much better). When it was in the page I think it would be difficult to explain to a non-technical user how to tell if the OAuth popup was spoofed or legit. Even now, everyone has to look closely at the redirect to make sure the site has the correct URL, and I'm not sure if a non-technical user would notice if accounts.google.com was actually accounts.google.com.xyz. – TTT Dec 19 '19 at 03:25
  • @Harper-ReinstateMonica IMHO, the rule of "Never share your pw" is violated by OAuth. Of course we know the difference but the non-technical user simply learns: "When I'm on site X I sometimes have to type in my Google user/pass, and I know that's OK..." – TTT Dec 19 '19 at 03:39
  • @TTT I was involved in one of the companies that developed OpenID, which had a huge problem with site X taking our users' credentials to scrape users' content on our site. So developers were very sensitive to that, i.e. OpenID/OAuth was engineered to avoid that, from day one. A huge part of the point was to stop that vile practice. If it had not been that way, I would have been appalled and yelled my head off. I did not. There may have been early stupid implementations, like a chromeless popup or an iFrame, but I guarantee it was not as you recall. Or, it wasn't OAuth. – Harper - Reinstate Monica Dec 19 '19 at 03:45
  • @Harper-ReinstateMonica good to know! – TTT Dec 19 '19 at 03:54
  • 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
  • @eis that sounds like pronoun trouble, then. (On StackExchange? What are the chances? :) Obviously site X is expected to ask for site X's password... – Harper - Reinstate Monica Dec 19 '19 at 16:44
  • @Harper-ReinstateMonica - I'm thinking along the same lines as eis. Site X is asking for you to supply your G or FB credentials, not necessarily site X's password. – TTT Dec 19 '19 at 17:37
  • @TTT If Site X does a G/FB login, it causes an actual G/FB page to pop up, and you enter your credentials there. (you might not notice this technical sleight of hand; and it's possible to actively conceal it using iFrames or chromeless windows, although that would be moronic). Behind the curtain, this "public key cryptography" sort of thing is happening, it's complicated. But Site X is given a token that'll work only for it, for your data. Site X never sees your G/FB password, which would be a nightmarish security hole, egads! – Harper - Reinstate Monica Dec 19 '19 at 18:08
  • @Harper-ReinstateMonica - Of course. I'm saying how it works is irrelevant. I know how it works, you know how it works, but does a non-technical user understand that? How do you reconcile "Never give away your credentials to another site" and "it's ok to give your credentials to a different site as long as it looks like X". Any site can spoof a G/FB login and make it look sort of like that. At least close enough to fool a non-technical user. – TTT Dec 19 '19 at 18:16
  • @TTT Listen to yourself. You're telling users to go ahead and give their passwords to third party sites because you don't trust them to know the difference. – Harper - Reinstate Monica Dec 19 '19 at 19:47
  • Regardless, it's a TOSvio: "To protect your Google Account, keep your password confidential" and "You must: Not share your password, give access to your Facebook account," By the way, I'm not your downvoter... – Harper - Reinstate Monica Dec 19 '19 at 19:48
  • @Harper-ReinstateMonica hmmm. That's not what I'm saying. I guess I need to reword my answer if that's how you're interpreting it. – TTT Dec 19 '19 at 20:13
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.

Mars
  • 298
  • 2
  • 7
  • 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 00: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 00: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 00:30
  • @Harper-ReinstateMonica The first comment doesn't seem relevant, it just establishes who holds responsibility if something goes wrong. – Mars Dec 19 '19 at 01:29
  • @Harper-ReinstateMonica But the second comment is gold – Mars Dec 19 '19 at 01:31
  • The "..." is simply a section separator, not missing text. Yeah, I don't know if "responsible for" means "obliged to", I just inferred that. – Harper - Reinstate Monica Dec 19 '19 at 01:34
  • @Harper-ReinstateMonica This would still be very hard to enforce (and under what punishment?). It also can't be precluded that Finicity doesn't have the permission "expressly authorized by Vanguard in writing". I don't know enough about either institute to comment on that likelihood – Mars Dec 19 '19 at 01:49
  • 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 03:01
  • @Harper-ReinstateMonica I'll edit in a little bit, let me know if I state some inaccuracies – Mars Dec 19 '19 at 04:09
  • @Harper-ReinstateMonica Nevermind, I can't think of what to say, so I'll leave it out. I can't think of any practical examples when that makes a difference, can you? If a loss occurred due to actions by User('s account), then it seems fairly obvious that User should be held accountable. If it was the 3rd party that did the actions, via User's account, then it would still be on User to seek damages from the 3rd party after paying the damages owed to Vanguard – Mars Dec 19 '19 at 04:17
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.

zimba
  • 1
  • 1
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.

mhoran_psprep
  • 139,546
  • 15
  • 193
  • 389