OAuth (Google Sign In / Facebook Login) is a pretty good technology in order to manage and share your information. What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed.
What is truly scary is that the banks and financial institutions have not implemented OAuth. Currently, financial data is provided to third party apps via aggregators, like Plaid and Yodlee.
Unlike OAuth, once you log into your bank with a third party app, they get an access token that allows access to your account indefinitely. There is no mechanism to monitor which apps have access to your account and ability to revoke the access to individual apps.
"What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed."
Really? This has NEVER been my experience with OAuth or similar protocols. It's always all or nothing, and I can never:
- limit the scope of any given type of permission
- find out which data was actually accessed
- limit the number of permissions given (it's all or nothing)
I realize this takes much more work than simple protocol, but it's the same as on Android: either an app takes EVERYTHING they ask for, and noone tells you how exactly they used those capabilities (no api log, no nothing), or you can't use the app.
I would much prefer a solution which lets me:
- understand full scope of data access (what does it mean that a web-app can "manage my contacts" in Google account? Manage as in... delete? Change their details arbitrarily? What?!)
- see full list, by app, what was actually accessed, and when
- be able to pick which things I want the app to do, and which I don't
- define (with groups, individual item selection or similar) which specific items I want the app to access
If the app breaks because it doesn't support partial access, so be it. But not designing this ability into the UI is basically forcing users to forever become oblivious of how technology works.
OAuth is a framework to allow access. It supports the idea of scopes, which would for example allow Google to grant an app "read rights for the last 30 days" or "read rights on contact list" but not "update contact list" etc. The scopes are entirely up to the discretion of the resource manager. In the case of Gmail, that RM is Google.
OAuth does not prescribe any feedback loop. There's nothing in the OAuth framework that says "RM must keep a record of what accesses have been made, and when; and must disclose that record to the data owner (you) upon demand, via a reasonable web UI".
It would be a good idea to have that, but it's not required, or precluded, by OAuth.
OAuth ALSO does not require that the RM give you, the data owner, the ability to review and revoke your prior granted consent. But most RMs do this.
Marshmallow is much better about this. You can actually control what apps can read, what they can write, etc. I wish it prompted you during the installation of the app, but it's getting better.
Yeah, for those that don't know, you can go into Settings -> Apps -> pick an app -> Permissions and disable them at will. I believe only apps compiled against a Marshmallow SDK version will prompt you at runtime, and there's little (or even negative) incentive for app developers to do that yet.
There's a great incentive on automatic updates. If you updated an app pre marshmallow with an extra permission it required the user to approve the update and that ultimately creates a problem with a large user base stuck on older versions.
Maybe for new apps there's less incentive to reduce access, I can't think about any other than compliance and user scrutinity. It's easy to spot bad reviews complaining about excessive permissions for some apps.
Does this mean they brought back PrivacyGuard? That was the main reason I switched to Cyanogen - to be able to use apps without giving in to their often ridiculous demands for access to my personal information.
> "What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed." Really? This has NEVER been my experience with OAuth or similar protocols
You point out one of my HUGEST frustrations, "either an app takes EVERYTHING they ask for, and noone tells you how exactly they used those capabilities (no api log, no nothing), or you can't use the app". I hate this aspect of OAuth and am so desperate for a simple solution. But I sincerely doubt one is coming-- at least not for a while...
The solution you're looking for is OAuth. It's in fact never been "all or nothing", its' always been a choice by each app and service. The reason most apps ask for everything is because 99% of users don't understand or care, and if you try to explain it to them, they'll get confused, bored, or nervous, and not use your app.
"What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed."
Users are free to revoke their their permissions at any time, but they won't be able to use an app without the permissions. You could very easily build a UI with user-variable permission scopes on account creation/management with OAuth, but no one bothers, because it would be a pain to manage on the backend for zero economic gain.
It goes beyond access to your data. With an account and routing number and access to ACH protocols anyone has essentially unrestricted access to your money.
I ran into an issue last year where I was unable to get an insurance company to stop pulling money, unauthorized and automatically, from my account. Since the amounts were different each time, my bank said I had no recourse other than to continue disputing the charges or change my account number.
So in that way it's a bit like oAuth, except you only have one key and when you revoke it, everybody loses access.
This is the CRAZIEST part of the banking system. The information to withdraw money from your account is on the bottom of the paper checks that you freely give out. Anyone with the routing number and account number can drain the entire account.
ACH fraud in the US is in the ballpark of $100M / year.
This is why I think we're only in the opening days of the FinTech shift. There's a lot to be done and a lot to fix.
"paper checks"... wow. You guys still have those? I found a book of them when I moved house recently, unused, from 10 years ago. Don't miss them even slightly.
Paper checks are the only free and universally accepted way to move an arbitrary amount of money in the US.
Most consumer spending runs through Visa/MasterCard credit or debit cards; the interchange fee is baked into the prices of consumer products. Most people have something that processes as MC/Visa (whether it is backed by a traditional bank account, line of credit, or non-check-writing account) but most people cannot accept such payments, and no one can accept them for free.
Tech-savvy consumers can pay each other small amounts of money through Venmo and Square Cash, and that is typically how smartphone-native millennials settle restaurant bills and alcohol purchases among each other. They are free, but you can't move more than a few grand. Very large organizations usually have a web portal where you can type your checking account and routing number to pull money from your bank account with 3-5 day latency through ACH. Perversely, many of them will charge a "convenience fee" for this service that is not applied to payments by check. This is also strictly less secure than payment by check, because it's at least a little bit difficult to get authentic-looking checks for account numbers that are not mine. I can type whatever I want into the box on your website.
Most consumer bank accounts have an Online Bill Pay feature with the ability to push money to organizations of this kind of size. Sometimes they work by transferring your money to a service provider who physically prints and mails a check on your behalf. Usually they're just the Push (rather than Pull) variant of ACH.
Only some banks have the ability to push ACH transfers by account and routing number, letting you pay smaller-time recipients (as long as they trust you with their account number). Sometimes you can also input an email address, and the bank emails them asking for the account details to push the payment to (because that's not reminiscent of a phishing scam at all).
There are plenty of uses cases not served by any of these options. The car dealership. The family member you're supporting. Your small-time landlord, or the friend you're subletting from. Small town governments, suburban school districts, etc. I'd guess most adults don't use checks frequently, but we still need them every once in a while.
Free (gratis) to the consumer only presumably, we have to pay at work (an SME) to deposit cash, cheques, and pay a third party for DD and CC processing.
Pretty much only get cheques from charities/clubs now, haven't written one in maybe 10 years.
What do you use to pay rent? That's the only use I still have for them, but landlords don't tend to take credit cards, and a check is easier than an envelope of cash.
Direct Deposit and/or BillPay is what I used in Australia before moving to the US.
I also miss things like BPay where I can pay all my bills via my Internet Banking portal. Moving to the US felt like a 10+ year regression in money related systems.
Yep, I moved to the US two years ago from Australia having never written a check in my life. The banking system here was probably the biggest culture shock for me.
Agreed; also in .au, the last time I presented a cheque (in 2011) the poor newbie teenage bank teller strained to recall his training. He processed it ok, but panicked so badly he accidentally handed it back. The branch manager drove out to my workplace to retrieve it from me in person...
Tell me about it, I'm trying to get an expense reimbursement from the NL to my personal bank account in the US. No IBAN, only SWIFT - nobody seems to know how to function with out antiquated system of very expensive wire transfers.
One way or another your bank has an IBAN you can use, but if it's a smaller bank, they may go through one of the larger ones. You just need to find the right person to talk to at the bank.
Even if US accounts had an IBAN (they don't, US banks don't participate in that standard) that wouldn't help. The Dutch bank can either process payments via SEPA (Single Euro Payments Area) or international wire transfer (which doesn't need IBAN but is expensive).
Maybe GP can make them use Transferwise, Currencyfair or the like?
Yeah, thats my current plan of attack, but getting the sender to use the service has been a trial. They're not too keen on non-traditional money transfers.
Also, because my wife and I use different banks but pay bills jointly, I just have her write me a check every month for her part of the bills. I then accept it using my bank's mobile check deposit feature.
While we could do ACH transfers, it's way easier to just write a check.
It amazes me the kinds of workarounds we have to do just to move money.
I am a member of two credit unions, both of which participate in the Co-Op Shared ATM network so I can use most credit union ATMs to make withdrawals and deposits. One credit union holds my regular checking account. The other has my mortgage.
Until the automatic payment gets set up, I pay my mortgage by going to a third-credit-union ATM (owned by a CU that is also on the shared ATM network) and withdrawing a pile of cash with one CU's card. I then stick that cash back into the ATM as a deposit with the other CU's card. The payment can thus be made as a "transfer" on the mortgage CU's online banking platform.
It takes minutes to do that versus approximately 3 days to do an account-to-account transfer.
3 days to do a bank transfer, ouch, that's a blast from the past. Sounds like you desperately need the Faster Payments system we have in the UK - allows you to transfer money between accounts (at different banks) instantly. Other than collections at church and the occasional business that doesn't take card, I hardly ever use cash these days.
> The Rule includes a “Same Day Fee” on each Same Day ACH transaction so that RDFIs would recover, on average, their costs for enabling and supporting Same Day ACH.
Never doubt the American banking system's capacity to gouge the customer.
It would be easier to transfer electronically if the systems existed.
I'd open the banking app or website, put in the other persons mobile phone number. Their name would be shown as confirmation. Enter the amount, press send. It's in their account in minutes, an hour at most.
If I transfer the same amount regularly, I'd click to make it a regular transfer.
If I don't know their phone number I'd use their account number. Either way, they're saved as a contact for next time.
Right; I'm not saying that using mobile check deposit is the easiest possible method for this (it definitely is not), but it is the easiest method that my major US bank supports.
You were still using them that recently? Must be fifteen since I used a cheque here in Norway. My sister still uses them in the UK though, you even see people writing them at supermarket checkouts (but not often).
I ran into this recently when my girlfriend paid her ~$5,000 credit card bill just by typing in my account/routing number. No authorization was required from me. I'm still confused and slightly outraged that this is possible.
> It goes beyond access to your data. With an account and routing number and access to ACH protocols anyone has essentially unrestricted access to your money.
Fortunately Intuit has really, really poor coverage for this. Comically poor. Plaid only supports a few FIs. Never sign up for a service with Yodlee and you're statistically covered here.
> Since the amounts were different each time, my bank said I had no recourse other than to continue disputing the charges or change my account number.
For future reference, your bank should have offered to migrate you to a new ACH number for free. It's really quite illegal for them to allow ongoing fraud to occur once you've informed them of it.
It's no different than if someone loads your Chase Debit number into an Apple Pay device and then adds biometrics (which btw: true tragedy and incredibly stupid. Chase needs to implement yellow path. I closed my accounts due to waves of fraud via this method). You're still not liable for damage, it's just scary and frustrating and time wasted.
The good news is that for personal accounts you should have 60 days to recover. Although if someone drained your account and you have to wait to pay rent, that might not be so comforting.
Businesses I believe only get one day. This ACH fraud is crazy that it exist. My landlord gives me his account number to pay rent. The routing number is trivial to google but, lucky for him, I'm not a thief.
Doesn't the bank require previous written authorisation? I've used banks in several European countries, and on all cases I had to tell my bank explicitly who could send bills to be debited to my account. Moreover, all the authorisations were revokable at any time (although charge backs were not possible).
> What is truly scary is that the banks and financial institutions have not implemented OAuth. Currently, financial data is provided to third party apps via aggregators, like Plaid and Yodlee.
Hi. I was the CTO of Level Money, that ultimately had a meta-aggregation platform on top of all the major aggregators. We were acquired by Capital One. Disclosures: complete.
Can I just put out there: every major FI has talked about OAuth2. We all know about OAuth2. It's entirely within our technical capabilities to make an API and then allow OAuth2 access. We could even make said access public. The "can they" is answered: yes we could. Yes, we have prototypes.
And yes, there are non-technical obstacles. Pardon me while I Nod Dance & Amble.
But there is a larger question about the aggregation problem. Banks are rightly concerned that if they do open these up, they'll be consumed wholesale by the major tech companies. You could imagine a world where Google partners with your bank to make a pretty amazing experience, but in the process it's almost certain that Google would have a significant upper hand. Most banks (even C1360, which I and many other people are working constantly on modernizing) simply aren't ready to work with giants like Microsoft, Google or Facebook as equals. That, sadly, will take years as these organizations realize they have to do this.
We're all in sort of a slow motion race towards this goal. Slow motion compared to the outside world (as I am all to keenly aware), that is. Internally, the process by which we do this is hugely complicated by US law and regulation. There is this wonderful thing where "regulatory capture" backfires and then you're imprisoned. For every thing that a bank charter enables, it closes off another 2-3 things that never mattered until things started being judged by their slickness in a mobile app context.
As for disconnecting from aggregators, let me tell you as an insider what you can do. Change your password. No really, change your bank password. EVERY major aggregator has a flow that requires they respect this at a technical level. If that fails, it's on your bank and you should shout at them VERY loudly.
But before you do, make sure you are ready to prove yourself as a banker. What will happen with most aggregators is that they'll have to decide, "is this person actually gone or is this stupid web scraper just having a bit of a problem?" They'll try and log in again, at least once in most cases. If you have hooked up multiple services (or the same service multiple times), these will trigger account lockouts just like any failed web login would.
> What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed.
One thing to know is that this is entirely up to the implementer. As others have noted, some sites do this, some don't. The concept of an access token having some "scope" of authorization is not limited to OAuth – there's no reason this can't be done with any other sort of authorization protocol. Bank security procedures are bad and they should feel bad but I'm not sure OAuth is the right solution.
As someone who has recently developed an app with Google OAuth I'd like to second this. Google lets you register which servers the auth tokens can be used from, which means that even if the application database gets hacked your data is safe. Tokens are also rate limited at both the user and application level, which means that even if there is a zero-day attack targeting your web servers, you can set up monitoring software to automatically revoke your tokens so that no more than a tiny percentage of data is at risk of getting exposed.
Although it can be dangerous to implement your own OAuth as a provider due to the complexity of the protocol, if you're merely granting an app access to your Facebook or Google account then as a user the security story is quite good.
> Google lets you register which servers the auth tokens can be used from, which means that even if the application database gets hacked your data is safe.
This works when there are places of origin it can track but if you're handling tokens via a mobile device it's not as easy.
Regardless I wouldn't say your data is "safe". If someone broke into your system and you cached Google's data (which you probably did; federated queries suck) then your data isn't safe at all. Even the token can be re-used (I mean if someone broke in I don't see why they couldn't run stuff on the same server or even looking like it came from the same server).
UK in particular has the worst bankins systems and services I've yet seen in my life. Many European countries, including these from eastern Europe, have a banking industry that's 100 years ahead of UK (on example is where you can't just walk in to a bank and have your thing done - you have to schedule a visit, often weeks in advance. And opening an account - real nightmare, good luck with that, if you're not born&breed brit). However, said that, I do understand that this is the result of UK banks being actually oldest ones and the usual inertia of 'working' things made the changes way slower than the rest of the world.
A while back, I heard about a scam where individuals were targeted by someone at one of the mobile phone providers. They logged in with their bank details, rerouted the authentication messages to their phone, and proceeded to do as they pleased. The "victim" had no idea it was happening as all the auth and notification SMS's being sent to their mobile number were being routed to someone else entirely.
How should the bank handle that. Sounds like one needs to send a crypto signed ACK before the bank enable access with the reauth code. Good companies at least send an ack email after the fact.
Not much seems to have been done about verifying the receiving end of communications - when I call a company on the phone there's no default protocol to confirm their credentials (like per user passwords for the business).
I don't see how OAuth could mitigate the problem stated in the article. Once you allow some malucious app to your secret zone, it's done. Your data is now theirs. Doesn't matter if it was OAuth authorisation or you gave them your password (although the second one is probably worse).
Yes, but if they're already downloaded the last decade of your email history... well, I'm not sure how much it helps that you're blocking them from further access. What if they start emailing "helpful" links, invitations, whatever to everyone in your contact list? What if they are rather less strict about how they secure their (your) data, and they're employees spend lunch breaks poking around for public figures who might have interesting histories?
These sharing mistakes are hugely easy to make, and sometimes have unpleasant consequences even with no malice intended on the app company's side.
Someone in our company tried out do.com several months ago, and granted it access to our company directory in Google along the way. We didn't end up using the service; but unfortunately after a while of inactivity they started sending "invitation" emails to not just users on our own domain, but also Google Groups we have set up... some of which include customers of ours who were not at all amused to see that (it appeared) we had exposed their addresses to some random 3rd party without permission.
Apologies all around, of course, but these days it's simply hard to be paranoid enough about this sort of thing. Gmail & Google Apps have tons of useful apps you can add with a few clicks; but what are you actually risking, using them?
If you consider Coinbase a "bank" for Bitcoin, then they have implemented OAuth, quite nicely. Users can review permissions and revoke access in their Coinbase account. The link shortener I run relies on it to transact with my users (https://credhot.com). I also use it for logging in, but that will go away soon in favor of social logins.
What is truly scary is that the banks and financial institutions have not implemented OAuth. Currently, financial data is provided to third party apps via aggregators, like Plaid and Yodlee.
Unlike OAuth, once you log into your bank with a third party app, they get an access token that allows access to your account indefinitely. There is no mechanism to monitor which apps have access to your account and ability to revoke the access to individual apps.
I posted about this a while back: https://medium.com/@johnie/let-my-financial-data-free-74f3b7...