It's called a "private" repo, not a "secure" repo.
The point of a private repo is to give you control over your collaborators. It is not to provide information security. To my knowledge, Github makes no special promises about the security of private repos. The data is not encrypted on disk at Github, and Github staff can access the content of your repo.
I WOULD NOT UPLOAD SECRETS INTO A GITHUB PRIVATE REPO.
There is a sample credential file to be renamed to credentials.json, this file is now in gitignore.
That might be an improvement over checking in the json file, as I suspect (from a very brief look) that that is why the json file is checked in.
# Something in lines of this...
# TODO: Make sure the keyrings are on tmpfs, too.
# Something like export GNUPGHOME="/run/gnupg" && mkdir -p "$GNUPGHOME"
gpg2 -v --import <(echo "$GPG_PRIVATE_KEY")
gpg2 --decrypt --output /run/secrets/credentials.json lib/credentials.json.gpg
ln -s /run/secrets/credentials.json lib/credentials.json
If you host in the cloud that offers a KMS (AWS, GCP, Azure), a slightly advanced alternative is SOPS: https://github.com/mozilla/sops (you can use that with GnuPG as well)
What does the latter give you?
That's not ideal - IIRC, CircleCI in particular has a feature to run the build with SSH, so a sufficiently aware attacker still has a way to get the decrypted data. Still, an extra obstacle. Just that security's not binary.
Also, this way you can manage the secrets in your repo. No need to log in to CI and use their web UI to edit the passwords. I think that's convenient.
Sops is a better idea, because you can't extract keys from the KMS.
But if you get my secrets, you can most likely own that instance.
And I think it's worth pointing out that companies who are serious about the trade secrecy of their code tend to host their own repos. I don't think you'll find critical source code from Microsoft, Google, Facebook, Apple, etc. sitting in private repos on Github.com.
I've been using Github private repos at work since 2013. As I said, I've not seen anything from Github that says that private repos are secure enough to upload secrets. For example, this document does not distinguish between public and private repos:
I use private repos to interact with contractors. Just because I grant a contractor access to collaborate on a private repo, that doesn't mean I want them to have my api keys, passwords, etc.
I use private repos because I want a cheap and easy way to host git repos, but I don't want to bother with the public. I don't want to create the false impression that I'm open to pull requests or forking my code.
Use non-production ones on non-production servers
That's not how it works. You know at least one person will put their key in a public repo by accident. Wouldn't this give anyone complete access to their bank account? Seems like a pretty scary thing to check creds into the repo.
Because Github makes it so easy to give developers read access to repos this happens more often that you would realize, and having your most sensitive credentials (banking username and password) exposed in a repo to several different vendors is NEVER a good practice.
It's fine if you're going to use this but at least properly encrypt the secrets, or add your creds in a different file and gitignore it at the least if you're too lazy to use something like vault, credstash etc.
The reality is you're only as strong as your weakest link and there is just no use in having your weakest link be a relative unknown
Source: I built a Plaid competitor once upon a time (that obviously did not work out as well for me as it did for them) and I am currently building a bank, so I know a few things about security and vulnerabilities
I'm curious about this. I assume you are building banking software? Like a full stack?
Robinhood of course comes to mind, and then deposit insurance ofc pops up as well. Whats your plan on that?
Are you doing debit and credit cards only for the launch? Do you already have open credit lines for interbank loans, or will you need to limit credit issued based on deposits made or other assets? When you're pre-investment, how do you even have enough assets to meet liquidity requirements? What are the toughest requirements and the biggest bottlenecks before you guys can start opening accounts?
In general, you guys should have an FAQ page full of info. And you should probably do an AMA somewhere, I'm sure many people would find the experience of trying to start a bank pretty fascinating.
tbh I just did not think people would find these kinds of things as interesting as I do. I would love to start an AMA for this and go through it if people want me to do that I'm happy to try to make it happen, not sure if there's usually a formal process for setting them up on HN?
I'll do my best to address those brief questions here though. You're right that at the outset it looks like we're doing things that are better for the customer but the overall goal is to actually properly align ourselves with the customer, for instance one of the things we plan to do is pay a higher interest rate if you save a higher percentage of your income. Thus incentivizing users to have better financial habits and as a result become the exact type of borrower we would like to lend to.
The no credit apps thing is actually very simple, it just means we're using a soft pull rather than a hard pull and we still know your credit history so we're not doing anything blind.
The assets and pre-investment question is another good one. We've actually entered into an agreement to become a minority shareholder in a bank that has been in existence since 1921, as they grow (as a result of the things we're building) we intend to keep buying more shares of the underlying Bank Holding Company and to eventually become a BHC ourselves. This means the bank has the capital requirements in the short term and we are just a minority shareholder that happens to build software for the bank!
It's a structure we arrived at after looking at a ton of options and deciding this was the best possible way to test buying a bank without outlaying all the capital on the frontend.
as for the insurance etc. That is relatively explainable as a result of the above. This is an established bank that has been in existence for a very long time, we're just building software we believe will help it grow while being able to share in the upside as an actual shareholder rather than the mis-aligned incentives you see with most of the challenger "banks" in the US since they only make money from interchange.
We are in no way incentivized for our customers to spend money since our number 1 task is to grow overall assets at the bank level.
We're basically ready to start opening accounts, we should have the core ready to go for friends and family around Jan 15 and then from there we will start onboarding the ~9k signups we have as well.
The main hold up has been that Mastercard has a moratorium on new products over the holiday season so we have not been able to issue cards just yet, but we've also been building the app, getting the core provider setup etc. (We actually got a new routing number issued for the bank and a brand new core provider)
Again, if there's a sanctioned way to do an AMA or something similar I'm happy to set it up with @dang or whoever is necessary and walk through this in more detail if its interesting to folks?
EDIT: One other important piece ... we think we may actually have some paid features eventually, things like Metal cards, Free international ATMs etc. that would mean people using us more like a subscription service in some ways. For instance I would gladly pay a monthly fee to be able to have my bank become my financial conduit meaning that they would handle finding the best prices on loans, cars, houses etc. without me having to fill out an application (because they already know the answers) and I think others might be willing to pay for that as well
Random, but you using the Harry's Rails app by chance?
It seems like using your CI provider to manage the credentials would be significantly more safe than checking them into even a private repository. For instance, there are several services that will scan or otherwise access your private repos for some purpose or another, and you wouldn't want to accidentally connect them while this is also in the mix.
A pre build step that templates the credentials into a file would be pretty easy to set up in most CI systems I've used, but I have no experience in CircleCI. (maybe 10 minutes of tinkering but that's it)
Finally I should note, I am not advising anyone to store their financial credentials with any third party. But if you've already made up your mind to do so, at least consider one that's meant to handle secrets in a secure manner.
EDIT: It's actually worse than that, see comment from erichurkman below.
Current account 'balances' for people he no longer wrote personal checks to: https://www-cs-faculty.stanford.edu/~knuth/boss.html
EDIT: See the other response to this comment by
erichurkman, this is still a potential vector for unauthorized payments, transfers, and withdrawals.
I think it would be a good match.
It lets you record purchases in your spreadsheet via SMS. I should be launching it in the next month or so. It's geared towards people who want just a little more realtime ability for their current budget without switching what they use. If all goes well, I'll be expanding to other integrations (private firefly III instances, YNAB, alternative input methods, etc).
Disclaimer: I'm the author.
Second disclaimer: Idea shamelessly stolen from a comment on here months ago about what one person does for themself.
Also, I'd be interested in finding a couple of beta testers.
Edit: Aslo, I'm sorry that it looks atrocious on mobile. Should load pretty quick though ...
question for you... my credit card (Chase) lets me receive SMS/email immediately from them upon any purchase using the card, including the amount and the vendor. It's a very trivial and consistent text format, it would be super easy to parse.
Could your service learn this format and automatically populate the sheets from these messages? Maybe each user can have a dedicated secret email they can target (email@example.com) and they can configure their personal email to auto-forward those emails to your service?
Then, unlike with mint, which syncs occasionally, you would have always-up-to-date information, right from the source of truth.
Edit: Yeah, category then description. Quotes are definitely another option. I realized I got caught up and just ignored part of your post while replying...
I'd love a web application that gives me a one page financial dashboard with:
- bank account balance
- credit card balance. Due date
- list of unusual transactions I should review
- all my bills in one place, with amounts due and possibility to click through to see details
- list of upcoming schedule payment (ie mortgage, gym membership, phone service) with alert/notification of one will bounce (ie: funds insufficient so I can transfer money to the right account)
- upcoming financial obligations
Is there such a thing? Ideally self hosted.
You are doing people a huge disservice by identifying the companies you listed as "the finance industry". They are scraping data (in most cases against TOS) and exposing it as a paid API service.
It's a terrible state of affairs that easy access to ownership of this critical data is so hard to come by and has essentially forced people to give up their most valuable credentials to in a lot of cases unknown or untrustworthy parties.
At least mint has partnered with some banks that actually provide supported APIs for transaction data (Chase), but that is so far from the norm right now it makes me queasy.
Direct Connect - Your customer ID and password are not stored on Quicken servers. If you choose to use the Quicken Password Vault, we encrypt them on your computer's hard drive.
Express/Quicken Connect - Your login credentials are stored on Quicken-hosted servers. This makes updates faster for you.
It supports a few institutions. If you're a developer, its pretty easy to add more. It generates spending and balance reports, and pretty easy to slap an app (E2E encrypted of course) or local only web UI on top of it.
Also Beancount has some nice support for implementing importer scripts inside it if need be, although I haven't played with those yet.
Also, have heard of some folks using services like tillerhq.com then exporting to a plaintextaccounting tool to presumably help with dealing with messy data that comes from financial institutions. I just download and parse the csvs, using a mix of browser bookmarks and katalon scripts to aid in the process.
Personally think the goal isn’t to have a mint-like experience of constant updates, but to have a habit where you sit down once a month, update things and go through a checklist of actions / write down improvements.
If they could sell me access at a price less than $500+ a month, I'd be more inclined to trust them.
Cashflow forecasting is important for my family budget and my small business. My cashflow fluctuates quite a bit. Some months I'll bring in 90k, some months nothing. I have really high expenses for such a small business because I travel and pay contractors.
So far I've been doing this by hand, and trying to use features in Xero, plus a few expensive tools online that integrate with Xero (which do not deserve a free advertisement so I won't name them). I finally figured out if I want cash flow forecasting done right for me I'm going to have to do it myself.
It looks interesting though, I have been meaning to make a little budgeting app for myself recently so this will be a good start at the least!
I guess I'm not the target audience. The only reason I would even consider building something like this is so that I'm in full control. I have no idea what Plaid is. All I know for sure is that I don't want to sign up for it and also introduce a major dependency. I don't understand what the advantage is over Mint. I get to do more work and not be in control. Usually you can only get one of those.
As for advantages over Mint, I'm sure Mint has updated recently, but as of ~2 years ago, if you had a bank that didn't expose an API, Mint would take your credentials and more or less scrape the bank websites to get your information into their systems to do their voodoo magic to show you your stats. Plaid has done most of that legwork for you (interfacing with banks) and exposed the data via a nicer API, so you don't really have to worry about anything being wrong because of scraped data -- it's coming directly from the source.
That's my understanding, anyway.
As for how is this better than Mint? No idea. It's just a demo that shows that you could, if you wanted to. And Plaid is more or less the new standard for interacting with bank data, at least in the US.
Does anyone know if the production (non-free) level reduces the delay?
connect to your financial institutions to generate access tokens
Are these generally offered across EU? I know I haven't found a way to get access for a couple of my local (EU-based) banks I checked with, but unsure about the rest of the continent.
p.s. notably, the author of Build your own Mint project is also the creator of Vuejs
It is a Google Sheets Add-on found in the G Suite Marketplace.
Disclaimer: I am the author. It is currently under review by Google and awaiting publication. There is an email sign at the bottom of the page if you want to be notified at launch. :)
Isn’t best-practice these days to store these in the ENV?
This is another service like this. I've been using them for around 6 months and haven't had any trouble with them.
Is there reputable FOSS bank website scraper?
In line with the rest of the US's financial technology (EMV adoption, 3-D Secure) which is pretty immature, I don't think there's a concept of Open Banking enforced by regulators. Hence, no OAuth based flow to use and no standardised transactions API.
Open Banking isn't ideal and has its own issues. It's not anywhere near as revolutionary as some 'thought leaders' make it out to be. But it's better than nothing.
the appeal of a personal mint is to not share all my financial info with third-party companies, not to keep from paying a few bucks for a useful service.
tl;dr - In the US, it's illegal to mint your own money.
> Fancy interface is out of scope for this demo.