Timeline for Should I provide my username and password for my brokerage account to my mortgage lender to verify my assets?
Current License: CC BY-SA 4.0
31 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 20, 2019 at 14:48 | comment | added | user19035 | @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, 2019 at 2:04 | comment | added | Mars | @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 | |
| Dec 20, 2019 at 1:59 | comment | added | Mars | @AxiomaticNexus Here we are not only concerned about bad-actors, we're also concerned about stupid-actors, and bad-4th-party-actors. | |
| Dec 20, 2019 at 1:53 | comment | added | user19035 | @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, 2019 at 0:26 | comment | added | Mars | @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 | |
| Dec 20, 2019 at 0:24 | comment | added | Mars | @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. | |
| Dec 20, 2019 at 0:22 | comment | added | Mars | @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. | |
| Dec 20, 2019 at 0:18 | comment | added | Mars | @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" | |
| Dec 19, 2019 at 18:34 | comment | added | user19035 | @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, 2019 at 18:31 | comment | added | user19035 | @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, 2019 at 16:53 | comment | added | Harper - Reinstate Monica | @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". | |
| Dec 19, 2019 at 15:04 | comment | added | user19035 | @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, 2019 at 15:00 | comment | added | user19035 | @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, 2019 at 2:53 | comment | added | Harper - Reinstate Monica | @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! | |
| Dec 19, 2019 at 2:01 | comment | added | Mars | @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" | |
| Dec 19, 2019 at 1:52 | comment | added | Mars | @SpehroPefhany Thanks. I was weary when I wrote that :) | |
| Dec 18, 2019 at 18:23 | comment | added | Reimus Klinsman | 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 | |
| Dec 18, 2019 at 17:25 | comment | added | Spehro 'speff' Pefhany | @Mars "wary", not "weary" unless you're just tired of the whole thing. | |
| S Dec 18, 2019 at 17:08 | history | edited | Ray Butterworth | CC BY-SA 4.0 |
Reworded.
|
| S Dec 18, 2019 at 17:08 | history | suggested | Sam | CC BY-SA 4.0 |
The removed statement is not true, not helpful to the answer, and extraordinarily dangerous.
|
| Dec 18, 2019 at 16:22 | comment | added | user19035 | 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, 2019 at 15:30 | review | Suggested edits | |||
| S Dec 18, 2019 at 17:08 | |||||
| Dec 18, 2019 at 12:18 | comment | added | Mars | (The Chase one sounded legit though, as I would expect them to provide that sort of API) | |
| Dec 18, 2019 at 12:06 | comment | added | Mars | 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. | |
| Dec 18, 2019 at 12:02 | comment | added | Mars | If the popup shows your url, you should also check that too, to verify that it's the real site | |
| Dec 18, 2019 at 11:50 | comment | added | Mars | 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 | |
| Dec 18, 2019 at 11:47 | comment | added | Mars | (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). | |
| Dec 18, 2019 at 2:42 | history | edited | Ray Butterworth | CC BY-SA 4.0 |
Mention indirect sign-on.
|
| Dec 18, 2019 at 2:36 | history | edited | Ray Butterworth | CC BY-SA 4.0 |
Mention indirect sign-on.
|
| Dec 18, 2019 at 1:58 | comment | added | milk | 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. | |
| Dec 18, 2019 at 0:15 | history | answered | Ray Butterworth | CC BY-SA 4.0 |