Just as one data point, Mercury has hired maybe ~120 Haskell engineers in the last 4 years. Some of that is reflected in these job posts but we definitely hired a lot more than we posted on the subreddit.
It’s also a huge vector for actual phishing, especially because google ads doesn’t use puny code, so it’s easy to buy ads for sites that differ by just a diacritic
That's how my stepdad got hacked. He didn't understand bookmarks or urls or homepages, so he just opened his browser at google.com, searched for the name of his bank, clicked the first ad, and went to log in. Usually that worked for him, but once, he got a scam site, and he was on the phone with a call center in India giving them remote desktop access before a single alarm bell went off in his head.
Granted, it's partly my fault for letting a loved one be that computer un-savvy, but that kind of ad should have been detected and blocked before it was ever served.
Agreed. There are so many failures on Google’s end to let this happen. One of which was allowing the advertiser to display a legitimate URL in the ad while redirecting to an illegitimate one. I really hope this isn’t the case any more.
I sent my father in law an article the other day, and he wound up clicking a scam ad that got his computer hacked. He showed it to me, it wasn't the most obviously scammy ad I've seen- plenty of people who didn't grow up with the internet might have fallen for it!
But anyway, on my laptop, the article was just clean text and a byline with some well-formatted images.
Failing to install ublock on your parents computer is a form of abuse! :-)
- For customers on our partner bank Evolve, this was bumped from 1mm to 3mm as of this morning. You get this automatically if you have accepted the T&Cs for the sweep program already; if you haven't you can do so at: https://mercury.com/settings/vault
- For customers on our partner bank Choice, you're still at 1mm FDIC insurance. We are working on getting you an Evolve savings account (or getting increased coverage from Choice) by tomorrow morning, or you can keep excess funds in Treasury (see below)
# treasury
- We also have a product called Mercury Treasury. This allows you to invest in mutual funds, the safest of which is a Vanguard Treasury Money Market fund (VUSXX), which invests primarily in short-term U.S. Treasury bills https://investor.vanguard.com/investment-products/mutual-fun...
- They're not part of any fractional reserve system like with banks; every share of a mutual fund you hold is in your name and Apex can't lend against it (unless you give them permission which would be weird)
- You can automatically sweep any funds between our treasury product and your savings account. Liquidity is about 3 to 4 days.
- All treasury funds are visible on your Mercury dashboard, so you don't have to manually manage fund movements or keep track of your total balance across websites
- You also earn interest on these
AMA if you'd like, though caveat I'm jumping between a lot of Slack messages right now (edit: probably bowing eat to eat lunch)
Each bank your money is in increases FDIC coverage by 250K.
Who is the owner of record on these Mercury accounts at "other banks"?
Can I withdraw *my* money from these "other banks" without Mercury involvement or approval? If not, then *Mercury* may have increased FDIC coverage but the Mercury depositor does not.
You as the customer are the owner of record on the funds. The accounts are held by our partner banks at these other banks, as your agent and custodian (something like "Evolve Bank and Trust for benefit of Acme Corp).
The FDIC insurance applies to the business holding the funds; it is definitely not insuring Mercury itself.
You do need to use Mercury to withdraw the funds; we still run all the authorization and compliance rules around this, and there isn't a facility for you to go into eg United Texas Bank and ask for your money. That said, if Mercury were to go bankrupt tomorrow, your funds are held by our partner banks who have full KYC/KYB info on you would be able to access all your funds.
You might consider providing a "living will" document that keeps your clients up-to-date on where the $$$ are and how they access them. If I'm using something like this I would want to be sure I can make payroll the day after you vanish.
(Not a potential customer or cash management expert, prioritize accordingly.)
My best guess, not until OK'd by a bankruptcy judge. You may have a strong claim on the funds but so does Mercury --- hence the fact stated above that you can't withdraw without their approval. On the other hand, they may be able to withdraw without your approval. A bankruptcy judge is the only one who could override their claim and release these funds to you.
Remember, SVB was an FDIC bank. The reason depositors are able to withdraw money today is because of the quick actions of the FDIC.
My guess, this is a trust/FBO co-mingled type account of some sort.
Only Mercury knows the exact structural details but based solely on their statement above, they have significant control and claims that you can't easily override yourself.
I wouldn't count on this all being resolved quickly in the event of a bankruptcy.
This is the question that needs to be answered before everyone starts throwing their money at these sweep accounts.
SVB offered sweep accounts. Guess how that worked out for folks with money in those accounts? They lost access just like everyone else. If you had a sweep account and you needed to make payroll on Friday, you were not protected.
> We also have a product called Mercury Treasury. This allows you to invest in mutual funds, the safest of which is a Vanguard Treasury Money Market fund (VUSXX)
Mercury charges 60bps for their Treasury product. Why the hefty fee for buying MMFs? VUSXX expense ratio is 9bps for comparison.
Hey Max, I think your offering is amazing but it might be built for the world of yesterday: Since starting this weekend apparently all deposits are 100% insured, why would I go to Mercury to take advantage of sweeps or a money market fund, when my bank offers me slightly higher rates for uninsured-but-insured-in-practice deposits?
1. As others have said in the comments, I wouldn't assume all funds are 100% insured. It is trending that way but I think if you are a CFO managing 10s of millions, its responsible to consider other assets.
2. Our interest rates on Treasury are pretty competitive, up to 4.67% for the slightly-less-conservative fund MULSX (various conditions apply, depends on how much you hold in treasury, etc; see https://mercury.com/treasury for details).
We are OK not having the absolute highest interest rate offering. Our position is:
* The Mercury product is much better than what most banks offer, across features like searching transactions, WebAuthn logins, virtual cards, etc (You can try the whole website at https://demo.mercury.com/)
* Mercury is much better optimized for startups (eg compliance that understands startup needs, doesn't ask your CEO to go into a branch to send wires)
You can always get a higher interest rate by eg buying treasuries yourself. Our position is for most founders, investing in these mutual funds is a safe, no-brainer options that optimizes for safety while keeping the convenience of a single dashboard.
I get this line of thinking, but I also think there's a counterargument that we're all on notice now that banks can go under. As commenters in other threads have noted, people are rebalancing their personal and business accounts right now. Companies like Roku probably won't have $400M at one institution anymore (without outside insurance). That means that if this happens again, many of the people who would have been screwed without a backstop this time around will be in the clear next time. There won't be as much pressure applied by high-level executives and lobbyists, so, as the saying goes, "past performance is not a guarantee of future results".
How is this safer than the alternative? There's no world in which the FDIC lets a bank the size of SVB default on it's deposits, so there are basically 2 scenarios here:
1) You get bailed out no matter what your insurance rate
2) Defaults are at such a high rate that the FDIC doesn't have the money to bail everyone out, the economy tanks, and all businesses that rely on risky VC investment fail anyway
It's like betting $100 on something that won't happen until you're dead. Sure, you might be correct, but there's no real benefit to it.
Queue can also allow batching. It might be that you need to consume or pack or ship N items at a time, otherwise you're losing money. Trying to aim for minimal latency would literally hurt your business.
This article obviously has a very specific kind of workload/service/target in mind that they fail to define and they overgeneralize. This is bad advice in many situations that they failed to imagine.
We had a credit reporting agency (big US one, suffered a large data breach a few years ago) try and insist that we require password expiration for our employees.
After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security" they backed off.
> After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security"...
Tip for those in settings with compliance reviews and cybersecurity insurance: get your PCI DSS, SOX, and other auditors, and cybersecurity insurance underwriter on board with these standards as well, with written statements. Then if Big Customer Co. pushes back after you say, "we're not prepared to reduce our security", ask them in a friendly way to hold an N-way meeting between their auditors and insurance underwriter, and your auditors and insurance underwriter.
This gets them to switch off their demand. Every. Time. If they don't back off on their own, their auditors and/or insurance underwriter makes them back off. I've yet to have such a Big Customer Co. push it to the point of asking more than one of their own auditors, though. Usually it is someone not in auditing and insurance underwriting blithely following outdated policies written in the Stone Age that still need updating, and most are grateful for the updated clarification.
You have to get out ahead of the business risk though for this to work: you need to properly socialize the delay this puts on the deal "while auditors and insurers sort out the risk". This is where soft skills shine.
This approach will also take care of the response user patrakov gave ("NIST is an American institute, and we are a Japanese company, we have our own standards that differ, and must follow them"), once it gets to the insurance underwriters talking it over on how to divvy up the risk and amend their policies if necessary.
The only PCI DSS requirement I couldn’t quickly align to NIST and others has been the 90 day expiration. My go-to has been to convince the insurance underwriters first of the primacy of SANS, NIST, Microsoft and so on. Then put them in a locked cage match with the PCI DSS auditors and accept the result when they walk out. PCI DSS auditors can’t accept liability shifting onto them, and cybersecurity insurance underwriters are getting more savvy on current standards and can often twist auditor arms enough to carve out exceptions and still obtain the audit certification.
It’s still messy at this time, but if it is important enough to you, then sometimes it can be obtained. Most of my clients aren’t that doctrinaire over the expiration part though and are still comfortable making everyone change every 90 days, and with some enterprises they don’t care because they have FIDO2/U2F or similar authN infrastructures and corresponding authZ improvements on their roadmaps within the next 3-5 years anyways that do away with most passwords in their environments.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Sure! I used NIST[0] (which has already been posted here), along with Microsoft[1] and the UK National Cyber Security Centre[2] (we're in the UK as well as the US).
For context, I remember the contract first came back, and we redlined it saying we're not gonna do password expiration and explained why. It then came back with another draft and they said "no, this is our policy, you definitely need to do password expiration" so I threw these references together and expanded my explanation. It was a bunch of business/lawyer types, so I threw microsoft in there as I assume they're better known to non-technical people and the other two references are obviously more salient to technical people.
As a side-note I think this was _after_ they had their very well publicized security breach, and I would have hoped that they had taken a look at their security and updated their policies but I guess that wasn't the case. I don't know whether they ended up removing it from their contracts going forward or just made an exception for our one. The cynical part of me says the latter (it's a big firm, and we're not a particularly big one) but I can hope.
I also recently read an audit for another third party we were evaluating to work with. I raised it as a non-blocking concern saying they're not following modern password standards, and I think if everyone does that these companies will start to update their policies but for now it's fairly common at least in my industry.
[EDIT] I went looking for what I actually said to them, and it was "as per UK/US government and Microsoft password guidelines, we will not agree to this, and would prefer if you didn't do it as well.". So I guess I was a bit exasperated with them at the time :)
This is likely the best way to deal with the inertia exerted by antiquated requirements: Most (keyword being 'most') businesses tend to follow the rules laid out by authorities, so an appeal to authority works in this regard.
Agreed, huge thanks to NIST for the sane password policy recommendations. While it is still an uphill fight to bring sanity into this mess, being able to quote NIST and say we're following their recommendation has been very helpful.
The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions:
> composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought… although the impact on usability and memorability is severe
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
There’s other great stuff in there as well like that you should allow users to “paste” passwords and potential passwords should be checked against a list of known bad ones.
Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.
Expiring passwords are the bane of my existence when the period is short. I can live with changing a password once a year, but every three months is only encouraging me to pick weak passwords.
Why can I accept it? I constantly see colleagues sharing passwords and constantly have to say "please don't" when they try to share their password with me. While forcing people to change their passwords doesn't eliminate the underlying problem, it does limit the scope of the damage.
My old man's work used to make them change their passwords once a month.
For the next 10 years, his password was a particular insulting phrase directed at the IT guys, followed by a number that would increment each time he had to change it. Got into the hundreds before he left the company.
I had a coworker that would type in something random as his new password, then immediately fail to login three times in a row so his account would get locked. To fix this the sysadmin would reset the password, and allow you to choose a new password... and on the no-repeated-passwords policy did not apply to the magical reset dialog. So he would then reset it to his old password.
I was doing the same at one point, albeit it only lasted 5 years before I changed employers. Didnt even had to rotate the numbers, I could always come up with new and colorful insults for the nameless IT group. Which ironically I remember perfectly.
Changing the password opens it to compromise when it's being changed. Capture of that account is possible and easy at that point.
It also interferes with password managers and secure keys.
Opens a phishing vector. Generally I could enumerate how bad it is and run out of ink here. (And it's a screen.)
My former company required not to use one of the last 10 passwords. So every 3 months, employees did the 11-password dance, setting the password back to the original one.
I know passphrases are better. But, the problem is there's much more to type every time you want to unlock your computer. And thus also many more chances to make a typo.
Of course there's TouchID and Windows hello but they don't work if your laptop is closed in a dock. Or in my case a Mac mini at home.
This is why I still stick to the truly random sorry password, I have no issues remembering arbitrary strings for some reason :)
Typing a passphrase is so much easier. You already have muscle memory for typing English (or whatever your first language) words. I can type probably type a 60 character passphrase consisting of real words at least as quickly as than I can type a 15 character password with special characters, if not faster.
For you maybe, not for me. I'm pretty good with arbitary strings. And I'd only use specials that don't require shift :) It's really much faster and I have RSI so I don't want to type too much.
Luckily my work still allows 10-char with specials or passphrases of 16 and longer without. And don't forget passphrases only benefit in very specific situations such as hash brute forcing. Online attacks already block after a handful of attempts.
Also, the incessant screen locking really annoys me, every time I step away for a coffee my PC is locked again, and this is also at home where my environment is completely secure and I'm the only one living there. I actually work in security but sometimes there is just no reason and it becomes just a barrier.
In the past I used an app to jiggle the mouse every once in a while but that doesn't work anymore. I now made a digispark that does the same in hardware. :) I only use it at home though and it auto-locks my desktop when I leave the house (all my personal ones do too)
If they'd just allow us to use our yubikey + pin it would be so much easier and more secure...
I type my arbitrary 12 character password for my laptop as quickly as I’d type two 6 letter common words, due to muscle memory, as I don’t have to change it every few months.
In all serious, my point is roughly that typing Sp3c1al_(h4racTer_p@ssw0rd$ is like O(n) whereas typing passphrases is like O(log n). Once you hit a certain length, pass phrases start pulling ahead in ease-of-use.
We're already constantly maintaining muscle memory just by typing normal words every day. With muscle memory for special character passwords, you have to start over from scratch every time you have to change one.
In other words, imagine I flipped over a flashcard with a new passphrase on it consisting of lowercase English words, and asked you to type it. Now imagine I flip over a flashcard with a new, special character password. How many more times do you think you'd have to reference the flashcard with the special character password while typing it out and developing the muscle memory over the flashcard with the passphrase?
Windows allows you to use a PIN for regular device logon - so you have a longer, more secure password for general use of the account, but an eg 8 digit numeric PIN _only_ for that device.
> Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Across the pond, there is also the NCSC password guidance. It's better than linking to some obscure paragraph in a standards document; it's written in plain English, aimed at the layman, and explains exactly why the old doctrines are bad:
I work for an insuretech startup and have been through a number of compliance gauntlets with large enterprise insurance companies. Appealing to NIST recommendations for why we don't auto-expire passwords every x days and don't require anything more complicated than at least 10 characters has worked on every occasion.
The topic of "what should we do about our password policies" sometimes comes up with our customers as well. Pointing to NIST and if pressed giving my opinions on good passwords and the use of 2FA (which is largely paraphrasing NIST recommendations anyway) made every customer happy so far :)
