If you bank online and choose weak or re-used passwords, there’s a decent chance your account could be pilfered by cyberthieves — even if your bank offers multi-factor authentication as part of its login process. This story is about how crooks increasingly are abusing third-party financial aggregation services like Mint, Plaid, Yodlee, YNAB and others to surveil and drain consumer accounts online.
Crooks are constantly probing bank Web sites for customer accounts protected by weak or recycled passwords. Most often, the attacker will use lists of email addresses and passwords stolen en masse from hacked sites and then try those same credentials to see if they permit online access to accounts at a range of banks.
A screenshot of a password-checking tool being used to target Chase Bank customers who re-use passwords from other sites. Image: Hold Security.
From there, thieves can take the list of successful logins and feed them into apps that rely on application programming interfaces (API)s from one of several personal financial data aggregators which help users track their balances, budgets and spending across multiple banks.
A number of banks that do offer customers multi-factor authentication — such as a one-time code sent via text message or an app — have chosen to allow these aggregators the ability to view balances and recent transactions without requiring that the aggregator service supply that second factor. That’s according to Brian Costello, vice president of data strategy at Yodlee, one of the largest financial aggregator platforms.
Costello said while some banks have implemented processes which pass through multi-factor authentication (MFA) prompts when consumers wish to link aggregation services, many have not.
“Because we have become something of a known quantity with the banks, we’ve set up turning off MFA with many of them,” Costello said. “Many of them are substituting coming from a Yodlee IP or agent as a factor because banks have historically been relying on our security posture to help them out.”
Such reconnaissance helps lay the groundwork for further attacks: If the thieves are able to access a bank account via an aggregator service or API, they can view the customer’s balance(s) and decide which customers are worthy of further targeting.
This targeting can occur in at least one of two ways. The first involves spear phishing attacks to gain access to that second authentication factor, which can be made much more convincing once the attackers have access to specific details about the customer’s account — such as recent transactions or account numbers (even partial account numbers).
The second is through an unauthorized SIM swap, a form of fraud in which scammers bribe or trick employees at mobile phone stores into seizing control of the target’s phone number and diverting all texts and phone calls to the attacker’s mobile device.
But beyond targeting customers for outright account takeovers, the data available via financial aggregators enables a far more insidious type of fraud: The ability to link the target’s bank account(s) to other accounts that the attackers control.
That’s because PayPal, Zelle, and a number of other pure-play online financial institutions allow customers to link accounts by verifying the value of microdeposits. For example, if you wish to be able to transfer funds between PayPal and a bank account, the company will first send a couple of tiny deposits — a few cents, usually — to the account you wish to link. Only after verifying those exact amounts will the account-linking request be granted.
Alex Holden is founder and chief technology officer of Hold Security, a Milwaukee-based security consultancy. Holden and his team closely monitor the cybercrime forums, and he said the company has seen a number of cybercriminals discussing how the financial aggregators are useful for targeting potential victims.
Holden said it’s not uncommon for thieves in these communities to resell access to bank account balance and transaction information to other crooks who specialize in cashing out such information.
“The price for these details is often very cheap, just a fraction of the monetary value in the account, because they’re not selling ‘final’ access to the account,” Holden said. “If the account is active, hackers then can go to the next stage for 2FA phishing or social engineering, or linking the accounts with another.”
Currently, the major aggregators and/or applications that use those platforms store bank logins and interactively log in to consumer accounts to periodically sync transaction data. But most of the financial aggregator platforms are slowly shifting toward using the OAuth standard for logins, which can give banks a greater ability to enforce their own fraud detection and transaction scoring systems when aggregator systems and apps are initially linked to a bank account.
That’s according to Don Cardinal, managing director of the Financial Data Exchange (FDX), which is seeking to unite the financial industry around a common, interoperable, and royalty-free standard for secure consumer and business access to their financial data.
“This is where we’re going,” Cardinal said. “The way it works today, you the aggregator or app stores the credentials encrypted and presents them to the bank. What we’re moving to is [an account linking process] that interactively loads the bank’s Web site, you login there, and the site gives the aggregator an OAuth token. In that token granting process, all the bank’s fraud controls are then direct to the consumer.”
Alissa Knight, a senior analyst with the Aite Group, a financial and technology analyst firm, said such attacks highlight the need to get rid of passwords altogether. But until such time, she said, more consumers should take full advantage of the strongest multi-factor authentication option offered by their bank(s), and consider using a password manager, which helps users pick and remember strong and unique passwords for each Web site.
“This is just more empirical data around the fact that passwords just need to go away,” Knight said. “For now, all the standard precautions we’ve been giving consumers for years still stand: Pick strong passwords, avoid re-using passwords, and get a password manager.”
Some of the most popular password managers include 1Password, Dashlane, LastPass and Keepass. Wired.com recently published a worthwhile writeup which breaks down each of these based on price, features and usability.
Sadly, some banks and other financial institutions don’t allow strong passwords due to restrictions on password length or not allowing all special characters. I no longer do business with those institutions. If they are too lazy to do the programming work to handle more secure passwords, I assume they are lax in their overall security practices.
Thanks, Mike. Yes, I meant to include a mention of this in the story, how some banks only allow a certain number of characters or stop paying attention after a certain number.
Places that do weird password policies like that (truncating early) can be an indicator that they are storing plain text passwords.
This is completely my assumption, but isn’t the reason that some institutions do not allow various special characters are for SQLi / XSS or other injection attacks? But, if that is true, that’s not always the case in every situation like you mentioned. I’m sure there are other reasons, I just thought that was a bigger one.
So they claim, but programming with security in mind will fix that. They are just too lazy or dont have a good security team
If avoiding SQL injection attacks is the reason they don’t allow certain characters in passwords, then they have much larger problems…
The certain characters are restricted might come from a rule where all input data from the web form is passed through a tool that scrubs the input for XSS or SQL injections. How often that happens I don’t know. Given the amount of open source web code that routinely ignore input cleansing you might be looking at a lesser of two evils scenario.
Either way we don’t have enough information to say either way.
They’re welcome to claim whatever they like, but the first thing they should do w/ a password is hash it. The second thing is to discard the password. Hashes have a standardized format which should be safe from SQL injection risks.
If they want to, they could take the original password and use the have I been Pwned password API [1] to see if the password is too common to be used safely. But, that like the above involves hashing the password before doing anything with it.
Password should never be submitted to SQL / HTTP / other APIs w/o first being hashed.
[1] https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/
I have always thought, why haven’t the banks taken steps to fix it. Financial institutions gets attacked second to the Pentagon, so one has to wonder why.
Suppose they are willing to pay millions after a breach instead spending money to fix the software.
Have to wonder how the business brain works.
I have yet to find a bank that allows hardware token devices like Yubikey as a choice unlike Facebook, Twitter and LinkedIn. I realize most customers would not choose a difficult 2fa method but the choice should still there for those customers that do choose to up the ante for their safety. Google and Microsoft authenticator and Yubikey s/b a choice. I don’t understand how a brute force attack can occur when many bank sites will freeze you out if you try and fail 3 times your password.
My credit union allows security keys like Yubico only for their business customers.
I’m going to keep at them.
Vanguard allows physical security keys for 2FA.
Schwab has multi-factor for account access, including checking if you have investor accounts. They gave me a Symantec fob one-time key generator.
https://twofactorauth.org/#banking
Unfortunately since most banks require a password on your phone to login, a shortish, easy to remember password is usually used. I’ve used RoboForm for 15+ years to manage my passwords, and it is great and free on a PC, but costs monthly to use on a phone.
A password manager with a monthly subscription? Ugh… there are better ones, and cheaper.
I’m always wary of the convenience features of the password manager living in the browser. Of all the security vulnerabilities found, they seem to be all related to these convenience features.
A better alternative for mobile, is to have a password manager also include it’s own keyboard, which can type into fields. It is browser/app agnostic, and doesn’t use the clipboard (which is accessible from any app).
Please no, just go check out Bitwarden. Free for all devices with paid optional premium services.
The “new-improved” quicken FORCES an online sync of saved financial institution passwords for downloading transactions. Another weak link in the chain.
Dan,
Can you please expand your explanation on this “online sync”.
Does this deal with quicken online only (vs. quicken desktop)?
I have a ” Mint” account but don’t have it linked to my bank financial information, not in a million years would I do this This would be a security vector for a real good breach if it occurred again Mint.com
I use i the account mainly to check my credit score , nothing else
It’s one thing to understand the environment and rationalize the fear.. It’s completely not prudent to Fear something you don’t know or have not explored in detail.
If anything, the weakest list is us customers, we reuse passwords , we fall for social engineering attacks, we don’t take our security serious. Agreed, banks and other institutions have to do their part, but again barring those huge breaches, the most impactful ATO’s have often been a result of customer falling for something that they should not !
The problem isn’t how you use Mint, it’s how banks allow others to use Mint (and similar service providers).
Essentially, banks have decided to trust Mint and friends more than they trust consumers. On average, Mint may be more trustworthy than the average consumer, but crooks have learned that there’s more trust, so they’ll open a mint account and use it to impersonate you– even if you don’t have a mint account, or perhaps even if you already have a mint account tied to the relevant bank account.
And then banks (or PayPal) will allow authorization of bank access based on “proof of account knowledge” — knowing the dollar (really cent) value of a pair of deposits.
The problem is that the underlying banking system is purely a friendly trust-based system. If I have a routing number and account number, I can ask a bank to make either a deposit or withdrawal to the account. This is what allows your employer to both pay you (“direct deposit”) and reverse a payment (e.g. if they accidentally over-pay you) even though you thought you only authorized “direct deposit” and not “direct debit” — there’s no meaningful distinction in the protocol/authorization. It’s pure trust — you trust your employer to generally deposit, and not debit.
You trust your credit card to generally debit (to pay your credit card bill) and not deposit (why would they?). But if for some odd reason your credit card accidentally charges you $2,000 on a card you only spend $100 and you complain, they can direct-deposit a refund (or send you a check, but that’s a pain). And if your employer accidentally overpays you by $20,000, and they realize their mistake, they can direct-debit a withdrawal (even w/o notifying you, although they’ll probably tell you).
PayPal decided a long time ago in a trustworthy world far away from today’s evil world that if you could see the transaction history of your account, you were probably authorized to manage the account and thus could authorize direct deposit & direct debit.
This was an extension of the original trust model.
But it fails if it turns out that anyone can ask mint to ask any bank for transaction history based on stolen passwords. — When the accounts in theory have 2FA to guard general access.
“avoid re-using passwords”? There is no avoid. Unique password at the maximum length and complexity allowed for each institution.
Also, people have don’t HAVE to use their phone to access financials shouldn’t.
Chase bank does not allow an email address to be used for a User ID.
Unfortunately, the reason is “Your User ID and Password cannot include special characters”. Oddly, this results in a more secure username and a less secure password. The username is more secure because otherwise many people would use their email address, and thus be in danger of the hacks described in this article.
Chase allows some special characters in their passwords; mine has one.
I agree on the more secure user name; disassociating it from the email address makes the attacker’s job harder.
Apple devices (Macs and iOS devices) have a built in password manager (Keychain) that works with Safari and most 3rd party apps. So do Chrome and Firefox.
Agreed. iCloud Keychain is a FREE Apple proprietary password manager built into every iOS and macOS device (Apple TV also seems hooked into it.)
It seamlessly syncs across all devices on a given iCloud account. It is en/decrypted on the devices, so the backup stored in the iCloud is protected in transit and rest. It is nicely integrated into Safari. It will generate long (formerly default was 15, but maybe a year ago it was increased to 20 char) complex passwords 99/100 times in compliance with a websites local requirements and automatically save to the Keychain. For folks that just have it turned on to capture authentication credentials, but haven’t bothered to let it create a secure password, it will also flag users for p/w reuse. iOS 13 will also flag inadequate password strength for old p/w’s or newly non system created ones.
Further it benefits from the size, scope and resources of Apple.
Finally, in about a month and a half, ios 13, MacOS Catalina, will debut and will feature a new private email relay feature, whereby the Keychain can generate an unique anonymous complex email address for each website. If the site or app wants to contact you, they send to this address and Apple will relay it into your email. If you start getting spam from that email acct, you might question if that site had a breach. You can easily discard it and replace it, and Apple does fraud detection if it sees your incoming mail is not from that site and can thus throw a caution flag.
It’s a great little tool.
P.s. I’m really looking forward to the relay feature. I created unique emails for financial and medical accounts using the gmail + feature, ie fin+004@gmail, which dumped into fin@gmail as my poor man’s relay system. While it worked, it was cumbersome to set up, especially if one wanted to put all those into the hibp registry for breach notification. Now the set up should be easy and the registration should be not necessary because Apple is doing the fraud monitoring in the background.)
My title here (for another couple of weeks, till I retire) is sr. linux sysadmin. I work for a federal contractor on site, and deal with a number of websites open to the world.
At home, I have my *own* router inside the Verizon one.
I do NOT DO ONLINE BANKING. How many breaches does it take before you decide to take a few extra minutes and go into a bank…?
Mark, how does your avoidance of online banking help to keep your financial institution from being hacked?
How does it keep an attacker from creating an account in your name? Your SSN is out there, and it’s cheap.
Correct. If you do not have online access, you are allowing a hacker to set up online access for you. The bank doesn’t care. So, mark, you are less secure than I am with my online banking.
Bruce is correct here. For an explanation of why please see: https://krebsonsecurity.com/2018/06/plant-your-flag-mark-your-territory/
Generally I agree.
However, if you can prevent your bank from allowing anyone to set up an online account, that also works.
OTOH, sometimes planting your flag doesn’t work (hello Experian/Equifax, who seem to have rebooted their accounts — you reported on that not too long ago although I can’t think of the right search terms for the time when they created a new freeze system and allowed people to unlock w/o their pins).
hello. call me dense but what are some more examples of these “financial aggregators”? someone mentioned mint. but the article also mentions paypal and zelle, which make wonder if paypal and zelle can be categorized as financial aggregators??? how about apps like privacy or token for disguising your real visa and mastercard numbers? sorry but, despite my being online since my old CP/M days, the term “financial aggregator” is really new to me.
I think in this sense a “financial aggregator” is any site or service that can connect to multiple financial accounts.
Mint is one. It’s service is to show you all your accounts on one site.
Paypal and Zelle could count since they let you pay via any one of the other accounts.
Plaid is also mentioned. Plaid is used by many cash back apps such as Dosh or Drop. Empyr is a similar service. (Note that I’m unsure if either Drop or Dosh actually use Plaid).
I’ve not heard of Yodlee before.
Wells Fargo uses Zelle for transfers. Does that mean WF customers now have a Zelle vulnerability?
Paypal should be linked to CC a/c, not bank a/c…
Dear Dense,
https://lmgtfy.com/?q=financial+aggregators
So do these financial aggregators gather my data? Or only the data of people who use them?
That is; if I’ve never signed up for any of these, am I safe from this attack vector?
Or do they do deals with banks to buy the financial data of all the bank’s customers? (Which used to be illegal, but I think Congress changed that years ago…)
It sounds like they ask an account holder (i.e. hacker) to provide account information + password and then provide that information to your bank. Your bank, which would otherwise, normally, ask you for a 2FA response, decides, “oh, hey, Mint, I trust you”, and skips the 2FA challenge. And then you’re screwed even though you thought you guarded your account w/ 2FA.
This is purely a bug in the banks’ trust model. You’re encouraged to yell at them. (Point to this article.)
Might be worth noting that the Wired article actually recommends KeePassXC over KeePass, a recommendation I agree with. It’s open source and not cloud-based, which are pluses in my book.
Your link actually does go to KeePassXC (yay!), but you may want to change the text so users don’t get confused. KeePass still exists, but is maintained by a different developer.
XC is more friendly if you’re looking to use it on Linux as well as Windows (it doesn’t require Mono).
There are a few options. I like the Keepass version that allows yubikey as a 2nd factor… and the same database/key file can be used on Android, and unlocked using the same yubikey using NFC.
Other connectors to banking accounts are the investment apps like Robinhood, Stash, and Acorns. They could potentially be compromised.
I have my own biz and am the CEO as well as the IT, PR, HR, GM and chief gofer. My take is that the current situation is no dif than when other innovations have taken place since technology took hold of society– railroad, cars, electricity, planes, etc. and no doubt there were major snafus (check military definition), calamities of all sorts including deaths. My impression is that a lot really depends on your predisposition to risk. 100% security does not exist. Best we can hope for is a serious attempt to mitigate problems. The other option is to NOT use the internet or do business with any that have electronic devices or the internet. Man, it was definitely safer and the pace much slower back in the days of carbon paper, typewriters, hand written bank deposit books and NO credit cards, only real money and paper checks where the bank recognized your signature.
I appreciate the “good ‘ol days” mentality. But it really is only the “Golden Age Fallacy”
Back then, check fraud was rampant. Signatures were not recognized either… I am sure if you had the same bank teller and the same grocer for years,… but 99% of the people didn’t.
Important to differentiate Interactive Login and API. It’s not practical to use traditional MFA approaches for API (unattended, programmatic access). There are plenty of solutions to securing API interaction such as restrict by IP/location/device/process, use of Oath tokens, using an API gateway, requiring user interaction during initial setup and then again at predetermined periods or when anomalous behavior is detected, restricting API to certain roles/permissions, etc…
Alas it is no longer possible to get into banks easily . In New Zealand many branches are closed and I noticed that in a U K city I visited that there is no counter service just a rank of machines to be accessed by Eftpos cards or Visa.
Cheques were useful but they seem to need staff to check them. Banks lay off staff if possible and divert customers to the internet.
I never access anything financial on a phone and try to do without one if possible .
SQRL is up and ready. no more passwords. Just in time solution. grc.com
Meh. SQRL is interesting, as an academic project… but nobody has implemented it in the real world. Probably because there are better methods.
GRC is really just a hobbyist… and should not be looked to as an authority.
Steve Gibson is just a hobbyist & not an authority? Really?
When it comes to developing a standard, yes.
When his idea is actually adopted, implemented, and fully vetted by the entire community, then maybe. But there is a huge graveyard full of protocols and standards that looked good at first, but weren’t practical.
“don’t roll your own” applies to crypto and also authentication schemes. And SQRL is homemade without any real world implementations.
I was also being somewhat polite when calling Gibson (GRC) a “hobbyist”.
Definitely not an authority.
http://attrition.org/errata/charlatan/steve_gibson/
SQRL seems to pop up like a bad penny on every authentication thread. It isn’t implemented by anyone in the industry, because it simply doesn’t deliver as promised. There are a lot of eyes in the community who would jump on it, if it did work as marketed.
New crypto and authentication schemes need a LOT of vetting and validation by the community. You simply do not “roll your own”, as Steve Gibson is trying to do.
My advice is not to advocate for it, until/unless it gets a proper vetting. Otherwise, stop trying to make Fetch Happen.
Some bank sites like Wells Fargo use an “I am not a robot” test that forces people to manually enter a string of moving letters that are displayed after inputting the password. I am wondering if this is an effective way of preventing brute force attempts to guess the right password.
No. For one, there’s sometimes a “mechanical turk” available. For another, it might not be used in all cases (which is the root cause of the problem described in this article).
It’s good Krebs has exposed the weakness of 2FA and the false security it is providing. 2FA can only work if the first factor is fixed.
Passwords will not go away they are need to demonstrate contractual agreement legally. It needs to be shown that you have agreed to a transaction on the balance of probability for commercial arrangements and on the beyond a reasonable doubt in criminal matters.
The higher test generally will apply in cases of fraud so it is important for an institution to be able to show the transaction is legitimate this can only be done with something you know as in all other instances the proof is subject to the possibilities of spoofing.
People who allow their banking credentials to be saved in browsers, password managers and with aggregators are just asking for trouble.
The key to correct password implementation is to have a system that prevents password duplication and automatically creates unique complex passwords that are easy for the user to remember and that prevents the passwords being phished or keylogged to provide the necessary proof that the transaction has been correctly validated.
We have a video that explains the weaknesses in 2FA in simple terms at Armorlog.com
As a practical matter, I agree that passwords will never be completely removed, as it shows that a user is present and knowingly is engaging with a company’s website.
But, since a user’s authority can be transferred to a physical token or a NFC device, such that presenting it for subsequent transactions is legally binding, then there may be a way to limit overall password use in the virtual realm, too.
Unrelated: congratulations on your patents.
I disagree. “after-the-fact” implementations of 2FA require it to be secure with a strong password first to set up a 2nd factor. But there are many other implementations of 2FA that are secure even without a strong password. PINs that only work for the physical token are an example of passwordless 2FA, where a weak PIN is the “something you know”.
Passwords won’t go away entirely, correct. But they can be so strong as to not resemble the traditional password. 256 char fully random strings can replace passwords, and still have the pre-shared component. There is no reason to assume we need to keep the “user chosen, memorable” model of passwords.
Password managers come in all shapes and sizes. They aren’t “asking for trouble” if they are secure, offline and don’t integrate with browsers.
U2F is a good example of phishing resistance as well.
“The key to correct password implementation is to have a system that prevents password duplication and automatically creates unique complex passwords that are easy for the user to remember”
That is not universally correct.
Easy to remember, means possible for computers to guess. The human brain cannot beat computational power.
Anything that you could store in your brain, can be derived much easier than truly random strings.
I don’t use a cell phone for any financial activity. I also don’t trust any company with my phone number for 2FA. It’s really about them wanting more info so they can upsell you on their “wealth management” or to increase the value of the info they will sell to their “affiliates”.
Passwords can be more secure. It’s the deliberate failure of the institutions which cause most breaches. They have login pages which run several offsite scripts. They limit your password to a few characters, or only one space, or no special characters, and worst of all they don’t always tell you what they allow on the create account page.
Many institutions require an email address as the user name. This shouldn’t be allowed. I use different random strings at several sites as my user name.
I wonder if the password databases would be more secure if they allowed you to enter a username, password, and a salt which they don’t store to encrypt the password. Use it like a CVV number on a credit card.
It isn’t really a salt if it user provided. At best, it is just another password. Really, it is the equivalent of just making the password longer.
CVVs are different. They are separate from the CC number because the CC number has LUN checks… which limit their randomness. So a 3 digit number is needed that isn’t part of the LUN, to make it better.
Joe,
Why isn’t it a salt if you must have the password part to login?
You provide a salt which is added to the password you created and only then the hash is stored. But the site doesn’t save your salt so only you can provide it with the password to login. Then even the site can’t provide login details when, not if, they are hacked.
A salt would be weaker than a 2nd password, for precisely the reasons you gave.
It isn’t stored on the server in plaintext.
So calling your idea like a “salt”, actually does it injustice.
Think of a “salt” as a common ingredient used just to make it more flavorful (more unique hash). Salt isn’t really a “secret” in itself.
Now my point, what you describe is more akin to a 2nd password. And that is still just as strong as a longer password.
Remember, hashing (like any crypto algorithm) gets exponentially harder as you add on, because order and placement matter.
Two passwords aren’t as good if they can be independently tested (or if they are separately hashed), remember the LANMAN 7+7 crap.
So yeah, the point would be to append the 2nd password to the 1st, before hashing, right? Well, that is literally just a single longer password.
So the best solution, is to just add the characters to the password minimum length, rather than making it separate in any way.
I work for a financial institution as Information Technology Officer. Like most FIs, our most important vendor is the company that handles ALL our customer account data — every deposit, every loan payment, every transaction. If a penny moves into or out of the bank, this vendor (referred to in the industry as our “core processor,” yes, seriously) transmits that data to their data center. The FI does not retain a copy of that data. Only the CP has it.
That core processor also provides our online banking. That is, the CP is also the web host that manages our customer access to accounts. When logging into online banking, the CP frequently asks our customers to confirm answers to their challenge questions. When asking for confirmation, the CP displays their original answers. This vendor, responsible for ALL the financial data, and ALL the transactions, and ALL the online traffic, stores answers to customer challenge questions as PLAIN TEXT. Further, they SHOW those answers to anyone who gets past the initial login, making the existence of challenge questions largely moot.
This is one of the top few CPs in the industry. Clearly they are obliged to know better. Individual customers MUST take the security initiative — as the core processors don’t.
All the more reason to have different challenge answers for every institution. My personal history is clearly scary due to the large number of mother’s maiden names that I have…
In other words, it’s way worse than we thought! 🙁
While I’ve heard many third-party apps clamouring for the right to use banking usernames and passwords, I’ve not heard of any who are willing to reciprocate. Many of these fintech apps have their own login credentials and they generally instruct users to keep these credentials private and not share them with anyone.
Do you have any new news Mr. Krebs? It seems to be the same… every… fucking… week…
Hmm. Not sure you’re going to find anyone else writing about this particular subject. But please prove me wrong if that’s the case.
“The same every… week” insofar as reporting on irresponsible security practices by various institutions around the world?
Why yes, that’s sort of what Krebs reports on. It’s a bit of a problem these days, if you hadn’t noticed.
Yup, can confirm. Services like Mint are whitelisted by IP and bypass MFA.
If you’re going to recommend an article, you should at least make sure that article is accurate, which the Wired article is not.
“Web browsers have other priorities that haven’t left much time for improving their password manager. For instance, most of them won’t generate strong passwords for you…”
Wrong: Chrome, used by the majority, generates and stores strong passwords.
“If you’re willing to spend a few dollars a month, a password manager can sync your passwords across all your devices.”
No need to spend money: KeePass can sync passwords to free cloud storage.
“Best Overall
1Password”
Wrong: No proprietary software can really be considered secure.
‘Runner Up
Dashlane”
Wrong: Proprietary.
“Best Free Option
LastPass”
Wrong: Proprietary, poor history.
“Best DIY Option (Self Hosted)
KeepassXC”
Wrong. Keepass is open, secure, and will work across platforms.
Hey John, I appreciate your comment. Might get your point across better by stating the above as your opinion, as opposed to presenting everything you have to say as correct, when most of your points are your opinion, IMHO.
For example, storing passwords in your browser — however complex they may be — is a huge risk, and not recommended for sites you care about.
Are these problems of getting hacked also true of the Wave accounting program?
Is it one of the “third-party financial aggregation services”?
It accesses bank accounts to conveniently present one’s banking information.
It’s at waveapps.com
Is Wave accounting one of these “third-party financial aggregation services”?
It dips into my bank accounts to present a convenient way to keep track of my finances.
It’s located at waveapps.com
Sidebar: it frustrates me that the concept of MFA is being diluted by sloppy or deliberately misleading terms like “2 step authentication”. Lots of sites do this. A password plus a KBA question is not MFA; it’s just (something you know) *2.
It’s so much worse.
Using Knowledge Based Authentication is something you know (the password), and something other people know about you (open source intel).
KBA was originally meant to be something your lender or creditor knew about you, that you could verify. How that got bastardized into user chosen answers that could be derived from public information… I could only guess. It’s like someone was lazy and wanted to prepopulate authentication based on the application for an account.
“All the more reason to have different challenge answers for every institution. My personal history is clearly scary due to the large number of mother’s maiden names that I have…”
Yes, that has made for some interesting conversations. It’s kinda funny watching the bank rep’s face as he/she tries to find a way to ask for clarification about my “Diceware” MMN without offending me. 🙂
I’ve also politely pointed out that not everyone can even answer that question if they wanted to. Some folks have two mothers or two fathers, for example.
We need to just move on from that silly “secret” question which isn’t, and from KBA in general. Just make me come in to your branch with ID in hand.
The smart thing is to make your username a 2nd password. For example, if your username is jpsmith, then append some numbers you can remember numbers after it , then your username might be jpsmith685429
With a password manager, having a different username and different password for each account will slow the crooks down.
Some banks do this… they use an ID number as the username instead of email address.
Of course, you can do this with email too (if they allow the ‘+’ symbol in the username). Gmail and several other email providers allow you to append anything after your email (ex. JSmith+239o23w09ksksd@gmail.com)
When you create an account, use that. The emails will still arrive just fine, but the username must be that full string.