nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Password Vault

MSStateDawg

What drives the need to store a password in the vault? Is this something driven by the F.I.?

I see some are not required (e.g. Amex, Discover, PennyMac, etc.). Is this because the connection method is EWC or EWC+?

Fidelity is required but the method appears to be DC.

Find more posts tagged with

Accepted answers

Chris_QPW

It would only serve as a protection against unauthorized persons using your Quicken data file to start an OSU download.

As currently implemented, it can't even be used for that. If all the accounts, you have in your Quicken data file are either Express Web Connect or Express Web Connect + Quicken will not prompt for the Password Vault password when you run One Step Update.

All comments

UKR

Used to be that the Password Vault held the bank passwords for all activated bank accounts, no matter what download protocol was used.
Nowadays, only Direct Connect - connected bank accounts are held in the Password Vault.
For EWC and EWC+ connected banks Quicken uses a different procedure to authenticate. Those passwords are not stored in Quicken.

Once all DC - connected accounts have been converted to EWC/EWC+ or are no longer activated, theoretically, the Password Vault can become obsolete. It would only serve as a protection against unauthorized persons using your Quicken data file to start an OSU download.

Chris_QPW

It would only serve as a protection against unauthorized persons using your Quicken data file to start an OSU download.

MSStateDawg

https://community.quicken.com/discussion/comment/20382518#Comment_20382518

Yeah, out of about 20, I have one F.I. that doesn't offer EWC…Fidelity. That one F.I. therefore requires me to enter the vault password which is incredibly annoying.

If DC is considered a "better" connection method due to it's added functionality than EWC offers then the logic seems backward to me of storing the password locally in the vault. If I understand it correctly, EWC+ is the method which has you authenticate at the F.I. website which then passes an auth token back to Quicken essentially eliminating storage of creds in the Quicken file and reducing risk of cred theft. DC exposes that risk by requiring cred storage in Quicken, but offers more features. Again, backwards in my brain.

Seems to me that a more advance connection method should also carry a more advanced security model.

Chris_QPW

Well, there is a lot of history to this, and it isn't as clearcut as one might think.

Of all the connection methods Express Web Connect is the worst. It only exists because of "depression".

I will start with QIF since it came first. It was never meant as a connection method, it was designed to help the support people to help people with problems in their data file. It was never standardized. Other companies/financial institutions just started using it. Things like the date from foreign countries might wrong and people including Intuit later added things to it that other may or may not have supported.

Then there was the OFX standard. Which as soon as it was created put in their "extension" (some extra fields for identifying "participating partners") called it QFX and charged financial institution for setup and support of it. That probably saved Quicken, since Intuit had more profit (Microsoft didn't do this and they abandoned Microsoft Money), but it is also an extra cost to the financial institutions, which of course they didn't want to pay, and every effort to pass that on to their customers has resulted in most Quicken users refusing to pay any fees. Note that Quicken users are a small percentage of any financial institution's customers, but with Quicken users demanding this for free, the cost was shared by all their customers.

It should be noted that the OFX/QFX protocol has its own security model. You aren't logging into the financial institution's web server; you are logging into an OFX server. The newest versions of the OFX protocol do support rotating security tokens so that no username/password would have to be store, but the financial institutions (or Quicken for that matter) have not adopted newer versions of the OFX as they came out. Some financial institutions are still using 1.01 the very first public release of it. 2.3 is the current version.

https://www.financialdataexchange.org/FDX/About/OFX-Work-Group.aspx?WebsiteKey=deae9d6d-1a7a-457b-a678-8a5517f8a474&a315d1c24e44=2#a315d1c24e44

Out of the more than 35,000 financial institutions in the US alone, only about 4,500 adopted QFX/Direct Connect, that highest, and that number is probably about 2,000 these days and going down.

That brings us to Web Connect. In the OFX/QFX protocol Quicken sends a request for the transaction data, and the OFX server returns that. Basically, Web Connect is just the financial institution somehow generating that "reply" when requested by the user on their website as an OFX/QFX the user downloads and imports into Quicken.

So, if not all the financial institutions would support OFX/QFX/Direct Connect what do you do?

You go out and get an agreement with them to allow your server to log in to their website as if you were that user. That is Express Web Connect in a nutshell. And the history explains the term "Express Web Connect", as in at first the agreement would have been to get a financial institution to use Web Connect but allow Intuit to use their servers to login as the user and get that QFX file. It is "Express" to the user since they wouldn't have to log in to the website. But predictively most financial institutions refused to create QFX files. And so, the agreements changed "per financial institution" to "some format", that Intuit would then convert to the QFX format and send that to Quicken. As security concerns started coming up, the financial institutions made it harder and harder to log into their websites and note a lot of focus was on defeating "scripts/programs" from logging in because that is how they figured the hackers would do it. No doubt this is the number one reason that Express Web Connect fails. Other reasons are that the financial institution might change their website in a way that breaks whatever agreed method doesn't work anymore, posted ad that, changed page, …

Express Web Connect is also the worst because your username and password are saved on Intuit's server. And it should be noted that Express Web Connect isn't alone here, there are many other "aggregators" all with their own "agreements". Even for Intuit, Mint, uses a different "agreement" for instance.

That brings us to Express Web Connect +, well that is just what Quicken Inc/Intuit are calling it. The actual protocol is called FDX, or at least the part between Intuit and the financial institution.

Imagine you are the financial institution, and you have multiple "aggregators" that want to access your customer's data. Quicken users seem to think that they are the only game in town just they aren't. So, instead of adopting OFX and using the latest version they get together and create a new protocol.

https://financialdataexchange.org/FDX/FDX/About/About-FDX.aspx?hkey=dffb9a93-fc7d-4f65-840c-f2cfbe7fe8a6

BTW note that this is same website as for OFX. The same organization took over the support of OFX in the US.

(Note that support of OFX and/or one other protocol has been required for every financial institution in the EU for about 10 years now)

This is a fully modern, standardized, but closed protocol. You won't be able to access the specs on it without signing a non-disclosure.

But also note this isn't all of "Express Web Connect +". It is just the connection between Intuit and the financial institution. Some (they aren't telling us how much and for how long) of your transactions/balances and such are stored on the Intuit servers. Quicken no longer talks directly to Intuit. This is the case for both Express Web Connect and Express Web Connect +. Instead, Quicken "syncs" with the Quicken Cloud Service (QCS)/Quicken Cloud dataset (same place where Web and Mobile get their data). And it is that server that actually connects to the Intuit server.