This is FUD. Lots of Plaid-based connections only allow reads. This is a regulated industry, and the fallout reputationally might be tough, but consumers are well-protected.
Is it, though? I’ve given Plaid the user name and password to my bank account. The same set of credentials that I use to log in, to pay bills, transfer money, etc. Plaid stores this information for future use in some sort of reversible encryption. So now we trust Plaid to keep both their data set of user names and encrypted passwords secure, and also to keep their decryption keys secure. Forget that noise. Like the previous commenter , they’re one breach away from exposing millions of bank account credentials. It doesn’t matter if the Plaid API is read only for the integration side - somebody has MY credentials, and that’s not read only.
Eh, it’s herd security. Hackers with credentials may pick off a few people’s accounts, but the odds of you being hit are low since it’s a hard problem to scale and there’s so many targets.
If all Plaid's customers accounts were emptied in one go, I suspect banks would reverse those transactions and tell any counterparties that lost money to pound sand.
I believe the cool kids call it a "hard fork", as in, if you are the bank that received the stolen funds and let someone withdraw them, you get forked, hard.
How is that enforced? What is the technical basis that enforces read-only access using user/password auth? Especially since that user/password auth is used by an end user to do "write"-type actions?
It's enforced - sometimes - by the bank. My bank provides read access to everything with a username + password, but to transfer money or update details requires an SMS confirmation.
I remember a presentation by the head of security of an Internet-only bank years ago, about banking malware.
The latest malware was a man-in-the-browser style one: it intercepted your input and changed what you saw on-screen. This was used to defeat extra authentication: the malware inserted a (fake) deposit (something like "yearly subscription mr. X" for $2134.56) into your on-screen total and phoned home. The victim was then called by a mr. X who claimed to have accidentally swapped two digits in a transfer, and that the bank had said they can't fix it because the target account was a valid account. All they could do was exceptionally give out the phone number of the receiving side. Would you be so kind to rectify the situation?
Since mr. X had all the details correct (amount, statement on transaction), the victim would initiate and authenticate a transfer. No way for the bank to detect, as this wouls be a genuine transfer order by the account owner.
To be clear: the attack requires a victim whose browser is hacked and an associated phone number. That seemed like a tall order to me, but apparently not tall enough to stop this attack from being integrated into multi-banking malware.
In short: read-only access is good, but not sufficient to prevent all attacks.
That type of hack doesn’t require the user/password. It’s also on the same league as the Nigerian Prince, just appealing to kindness rather than greed.
Idiots fall for these scams all the time, password not needed.
A couple of my banking institutions let me generate a read-only set of credentials for this sort of purpose.
Citi and Capital One have OAuth flows that Plaid supports, too, which tends to make me angrier at the banks than Plaid; the need for this stuff has been clear for a decade now, but only a few have added OAuth or similar.
AFAIU, there are still zero (0) consumer banking APIs with Read-Only e.g. OAuth APIs in the US as well?
Banks could save themselves CPU, RAM, bandwidth, and liability by implementing read-only API tokens and methods that need only return JSON - instead of HTML or worse, monthly PDF tables for a fee - possibly similar to the Plaid API:
https://plaid.com/docs/api/
There is competition in consumer/retail banking, but still the only way to do e.g. budget and fraud analysis with third party apps is to give away all authentication factors: u/p/sqa; and TBH that's unacceptable.
Traditional and distributed ledger service providers might also consider W3C ILP: Interledger Protocol (in starting their move to quantum-resistant ledgers by 2022 in order to have a 5 year refresh cycle before QC is a real risk by 2027, optimistically, for science) when reviewing the entropy of username+password_hash+security_question_answer strings in comparison to the entropy of cryptoasset account public key hash strings:
https://interledger.org/developer-tools/get-started/overview...
> Sender – Initiates a value transfer.
> Router (Connector) – Applies currency exchange and forwards packets of value. This is an intermediary node between the sender and the receiver. {MSB: KYC, AML, 10k reporting requirement, etc}
> Receiver – Receives the value
Multifactor authentication: Something you have, something you know, something you are
Multisig: n-of-m keys required to approve a transaction
> For purposes of Interledger, we call all settlement systems ledgers. These can include banks, blockchains, peer-to-peer payment schemes, automated clearing house (ACH), mobile money institutions, central-bank operated real-time gross settlement (RTGS) systems, and even more. […]
> You can envision the Interledger as a graph where the points are individual nodes and the edges are accounts between two parties. Parties with only one account can send or receive through the party on the other side of that account. Parties with two or more accounts are connectors, who can facilitate payments to or from anyone they're connected to.
> Connectors [AKA routers] provide a service of forwarding packets and relaying money, and they take on some risk when they do so. In exchange, connectors can charge fees and derive a profit from these services. In the open network of the Interledger, connectors are expected to compete among one another to offer the best balance of speed, reliability, coverage, and cost.
> Hopefully individuals will be able to use the Open Banking APIs to access their own data directly, but it looks like accreditation will be required, so probably not.
When you loan your money to a bank by depositing ledger dollars or cash - and they, since GLBA in 1999, invest it and offer less than a 1% checking interest rate - and they won't even give you the record of all of your transactions as CSV/OFX `SELECT * FROM transactions WHERE account_id=?`, you have to pay $20/mo per autogenerated PDF containing a table of transactions to scrape with e.g. PDFminer (because they don't keep all account history data online)?
E.g. GNUcash (open source double-entry accounting software) supports HBCI (and QIF (Quicken format), and OFX (Open Financial Exchange)).
https://www.gnucash.org/features.phtml
HBCI/FinTS has been around in Germany for quite awhile but nowhere else has comparable banking standards? I.e. Plaid may (unfortunately, due to lack of read-only tokens across the entire US consumer banking industry) be the most viable option for implementing HBCI-like support in GNUcash
ISO20022 is "A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives" https://www.iso20022.org/
What data format does the FTC CAT Consolidated Audit Trail expect to receive mandatory financial reporting information in? Could ILP simplify banking and financial reporting at all?
FWIU, RippleNet (?) is the only network that supports attachments of e.g. line-item invoices (that we'd all like to see in the interest of transparency and accountability in government spending).
W3C ILP: Interledger Protocol. See links above.
Of the specs in this loose category, only cryptoledgers do not depend upon (DNS or) TLS/SSL - at the protocol layer, at least - and every CA in the kept-up-to-date trusted CA cert bundle (that could be built from a CT Certificate Transparency log of cert issuance and revocation events kept in a blockchain or e.g. centralized google/trillian, which they have the trusted sole root and backup responsibilities for).
Though, the DNS dependency has probably crept back into e.g. the bitcoind software by now (which used to bootstrap its list of peer nodes (~UNL) from an IRC IP address instead of a DNS domain).
FWIU, each trusted ACH (US 'Direct Deposit') party has a (one) GPG key that they use to sign transaction documents sent over now (S)FTP on scout's honor - on behalf of all of their customers' accounts.
