I was having trouble accessing my account, so I gave a call to customer service. The service rep proceeded to (accurately) describe my own password to me. Should I report this somewhere? I'm not really sure what to do.
This will allow you to report it, eventually from an anonymous email address, without exposing you directly to the bank which might react bad to you. CERT can handle the coordination with the bank, this is what they do.
Really good suggestion. And in case they still need encouragement, some negative press coverage might get them going. Right person for this -> https://krebsonsecurity.com/
I do not think that recommending Brian Krebs is a good idea for someone who might wish to avoid retaliation. Recently, he doxxed some people on Twitter for reporting bugs.
As a result, I no longer visit his site or recommend his work. Publishing someone else’s personal data without consent is a terrible thing, and is one of the reasons so many of us work to secure systems. His behavior undermines that.
"Krebs appears to have form in outing people who do not agree with him. Back in 2014, he posted the CV of an individual who had written what he characterised as a bad review of a book he authored."
When British security researcher Marcus Hutchins asked whether doxxing a person for this was going a bit too far, his response was: "Dox people? Hardly. I think it helps to add context. The guy is a convicted cybercrook who's in jail. Of course he hates me."
Ouch. This is sad. I used to have a lot of respect for the guy.
This very looks cool, thank you for sharing parent.
I apologize for the nitpick, but I hope there will be some guidance on what an "anonymous" email is.
(Ex: Guerilla at a public wifi like a library, an email created at a library, but not your usual email from a place other than your home)
I worry sometimes that we assume people reporting security vulnerabilities will be security experts.
I often meet people who are intelligent and technical, but either do not understand security, or understand it in terms of confidentiality, integrity, and availability (CIA triad) and flounder when thinking about anonymity.
An easier way may be to anonymously message a tech savvy media company or security firm, maybe via snail mail even. You can do it anonymously yourself but it'll take some work and a mashup of:
- VPN service where you pay with cash (Mullvad)
- Temporary email (Protonmail?)
- One time use computer (cybercafe, pay with cash?)
There's layers you can apply like a TOR browser usage but it'll take more effort/learning.
> I often meet people who are intelligent and technical, but either do not understand security, or understand it in terms of confidentiality, integrity, and availability (CIA triad) and flounder when thinking about anonymity.
Can you suggest any resources for a technical user who would like to learn more about this distinction?
"Person X reported a vulnerability, they must be a hacker! Get our lawyers" - Some non-technical bank person. Most companies don't like having their mistakes publicly exposed.
> “It’s fine, there are more checks in place to prevent unauthorised transactions”
> “Also, it’s insured”
Well ok, that means the bank is protected, but what about my (sensitive) data such as transaction history?
> “If anyone does anything bad, law enforcement will step in”
Yeah, I totally trust a bank that can’t even properly deal with something as basic as passwords to notice breaches reliably.
> “It would be too expensive to replace legacy systems”
And that’s the consumer’s problem?
I really hope none of you apologists are moving fast and breaking things at any company that is entrusted with people’s personal information or is needed for more critical infrastructure of everyday life than cat pics and funny polls.
In Europe banks also don’t like paying to replace legacy systems to maintain security, but such a failure to protect consumer data and privacy would be in serious breach of legislation and result in significant fines.
>> “If anyone does anything bad, law enforcement will step in”
>Yeah, I totally trust a bank that can’t even properly deal with something as basic as passwords to notice breaches reliably.
As an example of this: Equifax. This happened in 2017, and not really much has happened and people haven't been prosecuted. So everyone got some identity theft protection for a year. That didn't solve the problem. Equifax lost a little money. So little changes. And the claim is that it is Chinese state actors that did this, so no one will get prosecuted (because we just let China attack us?).
So handwavy seems defeatist.
Also, if this is a major bank, then Equifax is a great parallel to draw from.
> Well ok, that means the bank is protected, but what about my (sensitive) data such as transaction history?
If I recall, they already sell that to other companies. (It might not have your real name attached, but any one of the companies you purchased from can deanonymize it by cross-referencing their own charge log.)
As someone who works in finance/banking, I can assure you that this is not uncommon. Almost everyone is engaging in not-so-best practices with password storage if they are using any 3rd party vendors. Only the institutions with the resources to rebuild in-house systems with modern security standards are the exception to this rule. There are only a handful of these. Ultimately, it's not some malicious intent or incompetence, but simply the acknowledgement that the legacy systems will not enjoy PBKDF hash+salt+iterations columns being added 30 years after the fact.
The risk analysis and mitigation discussion for these institutions goes something like this:
1) We cant have good password storage so we will require a 2nd factor and attempt to ensure these systems reside in our most secure network.
2) There is nothing we can do, so we will simply rely on the fact that if someone logs into an account illegally, we send in the men with guns. For some strange reason when a bank calls the FBI things move with a high level of expediency.
There is much more to this than just the technical aspect of "oh my goodness why aren't you hashing your passwords". How much ripping would HN impose on one of these institutions if they attempted a 100% best practices secure password upgrade and then subsequently had a complete IT disaster unfold (I can certainly link articles). For many banks and other financial institutions, going down for even 1 hour is a complete catastrophe. If people can't get their money out right away, they are leaving for the competition and you will likely get dinged by regulators. Bad people will continue to do bad things until the end of time. Killing your business to handle every edge case, even if it seems obvious, is not a good path to go down.
I would also consider this: These banks' IT systems are storing things that many of us would argue are much more valuable than your passwords. A bank's core system also represents the actual monetary value of every customer's account. We are talking about password security in a system domain where there are arguably far more valuable assets to secure. These assets are already implicitly protected by a massive apparatus extending as far as Ohio Class nuclear submarines patrolling the Pacific ocean.
> For many banks and other financial institutions, going down for even 1 hour is a complete catastrophe.
Are you joking? It's a common trope for bank websites to go down for "scheduled maintenance". Not to mention real-world bank branches keep bizarre hours and close for random holidays like Presidents' Day and Veterans' Day.
Even though websites are really important, I think they mean other business critical services going down for an hour.
Imagine if all credit cards with a company failed to process transactions for an hour, or depositing/withdrawing money didn't make a change to your balance. Those types of issues are much more severe than a customer not being able to log in to the website.
You know, those kind of things already happen. Even I sometimes had issues with my credit card when paying online and usually there's another way or you could just pay an hour later.
This site is used for everything. Reviewing your taxes, reading mail and notifications you've received from the government, filing returns, making payments, etc.
That sounds amazing... as an admin, I mean. Can you imagine being allowed to have scheduled downtime every day? It does suck a bit for users, although honestly putting it at 3-6AM mitigates a lot of my concerns with that.
> These banks' IT systems are storing things that many of us would argue are much more valuable than your passwords. A bank's core system also represents the actual monetary value of every customer's account. We are talking about password security in a system domain where there are arguably far more valuable assets to secure.
The password is what secures the more valuable things inside the account (the money). In fact, in nearly every case a password is used, no one really cares much about the password itself, but what's inside. That's why services require password in the first place.
EDIT: Also, don't be so sure that passwords are not useful. If you can compromise a password in one service, there is a significant chance that the user in question is re-using the same password on other (or all?) services. If your password is "joe123" on somewebsite.com, if I can crack that, I can try to use that information to guess your login on somebank.com, somedoctor.com and somegovernmentservice.gov. The more things become "cloud"-based, the higher the value of cracking a password.
I think the bigger consideration is actually how to exfiltrate money from an account that you compromise: If you initiate a wire transfer to some account you control, that leaves a paper trail, and typically has a lag time, during which the institution/customer have a chance to react. This is also why scam centers in India ask you to send them cash equivalents: gift card codes they can redeem/resell.
> The password is what secures the more valuable things inside the account (the money)
> I think the bigger consideration is actually how to exfiltrate money from an account that you compromise: If you initiate a wire transfer to some account you control, that leaves a paper trail, and typically has a lag time, during which the institution/customer have a chance to react.
It sounds like your third paragraph contradicts your first - it's not just your password that protects the money, but the institution whose business it is to maintain and reconcile paper trails.
Banks were using signatures(!) to protect depositors' money long before passwords existed - and they have had processes to mitigate fraud since then. While not ideal, plain text passwords are huge upgrade over signatures
> The password is what secures the more valuable things inside the account (the money).
I think the broader point of the parent is that in banks, there is actually a lot more than just the password securing the money in the bank. There is careful surveillance of the activity of accounts at the bank--separate from the website login system, and backed by regulatory accountability and ultimately the police.
Unlike a modern service like Facebook or Google, your bank's website is not the same thing as the entire bank. When you log into your bank's website or app, you're logging into a public-facing system that in turn interacts with the "real" systems that the bank uses to manage money. Those "real" systems are secured in various ways too, and not just based on the web password.
I once attended a talk by Bruce Schneier talking about the resilience of the financial system. Beyond the prevention of bad actions (for example by authentication), he emphasized that the financial system is highly engineered to make it possible to recover from bad actions. That includes some technical means, but also methods of accounting, and insurance.
>The password is what secures the more valuable things inside the account (the money). In fact, in nearly every case a password is used, no one really cares much about the password itself, but what's inside. That's why services require password in the first place.
Only access to the account is protected by the password. Sending money isn't protected by a password. It is protected with a second factor on top of requiring access to the account.
So they can add columns for 2FA but strengthened password storage is not doable?
This was forgivable 30 years ago. It was bad practice 20 years ago. Someone could have demonstrated leadership and developed a ten year plan to fix their legacy problem then.
> developed a ten year plan to fix their legacy problem then
They did. And Pi factor came in. And budget was cut because those pesky fintech are a threat, and clearly money was better spent on a more modern offer than on those "security" concerns.
And yes, it's possible to add 2FA to the front layer. However, the remnants of COBOL code running on the mainframe for the last 25 years weren't designed to handle passwords length 9 or more, and the last guy who knew how that code was built has retired some 15 years ago.
That COBOL layer that underlies almost all of our infrastructure.
It was written when the cost/benefit calculation of writing it involved "downsizing" thousands of clerks who were doing the job manually.
It can't be replaced because the cost/benefit calculation of replacing it does not involve anything like those kinds of numbers. The benefits of avoiding even a major security incident just don't compare to the costs.
Some banks are replacing their core banking system with new software. It's extremely expensive, a huge risk (any delay in migration means time where customers can't use ATMs or cards) and the benefit vs just adding API layers on top isn't always clear. At some point everyone needs to modernize but there are very few people who'd want to take responsibility for a project that size.
Not only banks. I bought a house with the money I made on a Y2K project for a water authority's billing system. I doubt they've managed to work out how to replace that mess of COBOL without going broke.
Speaking about Germany here, the online banking userid is much longer and basically acts a second password. It's not written on your card or used for anything except logging into your account via online banking.
Yeah, this "we can't extend password beyond 8 characters because legacy systems" argument does not hold water.
My experience: built a Web site/app for: a) major bank b) major corp, back in the days when Web presence was kind of a new thing. ~15-20 years ago.
You build a new (Web) app and treat the legacy system (happened to be some mainframe) as a backend or whatever. Add new tables to hold user's credentials, email addresses, and whatever else. Link the "new" credentials with the old "account id on mainframe" or whatever. Not really rocket science.
BTW - there was no such thing as an "old password table with max 8 character", not for retail customers. Retail customer did not have a password, or email.
>> Until 3 years ago, J.P. Morgan chase would only store the first 8 characters of your password. They would accept more but silently discard it
Oh, I am sure they do. The big question for this thread is: how come this "8-character all-uppercase" password is a thing in States, but less of a thing in e.g. Europe.
>> Add new tables to hold user's credentials, email addresses, and whatever else.
Adding a table to hold users' credentials doesn't really solve the problem that is being discussed, which is storing users' credentials. All that does is add a new attack surface, stealing the new credentials, and the original credentials are still in the same position.
Yes, you are right but we are talking about potential causes of these strange policy decisions. One source is simply old software that cannot be updated but this sub-thread is trying to debunk that by saying that you can have a modern table with hashed passwords and a generated secret value that conforms legacy restrictions. The secret value can be used as a password on the old mainframe. There will be collisions but they can be prevented by comparing usernames.
There is no technical excuse for not hashing passwords.
You can salt and hash the new password; and the old password can be in plain text. The old password being in plain text doesn't matter so much if it is not possible to access the legacy system directly from outside of the banks network.
A lot of the mainframe systems running large organisations were written more than 30 years ago and are still the core of the business, so their limitations are the constraints everyone else works around.
> Someone could have demonstrated leadership and developed a ten year plan to fix their legacy problem then.
The large project I work on is 12 years into replacing the mainframe platforms which have run the business for 45+ years, and we're not even halfway through the portfolio. Do not underestimate the complexity of these mainframes and the time & cost needed to fully replace them.
We have a legacy database at our company that we simply wrapped with a service. There are still a lot of clients that access the database directly but that number is shrinking. Limitations of the database can be worked around in the service layer so it wouldn't matter to us if we still use the original database in 10 years but it also wouldn't matter if we just migrate it to postgres one day.
> Ultimately, it's not some malicious intent or incompetence, but simply the acknowledgement that the legacy systems will not enjoy PBKDF hash+salt+iterations columns being added 30 years after the fact.
Are banks running their web interface on 30+ year old legacy systems? I'd expect the web stuff to be on much more modern systems, which call upon the 30+ year old stuff to do the underlying financial stuff.
Maybe, that COBOL codebase doesn't contain the web-facing stuff. It's not handling user auth and all of that. It doesn't seem to make much sense for the web-facing side to be so directly connected to the financial backend, anyway, because some kinda privilege escalation or crafted input exploit on the web side could give someone direct access to the financial backend. Those two things are likely pretty heavily separated.
So instead, it seems like the stuff holding just account holder information was given a password field to use on their fancy new HTML 2.0 webpage, but then just mostly left there ever since. The age of the financial side is fairly irrelevant in this scenario.
>How much ripping would HN impose on one of these institutions if they attempted a 100% best practices secure password upgrade and then subsequently had a complete IT disaster unfold (I can certainly link articles).
Not specifically related to password security upgrade, but it illustrates the impact of a bank's IT systems going down. Being able to run a credit card transaction and receive your paycheck is fundamental to the fabric of our society. When these processes are disrupted, people get very anxious and things start to fall apart rapidly. When is the last time you insert your card into the reader and thought "I sure hope this works"?
>As someone who works in finance/banking, I can assure you that this is not uncommon. Almost everyone is engaging in not-so-best practices with
Are there any standards that doing this violates, and if so do banks have a person in the org (or external to the org) that violations of said standard can report to?
> We are talking about password security in a system domain where there are arguably far more valuable assets to secure.
My worry is that because this is such a simple thing, if we allow ourselves to not do the best practice, where does it end? Especially since large organizations have many parts that don't communicate.
I agree we should think critically about risk, but I've also met lots of people who seem to backdate their logic - first they decide it's too onerous/costly to do a thing, then game out a reasonable enough reason why.
The problem with the latter is eventually your focus on compliance and handwaving will bite you hard, and you may not get a chance to be reactive because the breach will be so bad.
Look at it this way - banks will continue to support check payments for the foreseeable future, and checks violate every single security best practice by today's standards. The infrastructure to support checks without fraud burning everything to the ground was built up over centuries and works fairly well, this infrastructure works and has been extended to deter electronic fraud - so why waste time on technological navel gazing?
As someone who uses the bank being referred to in the OP, this makes me feel a little better... somehow. I use a unique password and 2FA and monitor my accounts but I am still considering switching banks to one that puts more emphasis on security.
You mentioned that only a few banks have the resources to tear down their systems and create a new secure one. What banks are these?
I cannot say which ones specifically, but if you OrderByDescending market cap and pick the top 5, you'd probably be looking at the only ones. Developing an in-house core banking system is a massive undertaking that is even larger than starting an entirely new bank from scratch (which almost never happens now). We are talking billions of dollars locked up just to start the project. Not even god himself could tell you if/when that project would complete. Bank cores are some of the most complex monstrosities on earth.
Honestly, this is bananas to me. I work for an IoT company with contracts to places like gas stations and chain restaurants. Freakin Wendy's and places like that absolutely don't want our product on their network and we have a base station connected to cell network along with our own local wireless network. (fwiw I agree, I think its best we aren't on their network)
I know this is an apples to oranges comparison, but I just find it weird that payment processors (not the banks, I know I know) are the main driver behind these restaurant IT security measures, but other financial institutions have things like this that they do.
I don't think network security is the issue here. Storing plain text passwords is likely a legacy problem, not an active implementation decision. And especially because some systems within the network can be vulnerable, locking down the network as much as possible at every possible point is even more important. Core banking systems can only run on 50 year old code because you have to get through many layers just to get close to accessing them.
"For some strange reason when a bank calls the FBI things move with a high level of expediency."
Is this really true? AFAIK illegal account accesses such as phishing etc is fairly commonplace. Criminals steal low value from lots of accounts, and also the way they steal is not really traceable, not at least easily. How would they even know where to send the guns? And also I'm not really convinced that FBI priorizes bank cases, they probably prioritize all cases based on monetary value and maybe some harm factors, but I dont think banks get special treatment on principle. Sounds like bullshit to me to be frank.
I once heard an ancedote, I forget if it was the FBI or Secret Service (who deal with some financial matters due to the weird hybrid nature of the agency), but one or the other, at the time, allegedly would not even begin to investigate a matter of less than 5000 USD. Now if you can establish it's one person making many sub-5K transactions they may, but that's hard to do if they won't take notice.
(The more I think the more I think it was the FBI, since the person also relayed that crimes against people often got short shrift since unfortunately one's feelings when threatened or harassed don't have an objective dollar amount)
>These assets are already implicitly protected by a massive apparatus extending as far as Ohio Class nuclear submarines patrolling the Pacific ocean.
A lot of good they will do you when a clever hacker from an unknown country logs in to your account, takes some money, and disappears untraceably because the bank's poor IT practices didn't involve enough logging! The bank might not even realize they need to call the FBI. The only practical security solution is to stop the money from being stolen in the first place: law enforcement rarely recovers all of the stolen assets.
I don't even know where to begin.. you store customer passwords in plaintext because everyone else does it and that's okay because the FBI will handle it?
Did you know you can transfer money out of an account with nothing more than the checking account number that’s printed on all your checks along with your name and home address?
American Express passwords are not case sensitive.
It is possible that they UPPER(...) the password before hashing it and then compare against that when you log in. This explanation would only be a little dumb because it reduces the domain of the password space. It also strains credulity.
It's because the old mainframes they used to use only accepted uppercase passwords. A lot of of financial applications were uppercase only. I know this because my dad would often message me in all caps and then say, "sorry I was working in FinAppX and had caps lock on".
When the banks first moved to going online, they were just building thin interfaces on top of their mainframes. Hence things like password being letters and numbers only and max 8 characters. Some banks made this explicit, some just did upper() and truncate(8).
And at this point some have converted to modern technology but their tech debt lives on.
Lol it's been that way for at least 20 years. Same with chase (well at least the bank one half of it).
It seems remarkably stupid, but it's way cheaper for them to refund any losses and/or pay for lifetime credit monitoring than it is to deal with customer service calls from people getting locked out because they can't figure out how to deal with uppercase and lowercase letters.
It's funny that my small-ish credit union is not only more technologically advanced, but also way more ethical (looking at you, Wells Fargo) and convenient, and has top notch customer service. Seriously, I've never interacted with more pleasant customer service reps than my CU.
Why are people giving their money to big banks again? Is it just advertising pressure?
Well, 25 years ago, when I opened at $BigBank the CU I use now didn't exist, and $BigBank offered services and availability that CU didn't (in 1995). Then, for the very long time I tied so many things to that account at $BigBank that it took almost three years for me to migrate all the accounts, business and personal and loans, etc to the new CU.
I get that Amex would do this. It seems to be their attitude. They seem absolutely bent on eating the cost of fraud to make life easier for their customer.
For the other banks, the motivation is harder to understand.
Same motivation. Call center costs related to account recovery are astronomical when you have tens of millions of customers. The authentication systems at large banks are generally a bit more 'observational' than just watching what password is sent (not always of course) so you can still mitigate many threats while still allowing for reduced login friction.
Just checked to re-confirm: Wells Fargo passwords are case insensitive as well. This doesn't confirm that they store passwords in plaintext, as you said they may just convert to uppercase before hashing, but it is bad practice either way.
There is a lot more possible entropy if QwErTy and QWERTY are distinct. However, there seems to be issues in the entire financial sector with inability to upgrade certain systems due to massive amounts of legacy code. That being said, my local credit union's system distinguishes case for passwords; and they were unable to give a family member their password (they had to issue a reset) which at least leads me to believe they are hashing passwords instead of storing in plaintext.
My gut reaction to your story would be to assume that your local credit union is doing a better job than the big banks, not that there's a good explanation for the big banks.
Credit unions frequently also offer better mortgage APRs, better savings APYs, better customer service, lower (or no) ATM fees, etc.
My local credit union (one of the largest 25 NCUA insured in the U.S.) until about 5 years ago used your debit pin as the only password for online login and didn't allow changing the password or adding a second factor.
They also disallow certain common punctuation, which is indicative of either storing in cleartext, a really dumb hash function, the inability to sanitize inputs, or someone who has no idea setting password policy. All of which are bad.
BNP's password interface is insane. Instead of having normal password options, they limit it to 0-9 and then implement some hideous and overcomplicated front-end that randomizes the positions of each number on a virtual keypad and you click to enter your password.
Sucks for users but means you can't use key loggers or click loggers to get users' pins. From a security perspective it's actually pretty good. Even if they offered more complex passwords most people would choose a simple one anyway. This likely reduces fraud for the most vulnerable. It obviously sucks for people who know how to protect their devices.
I've got an account number, which is only used by the bank (though it appears on all bank statements). For some operations (adding a beneficiary for bank transfer, for example), there's a double factor, either on my phone or by postal mail and then there's at least a 24h delay: they must know their security is bad, so the bank limits the damage that can be done, you can't just get hacked and all your account emptied in a hour.
And to change your phone number, you've to use a on-use password, sent by postal mail to your address.
Elsewhere in this thread, a commenter (actually multiple) mentions that many French banks use 6-digit pins for authentication.[0] Another mentions that in Spain, some telcos do the same thing.[1]
Blizzard battle.net used to do that, and probably still does: transform to lower or upper case (then hash because I'm giving them the benefit of the doubt), instead of dealing with customer support at a large scale of people messing up capitalisation of their passwords.
There's a middle ground where part of the bank wants to do things right, and the other half wants customers happy now.
As a pure hypothetical situation, if the old system was terrible and, say, stored things in plaintext and did case-insensitive password lookups, then the new system needs to emulate that if they don't want to piss off existing customers by making their old password suddenly not work. The security side is going say "just have customers make new passwords", the business side will say "we won't budge, this has to be seamless", and the developers will settle with the crappy middleground of uppercasing everything before hashing to emulate the old system. Maybe they even maintain naive hope of improving the system down the road and convincing the next set of execs that its ok to revoke everyones password to allow them to better the system.
Found that out when I typed in a (example) 25 character password, but at some point the field was truncated down and I somehow figured out that if I backspace IIRC 4 characters away, my saved password worked.
This chain of logic does not follow. It is possible that your bank is properly salt+hashing your password - the truncation may have been on the back end before, and is now exposed to you because the field is shorter.
Maybe - but why not indicate clear password length requirements on the password entry screen and/or have the PWE text input HTML form only accept password characters up to that max length?
Additionally, silent trucation and 'maybe we do salt and hash after all' makes no sense IMO. That's not to say that I disagree that this is a possibility, only that the whole point of a hash is that it converts something of arbitrary length to a single length.
Therefore, truncating data that gets inputted into the hash would be computationally wasteful for no benefit, because the hash function will always result in a single length.
This is a feature, not a bug. Facebook accepts the inverse casing of your password as valid in case you accidentally have caps lock on while typing it.
> The service rep proceeded to (accurately) describe my own password to me.
Wait, that alone doesn't necessarily indicate that they're storing clear text passwords. I notice you didn't say that they just repeated your password to you-- why do you think they store the whole thing in clear text?
HN readers are apt to demand hardcore passphrases, salting, 2FA, etc. But the reality is that banks have to deal with all kinds of people and situations. Your security as a bank customer hinges on more than just one password, it's also about monitoring patterns of behavior, being aware of what's coming and going from your account, and protection mechanisms like the bank's insurance.
That said, one would think that large institutions have learned their lesson about clear text passwords, perhaps this one hasn't? Is there a law against clear text passwords? How does anyone actually know if a financial institution has sound IT practices, by happenstance incidents like this? Really?
> Your security as a bank customer hinges on more than just one password, it's also about monitoring patterns of behavior, being aware of what's coming and going from your account, and protection mechanisms like the bank's insurance.
Some banks do this better than others from past experience. For example, I definitely have Bank of America notify me when I do something out of the ordinary. I had gone to a gas station and then my next purchase was pricey and online based. They put that on hold till I confirmed it was by me. They also have done so when I get gas from outside of town.
Other banks just cough up the money without a second thought. I'm sure they might have other "triggers" but it feels like mainly really the big players have proper security setup.
This is why I mostly use my credit card and pay for it before the statement is due. You have better protection on a credit card than you do on a debit card. I wouldn't use my debit card outside of an ATM.
> I definitely have Bank of America notify me when I do something out of the ordinary.
-And such routines are incredibly efficient; while commissioning one of our deliveries (heavy engineering equipment) in Namibia a few years ago, I found that the local power electronics distributor hadn't heard of my employer, and were (reasonably so) reluctant to hand over parts for $13,000 or so and send an invoice to Norway.
VISA to the rescue, and as we hauled the parts into the car to bring them down to the dock, my phone rings - VISA on the line, asking if I had happened to use my credit card in Namibia a few minutes ago, definitely expecting a 'No!!!!'.
-'Sure, we're loading the supplies into the car now, how come?'
Deep sigh and a chuckle at the other end. -'I guess it had to happen some day. You have a nice day, then.'
Lucky you. You got a phone call before just declining it! /sarcasm
Story time:
I was in London, on a multi-week vacation when my CapitalOne card got declined while trying to pay for dinner on the 3rd night using Apple Pay (for the contactless feature).
It wasn't an expensive meal.
There was no warning, no text-message, no phone call. I opened the CapitalOne app and it said my account is now restricted. I proceeded to call CapitalOne, and sit on hold, then get transfered a couple of times until there was a person who could flip the switch.
I paid for dinner, and my wife and I started back to our hotel. Half-way there, we stopped off at a Boots Chemist, and picked up some allergy medicine. Card declined again. I knew it was going to take 30+ minutes to deal with it, so I paid cash and we left.
When we got to the hotel, I had to call back, deal with the same multiple transfers to the person who could flip the switch. Then we would get 1 transaction through before it would get declined again. I eventually got a direct line to the guy who could flip the switch, and after the 5th time of me calling him, we spent a few hours investigating.
I have used this card in the UK for years on vacation. But increasingly merchants dislike the lack of pin, and needing a signature, so to be a good tourist, I decided to use it with Apple Pay, and that was apparently the combination that was killing my account.
The Apple Pay + UK card reader combination was apparently blanking out the CVV code for whatever reason, and while Capital One would allow a single transaction to fail that check, they would then suspend the account until a person verified the transaction was legit. My biggest gripe about this though was they did not even inform me each time it happened. So for the remainder of the trip I had to either dip the chip, and sign a receipt or pay a FX fee.
EDIT: Now that I'm thinking on it more, I think the reason the CVV was blank was because a CVV doesn't get used when your card is present. So I'm back to thinking this was a CaptialOne issue. They were seeing the transaction as a card-not-present transaction, instead of as a contactless transaction, at the time, I don't think they had contactless cards, so that might have not been a scenario they had accounted for.
We have all these stories of how our feudal lords have been nice and helpful
But why not get the notifications yourself on your own devices?
You can set up your own policies for approving transactions or whatever. I understand that the chargebacks can be done up to 60 days, which means “seller beware” in the current financial system as opposed to “buyer beware” in the crypto one. But in the crypto one, you are in charge of your keys. And the arguments made in favor of banks could have just as easily been made for printing presses or telephone switchboard operators!
-I can, to some extent, do this in my phone banking app; I can update region/type of transaction/maximum amount; my bank even lets me have whitelists ('No card-not-present transactions outside EU, except renewal of magazine subscription such-and-such from the US', for instance).
Changes are immediate.
However, I have the impression that the VISA/MC/AMEX fraud detection override my preference.
USAA will just decline first and ask questions later. (I'm not saying this is a good thing; it sucks as a customer.)
I tried to order from a German e-retailer with my USAA card. First time, rejected; I got a text asking if it was me. I replied "YES". Second time, rejected again, got another text... I had to use another (Chase?) card eventually. Still got a text, but this one was prompt and I was able to respond before the transaction was rejected.
These are all automated; no CS rep is sending these texts (or rejections) by hand.
In Europe GDPR covers that, many big websites started hashing after it
Edit: could somebody explain the downvotes? The comments seem to agree with me
Obviously GDPR is not a law about plain text passwords, but as the comments say it forces "the use of an appropriate hashing algorithm to store your passwords, protecting the means by which users enter their passwords, defending against common attacks and the use of two-factor authentication." etc.
> Although the GDPR does not say anything specific about passwords, you are required to process personal data securely by means of appropriate technical and organisational measures.
> Passwords are a commonly-used means of protecting access to systems that process personal data. Therefore, any password setup that you implement must be appropriate to the particular circumstances of this processing.
> There are a number of additional considerations you will need to take account of when designing your password system, such as the use of an appropriate hashing algorithm to store your passwords, protecting the means by which users enter their passwords, defending against common attacks and the use of two-factor authentication.
GDPR does not have any wording that refers to any technical specifics (e.g. password storage) whatsoever.
The most relevant passage is "the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk" from article 32; and it could be argued that having passwords in plaintext most likely does not constitute "appropriate technical measures" and doing so opens you up to fines based on GDPR if an incident occurs, but it's not really "a law against clear text passwords" but rather a law that simply says that you are responsible for how you [mis]implement your security and the consequences of that.
GDPR doesn't state explicitly "passwords must be hashed", but Knuddels.de was fined for unhashed passwords. The fine was specifically for the lack of hashing and not the breach that uncovered it.
Yes of course GDPR is not a law about plain text passwords, but (as the sibling comment points out), pretty much everybody considers the use of appropriate hashing as a requirement to to ensure a level of security appropriate to the risk.
One bank that has astoundingly bad password requirements is Westpac Australia. Usernames are an 8 digit customer ID, and passwords have to be exactly 6 characters long(!) consisting only of numbers and uppercase letters. Try it for yourself, note that the login form only allows you to enter 8 characters for the username and 6 characters for the password:
I complained to them about this years ago, they replied explaining they knew what they were doing and it was a balance between security and simplicity...
A company that my retirement plan used to be with was worse than that. The password could only be numbers and letters, and they would silently truncate your password to 8 characters. The worst part though, is the password was stored in a way that it could be entered on a touch tone phone. So case was silently ignored for letters, and the characters "2abcABC" were all stored as the number 2, and so on for the rest of the buttons on the phone. They also didn't support two-factor authentication. They've since updated the password requirement to something more sane, but it was baffling that they would ever do that.
All major telecos in Spain do the same. One of the largest asks you to set up only a 6-digit PIN to access the customer portal and no 2FA. They send you your PIN by SMS as a confirmation. All your invoices (with the details of the numbers you called) as well as other personal details, are "protected" by a 6-digit PIN. I want to think they have other protection mechanisms in place, but I seriously doubt it.
It's not identity theft, it's just fraud. Calling it identity theft is an attempt to put the cost and responsibility for ordinary fraud on the victims.
Even worse, a major French bank removed their perfectly fine password requirements and replaced it with a 6 digit PIN that you have to enter via an on-screen numpad. They explicitly block password managers from autofilling too! And I had just managed to get my parents to start using one.
Well Westpac had an onscreen keyboard for the password entry too until about 18 months ago. When they finally replaced it with a (thankfully password-safe friendly) text box they had this to say:
"At Westpac, we are continually striving to provide the highest quality service and security to help support our Online Banking customers.
From the end of May 2018, we will be removing the keypad from the online sign-in screen and replacing it with an open text box, which allows you to type in your Customer ID and password.
...
Security Guarantee.
We assure you that using the open text box to enter your sign-in details carries the same high level of security ..."
The US treasury does/did this on-screen keyboard thing as well (at least up until I stopped needing to login to that website within the last year or two). The "best" method I had around it was to copy the password out of my manager, use developer tools to find the '<input type="password">' element, and add 'value="[paste]"' manually.
I used to bank with WestPac and from memory it wasn’t possible to do this as they had some additional javascript running that would cipher every letter.
I got firefox to remember passwords for a couple sites that were blocking autofill. It involved opening up the xml file where passwords are stored, copying the latest entry, changing the url and ID number, then opening up the password manager in firefox and updating the actual password there since the XML file only stores an encrypted version. It wouldn't autofill instantly, had to click on the username box to get it to work but it saved me a lot of time from entering a massive password that system required.
This is common in Brazil as well. Allegedly they are trying to avoid keyloggers. Obviously people just improved keyloggers to take screenshots at precise times.
Looks like they are using Fiserv (lots of Fiserv references in the code). Fiserv is a huge provider of banking services. If Fiserv is requiring these ridiculous id/pw requirements that would be even more scary.
You should report to proper authorities about the severity of the issue. Reach out to their security or technical higher up department of the bank.
In your case, they may or may not be storing the password in cleartext. They might be using the two way encryption instead of one-way hash. Passwords should be hashed (with salt) and it is irreversible.
For a financial institution, revealing your password by a customer service rep is a big red flag. I would reach out to concerned authorities and do a proper disclosure.
> You should report to proper authorities about the severity of the issue. Reach out to their security or technical higher up department of the bank.
Switch your bank.
Do not reach out to the bank's security/technical! There's a non-zero chance that the response from the bank would be to reach out to the FBI and claim that you are the "hacker". It will create an enormous headache for you.
If you are going to reach out to anyone, reach out to the OCC.
It is about what you are optimizing for. You, a customer, notifying a bank would probably do nothing. You, a bank customer, filing a formal complaint with a banking regulator triggers procedures to handle it that a regulator has which in turn triggers handling procedures that a bank has. You do not complain that the bank stores passwords in cleartext. Instead you complain that the bank does not adequately safeguard information needed to access your account from the third parties with the example being the customer service agent being able to see not only your ID ( which they can and need to do their job ) but also your password ( which they do not need to access ). So not only the customer service agent can access your account while on-duty in the call center via a special system but also can either themselves or via another party access the bank account as if it were you.
Wow. Did they repeat your password or some hint you typed in a long time ago?
FWIW I have seen two companies that store passwords properly in a one way hash with salt but store statistics on every password like number of case changes and count of numbers and total length. I personally think that practice is infinitely stupid but can explain why they can say it has 3 numbers in it. One major marketing firm I did work for did that until we showed them why it was so dangerous. They were just trying to make users life easier but that wasn’t a smart trade off.
Personally I would like to know which bank. I have accounts at a number of major US banks and if one I use is doing this I’ll move everything out of them immediately.
Edit: to answer your question I’d hand the info to a major investigative news source and let them dig more. The FTC and banking regulators I don’t think will get involved unless there was damage.
Tell them you’d like to file an “Official Complaint” regarding a serious cyber security issue at that bank, and to transfer you to whoever handles official consumer complaints regarding cyber security. Regulators are sensitive to the word “complaint” (specific wording matters) and typically require that complaints are stored, prioritized, and handled in a prescribed way.
Ask them if they can get back to you with any resolution and leave your contact information. Update HN if you’re comfortable with that. Good luck.
That's about run of the mill for them (assuming we're thinking of the same bank). I called about my mortgage and they started reading off someone else's information. They also wanted me to confirm personal information over email...
Shoot. They are pretty open about the fact that their passwords are case insensitive. I had always hoped this was some clever implementation using multiple hashes upon password creation.
Or tolower() everywhere.
If it's true that they're able to read it back though, then why would they bother?
I know a bank (I forget which, in EU) that asked me for the 3rd and 5th letter to my password when I called them. Their thinkkng was probably that way the customer support on the other end would only see 2 letters of said password.
To be honest, while I'm aware it's not the best of practices, I don't care much. To me, the most important thing about bank security is that if there are fraudulent operations in my account, I can call and have them undone without much fuss. In this respect, my bank has behaved well in the past when random charges from an exotic country appeared in my credit card, in fact they noticed before I did, gave me a call and everything was fixed immediately.
For this reason, I think I'm OK with banks not having too strict security practices. If at some point they start being really paranoid about security, they might feel tempted to conclude that if there is fraudulent activity, it must surely be the client's fault, because their systems are unbreachable. I'd rather have the current situation in which I don't have much responsibility about security, problems happen but the bank responds.
Reminds me of TSB (UK bank) that asks, in addition to username and password, for three characters of a string when you sign in. Which is stupid because you can’t do it in your head easily. You actually need to see it written down somewhere when they ask for the 3rd, 11th and 15th character of that “memorable information”.
Pretty sure all UK banks use this method. For a while a tried to use a complex password for this, it became so annoying to use it is now a simple password that I can remember easily and count out. Like a downgrade attack on my brain.
For the "memorable information", I use a 32 character string that was generated with pwgen. I don't ever remember it asking me for the 25th or 30th character, it's always within the first 20 characters.
My UK bank has a "memorable word" which is separate from the login mechanism (which uses a physical TOTP pad). Authorising online transactions requires you to give "3rd, 6th & 10th letters" eg of your memorable word.
First Direct do this (but they've been that way for ever) for phone calls (better than me reading out my full password over the phone) along with a couple of secret question answers (I'm pretty sure customer support can't see the whole thing).
Online they are now forcing a one time PIN from a token generated from amount + last four digits of destination account.
It certainly isn't going to be news to the bank itself, so there aren't responsible disclosure concerns here.
And since the top advice here is to leave the bank, wouldn't the best thing you can do be to alert the public, so others can protect themselves as well?
Finance is between 20 and 50 years behind the curve in terms of fundamental/top-down security common sense, notwithstanding the handful of specific exceptions strictly necessary to ensure accounts are not actually made off with on a regular basis.
There are likely a good handful of hair-raising security issues (known and unknown) impacting your account(s) right now, that would cause you to scream and run were to learn of any single one of them (let alone the full list).
In this light, cargo-culting specifically [only] avoiding environments that store passwords in plain text feels like premature optimization.
With the above being said, I do agree with the sentiment raised elsewhere of contacting annoying persistent organizations that will follow up - apparently in this case that's investigative journalists and the OCC.
Do you want this person to mount a full blast investigation on their own? Most banks are mostly interchangeable nowadays unless you live in a small town and there’s only one bank you must use because you’re transacting with cash. They pay nearly zero interest, and they treat their customers like trash with monthly fees galore.
Thank you, yes I will certainly change all my financial set up based on no further information these two alarming comments. Who needs to look further into things - they are all the same after all.
His viewpoint seems to be that poor security practices around passwords in banks are not a big deal, due to the overall processes that banks use to prevent fraud.
I would tend to agree, for now, except that banks are doing their best to shunt responsibility for fraud onto merchants and customers. There are obvious financial incentives that will encourage them to continue trying to do so.
This is the best way to go about it if people at the bank aren’t responding. Nobody likes a PR nightmare, and Brian Krebs can handle this better with the right people if the OP provides enough evidence.
"Almost without fail at each engagement multiple C-level folks will approach after my talk, hand me their business cards and say something like, “I hope you never have to use this, but if you do please call me first.”"
My bank just changed from a 6-number password (literally no option for more or less characters nor anything but digits) to rational passwords this month. I don't know how my WoW account 10 years ago needed an authenticator but the people managing my retirement savings didn't light a fire under asses to get that done.
Legislation should have and likely still should be put in place.
Hashing passwords has been ingrained into our brains as it's an easy way to reduce risk. That said, sometimes sensitive information needs to be stored in a retrievable format (subscription credit card processing comes to mind). Every data decision that's made has an element of risk involved while accomplishing an end goal. With the right processes in place (encryption, limiting access (auditing that access), decryption authorization), the risk can be reduced to an acceptable level.
I don't think we have enough knowledge of the risk and processes in place at this bank to say if it's an issue.
A password should be considered a user secret and never be available in readable form by anyone in the company. Here, instead of having a rep reading out loud the password, they should have done a password reset or something with the same effect.
And let's not kid ourselves: if passwords are accessible in readable form they are eventually going to be read and used by someone ill-intentioned. There is no reason to have passwords in plain text, period.
I think you're prematurely jumping to the defense of this bank. What we do know is that the customer service rep was able to read the user's password in plaintext. Even if there is a "legitimate" reason for storing in a retrievable format (probably due to compatibility with legacy systems) the fact that the customer service rep could access that password tells me they do not have appropriate access control.
What is a secure hypothetical way of granting access to an account when the customer lost access to their email and phone (so no pw reset or 2 factor authentication will work)?
The bank has to have other processes in place. They're not going to keep your money from you. Let's say they accept a driver's license as authentication or a debit card. These methods are way less secure than a secret password and possibly introduce more security risk than a rep having access to view a password.
A bad actor rep could then [almost] just as easily get a fake ID created to get the same access the password would have granted. I'm also assuming that the password was completely visible, not just a truncated version.
This is the root of my concern of not knowing all the risks and processes involved. I don't want to jump to conclusions without knowing the whole ecosystem.
Can you name a single reason for having a password in a retrievable format? Credit cards, account numbers, etc need to be retrieved so it makes since to not hash them. Passwords on the other hand should only be known by you so there doesn't seem to be any reason to have a retrievable format for them.
I did some tech consulting with some ex-banking Wall St. consultants. It's not a monolith. That industry is very conservative.. and some companies get so frozen in time that they become complacent and go full Equifax. They're always playing catch-up because every criminal and most people would like to rob a bank without a gun, so their threats are numerous and perpetual. (And then there's Wells Fargo.)
It seems like banks should adopt that credit-file-based challenge protocol with the multiple choice questions containing ~50% or so spurious data that answers (None of these). I had to do it to reset a hospital's patient login for myself the other day.
DOB, SSN, address, phone number aren't secret-enough "things you know" or "things you can do." For signatures, I always sign a smiley face because they're completely worthless.
Perhaps even better would be to:
0. have the bank have a relationship with the customer
1. issue 2FA device or soft-2FA
2. use per-customer colors, pictures and words on the password screen to deter impersonation and phishing attacks
3. It seems like hardware is so cheap these days, the bank could issue customers a hardened tablet with a pin, biometrics & face recognition that VPN'ed back to them and functioned only for their banking apps. It's much easier to support and harden one controlled device than zillions of likely malware-infected Chrome on Windows 10 or macOS Catalina's Safari on unsecured public WiFi.
>2. use per-customer colors, pictures and words on the password screen to deter impersonation and phishing attacks
I've seen this on multiple sites, and I always thought it was snakeoil. All you need to do to bypass it would be to make your phishing server contact tho bank to request the per-customer color/picture/word.
What is particularly wrong with Catalina on unsecured public WiFi? Are you just making a pint about public WiFi or is there something wrong with Catalina?
Wells Fargo used to require that a new password be sufficiently different from an old password. e.g. if my password was "Madison111$" I could change it to "Madison222$" except that when I did so I would be prompted to change it again the next time I logged in. Since I always iterated on a version of my password this was an issue. The reason was explained to me when I finally called and asked why I was being required to change my password every single time I logged in. So, I changed Madison to Matthew and was good to go.
Not sure how they were doing that if they weren't storing the password in plaintext.
It is definitely possible to do that. When the user submits a password to save, it hashes it and saves it to the database. At the same time, it calculates x number of variations of the passwords, hashes those, and saves those to the database as well. The next time you go to update your password, the hash gets compared against the actual previous hash as well as the x number of hashed variations and if any match, it gets rejected.
Not super efficient and in most cases, probably not worth the effort. But completely doable to do.
How many variations will you store? It's very easy to calculate the Levenshtein distance on plaintext data, but basically impossible to enumerate all the variants and hash them.
For user accounts on a Linux system, this is often done during the change process. `passwd` asks for the old password, and then the new password twice. At this phase, the password program knows both the old and new passwords unhashed, and can compare them. So while the other answers may also be right, if it's really just comparing the current password to the old one, then it can be done this way without storing passwords in plaintext.
But it was a little unclear to me from your description how many old passwords are being compared, or if the the password change method requires entering the old one too.
Microsoft does this. When logging into PowerBI, you have to change passwords every 6 months. They somehow store last 5 used password patterns and won’t allow re-using them. So for every 6 months you gotta come up with new combinations and remember them.
It’s a pain in the ass because I only login once in a while. I refuse to use their software until they give a sane password experience with two factor auth. Well I refuse to use it because I have to click 20 things before I can even proper login.
One (devastatingly bad) way to do that is to store hashed subsets of your password string, say the first and second half, and if one matches then your new password is considered too similar to the old password
Note that this demolishes the security protection of hashing because brute forcing two (n/2) length password hashes is much easier than brute forcing a length n password hash.
One way to do this is to store a much weaker hash of the password and require some minimum difference in that hash, e.g. add all the character codes together, and reject a new password if its sum doesn't differ by at least 50.
Something similar happened to me once. An e-commerce platform gave my wife my plaintext password. It was my "low security" password, the same one I used in dozens of sites. That's when I started using a password manager so now every site gets a different random password.
It never ceases to amaze me what the state of online banking is around the world.
Here we have something called BankID which comes in two flavors, one that is a physical token that generates TOPT used to log in, either in a combination with a password or a PIN on the token device itself, referred to as BankID. And the other, much slicker solution, called BankID on Mobile, which runs as SIM-application on your phone where you digitally sign the login request using a PIN. The user can also verify the request visually on both the computer and phone using a unique keyword.
One killer feature with BankID is that you can use it to log in to any service that has BankID, like your insurance company, looking at your tax return, other banks, etc. This is perhaps the biggest issue with it since the system can get overloaded when there's a country wide rollouts of tax returns and such. This has become much better lately since they've started to roll out things like tax returns as soon as they're ready instead of doing bulk releases.
Now that banks aren't paying useful interest rates they are mostly only tolerable for security and convenient access to your money. If they can't do those two then... what exactly are they for? Likely nothing.
Be extra careful with your details associated with that account and anything it touches. eg any direct debits might "change" without notice. Enable all added security you can.
But realistically, there's no silver bullets. Refinancing can be expensive. Cost/benefit applies: Might not be worth refinancing just for this. Just be vigilent about the accounts involved.
I had a phone company that bragged about its security. So I tested them out. Yup they sent my password via text. Ok then. Contract was for six months. Not worth switching. But also not worth renewing.
Since it seems this is PNC, I am one of those who now needs to find a new bank. Any recommendations? I used PNC for my checking/credit but already use an american express high yield savings.
Why? The compliance requirements don't require hashing (iirc, "commercially reasonable" protection is/was the standard), so you should assume that any other bank is doing the same thing, as they probably are.
All that is needed to steal your money is the bank account number, which you probably have mailed out or otherwise provided to numerous random third parties, who process them with other third parties. There's almost no information in there that isn't already available to anyone who cares to look.
A more reasonable approach that actually impacts your security would be:
- Opt-out of electronic communication and get paper statements and account notifications. (This ensures that you receive notice, in the mail, about changes of address and other changes)
- Opt-in to notifications about large transfers or low balances.
- Disable Bill Pay features at the bank.
- Disable external ACH transfers.
- Request wire transfer privileges, which with some banks allows you to get a physical token to secure access to your account.
- Use a dedicated PC/iPad/Chromebook/etc for your banking to reduce the risk of malware capturing your banking details.
If you're going to switch banks over this, look for a credit union small enough that they use an off the shelf banking solution, and figure out what the default configuration of the solution is.
Thanks for recommendations. I will admit I overreacted when I saw the headline and found out it was PNC. Just not the thing I expected to start my day hearing.
I already use 2FA, a unique password only with PNC and alerts on all account activity, including logins.
I moved from PNC to SoFi a few months ago and I'm very happy with them. ATM fees everywhere are automatically reimbursed and their customer service is fantastic.
Make sure if you have a Virtual Wallet account with PNC to manually downgrade it to the lowest tier, and keep $500 in it until you're ready to close the account. It'll charge you $7/month otherwise, more if you're at a higher interest tier currently.
If you see my other comment, I don't think I am going to switch right now but it is good to check out alternatives. I am from the DMV area and capital one is huge here and pushes the narrative that they are an elite tech company VERY hard around here with recruiting.
I figured they would have the most secure systems out there with the army of SWEs they recruit in this area
Fidelity's passwords map to characters on the phone keymap, e.g. the characters "j,k,l,J,K,L,5" can all be represented by the number 5 on the phone. Holy entropy, Batman!
I can attest to this. When you call in you just have to type in your alphanumeric password completely using the 10 digit phone pad. Just like in the 90s. On the other hand Fidelity has the best customer service I have ever experienced so I guess everyone has competencies.
Does anyone know if PCI rules call for non reversible storage of passwords (hashing)?
I looked quickly online but the only reference I could find was that "passwords are protected by strong cryptography in transit and at rest", which seems to allow wiggle room to store passwords in reversible but encrypted format.
There is not much you can do, I’ve tried to inform banks of security issues in the past and all that happens is you get a form letter saying thanks for writing we are doing that on purpose for reasons we can’t explain to you and we’re not interested in outside help. Synchrony and Citibank, I’m looking at you.
What does the password give access to? Full online banking (e.g. being able to do transactions?). Does login not require any further authentication beyond the password?
If the authentication still requires using some kind of good 2FA then it's less serious to have the password in plaintext. Still bad of course.
If this is for some other service that doesn't let you do any transactions then it's not as serious either (still bad and embarrassing, but not that serious)
Even with properly hashed passwords etc I'd be worried if my bank allowed login with only a username/password and no further security. I didn't think even that was a thing in 2020.
Santander in the UK does this too. You can tell because they only ask for 3 characters out of your password whenever you log in. What's ironic is that whoever did that propably thought they were being super clever.
There is nothing in UK law that says banks have to store your passwords "securely".
Issues like this have been raised in the past, and authorities like the ICO have said no law is being broken. GDPR, for example, does not specify technical mechanisms required to store any form of data.
Unfortunately, they are still non-committal on what is required. They advise that passwords should be hashed, but there is nothing that makes that a binding requirement.
The gist is still "do what you think is appropriate".
The ICO talks about balancing risks and convenience, and the banks will argue that their systems are secure overall, and don't make the consumer liable anyway.
Under the ICO's guidance, an organisation could argue that plain text (or reversibly encrypted) passwords allow them to do things like password reminders.
You or I might think that's terrible, but they can argue that it's a better user experience.
If you store an individual character hashed then it is trivial to brute force it. I don't think there is a bcrypt work factor that you could use that would prevent brute forcing but would allow the individual character to be used for authentication.
I once did an API integration with a very popular well known brokerage. When we asked for a test account for their API... well they didn't have a test environment, so they just gave us a real account with 10k dollars in it with instructions to be careful. The test account was something like "apitest11" and the password was like "11apitest". Did that money mysteriously get stolen? Yup! (Not by me definitely, but that account must have been shared with 15 or so people, with a trivial password if it had been an outsider)
When I went to TSB (UK) open an account for my partner and she was asked to type her password on their computer she asked when she can change the password, are they any limitations, like wait 3 days before changing password. The assistant responded "why would you ever want to change your password? you can type any password you want now, just please type your password". This was so weird we didnt use the account for a few days, changed the password, waited a few days again and after that deposited money.
That's still better than the SSA. Every employer must use SSA to submit W-3 to report employee wages. They only accept case-insensitive passwords up to 8 alpha-numeric characters.
A popular bot protection system provided by a third party used by a number of US banks would accidentally disclose plaintext usernames and passwords to the bot protection software.
I'm not sure how the bot protection software was deployed but looking at marketing materials I suspect the data was sent to the third party as part of a SAAS service.
We believe this was accidental because a later version of the software stopped doing it. I'm not sure if there was a notification by the third party to users about this flaw.
The law is not behind or antiquated in this case. Bank cybersecurity has been regulated for quite some time now, and failing to adequately secure your digital assets is a compliance violation no different than failing to catch obvious fraud.
It's very likely that your bank is based and regulated by New York State, even if it isn't physically based there. Contact the NY State attorney general's office, they should take you seriously.
Wells Fargo isn't really Wells Fargo. It was a massive bank in the midwest called Norwest (based in MN, but offices all over midwest). Norwest acquired WF primarily for the superior name recognition. The merger with Wachovia happened after that.
for the longest time they you could set your password to be anything, but they only checked the first 8 characters and it wasn't case sensitive. Just chalk it up to shit being written in the 80s.
This is doubly bad because not only is your password in plaintext, it also means that anybody who works for the bank is able to view said password.
Don't get me wrong, plaintext stored in a DB is bad enough, if the DB gets compromised, but apparently they don't even need that as they have an interface that customer service can use to view your password.
Use a generated unique password for every site, preferably with a password manager. Along with the absolutely most important thing you can possible do for banking security, which is to check your statements/transactions promptly every 30 days. Beyond that it's not really your worry, besides having to possibly attend to helping them clean up any messes.
It is possible that this is intended and that they will prompt you to enter a new password on login.
Ask yourself these questions:
Are you sure it was your password? Did they generate a password for you? Did they verify that you are the account owner by asking you to enter the "hotline-pin"?
Some people have noted that they might store part of your password, but they could also be using some sort of master key to encrypt their passwords. Meaning they can also decrypt them and provide a UI for their help desk.
Hypothetically, if that were the case, it creates a single point of failure for the whole system and is effectively "security by obscurity," imo. A malicious actor with the time, resources, and/or internal connections could obtain said master key and have access to the entire bank's database.
You should give them 7 days and tell them you have a responsibility to let the community know what bank it is. You should communicate this clearly to the bank and then let us know.
I got locked out of my account (forgot my password) with said bank and they had no way of telling me my password. Had to wait for them to send me a OTP mailer so that I could login and create a new password.
I was going to say vote with your money and leave but then it occurred to me where do you go, is there any public list of banks or institutions that have passed some kind of security audit?
They have to no? If you want to link some other bank accounts you have to give them the associated credentials that they pretty much have to store in clear (or encrypted at rest whatever).
Proud of my bank in India (State Bank of India) which is crazy over security. Secure password requirements for login. Another completely different password for managing my banking profile and adding bank transfer beneficiaries. OTP for each money transfer related activities I do from the bank.
Are local/regional banks more likely to have better security practices? I'd think they have worse ones, especially since they don't have the money for cybersecurity consultants which are usually fixed cost.
Unfortunately I'm not awake at all hours of the day to respond to internet comments. But if you want further evidence that their passwords are indeed stored in plaintext, consider that their password rule prohibits the special characters !, /, \, <, >, etc. You can verify that yourself.
I once used a small DNS hosting provider where I used a password ending in '!!'. I was in the process of attempting to transfer the domain to another host but it was taking them days, and they communicated several times they were having odd issues specifically with my account. In that same time I was learning how to use Linux and MySQL, and ran into issues using the same password for the MySQL admin during a command line install. That's when I learned !! is short for "run last command". Took me a few more days to think maybe that's what was causing issues at the host provider, so I changed it, told them what I did, and asked to please try the transfer again, and it worked. I never got confirmation the password had anything to do with it, but I let support know my suspicions.
Is there actual damage? At the end of day, as a customer，all I care is my money is available (not stolen) and I can access it when I need it. Why should I care about implementation details ?
Heres another analogy, I've been using a black box sorting function from third party library, its super fast and satisfied all my requirements. Then they told me they implemented it using <insert super scetchy/controversial method>. From my perspective, as long is doing a good job and works as I expected, I don't care how its implemented.
..., but I don't care how it is implemented as long as it is secure.
I totally agree with this part. The problem is that the security of the implementation is the security of the implementation. So your sentence reads:
This is implemented extremely insecurely, but I don't care how it is implemented as long as it is secure. I also don't care about water, as long as it is dry.
Yes, I expect the bank to protect my money. What I'm saying is how they actually do it, clear text pwd or whatever is not really my concern. Why should I ?
You’re right, you’ll probably get your money back if your password gets stolen.
Eventually. Might be real disruptive if you’re in the middle of buying a house.
I’d probably choose my bank to minimize my chances of dealing with a giant bureaucracy for however long (and the non–zero possibility that I actually won’t get my money back). But if that’s not “damage” to you, feel free to keep doing business with them!
>Might be real disruptive if you’re in the middle of buying a house.
Agree, I consider this a damage but if the bank can avoid causing me any disturbance despite of using clear text password or <insert any other questionable security practice> then why should I be concerned ?
The same reason you might be concerned even if a doctor can deliver a baby safely despite not washing his hands in between a cadaver examination and touching your wife.
Sure, If the doctor can deliver baby safely and not causing any other damage despite not washing hands then what's the issue?
That's why I asked what is the actual damage. Is the money is stolen ? Is the money can't be accessed ? If the bank doesn't do me any actual damage despite the clear text password then I don't see why I should be concerned.
I guess I can see that for some people, clear text password usage can cause them anxiety and lose some sleep.
Are you genuinely saying that when you see someone putting you at risk, that you do not see a problem with it until a problem actually occurs?
Imagine you worked in a building for a week and didn’t die in a fire. Would you have a problem with discovering that the writing was done by a amateur, there were piles of lint and fabric everywhere, and there was only one revolving-door exit?
If yes, then you understand the problem of risk and its just a question of magnitude.
If not, then you should be aware that you see the world dramatically differently than most people.
Sounds like they are open to social engineering attacks, if you can get a rep to describe the password to you... Meaning I could pretend to be you and get your money.
Well any risk is going to be paid by the customer in the end. If they lose 0.01% of their deposits because of a vulnerability, they're gonna be charged more by their insurance and eventually charge it on their service fees to customers.
You're implicitly suggesting that the bank can either pass on the costs without people noticing, or that they have no competition, so they can set fees and interest rates to whatever they like. I don't think either is true. We do regulate banks, and this is why it's vital.
You could just as well say the cost is going to be paid by the shareholders, the public (in the form of reduced taxes), or the employees.
Do you really think the only thing the bank does to log people on is to check the username and password? Banks are way more sophisticated than this and it goes well beyond merely string-matching credentials; there's all sorts of other environment, behavioral and heuristic patterns used to establish legitimacy. Even if you rose this issue with the bank, they'll hardly change their modes of operation, and you certainly won't ever see a bank telling you how they do it, but those "hidden security features" make a significant contribution to the bank's security posture; ie: https://twitter.com/mbna/status/1016270694299127809?s=20
In addition to this, you might be interested enough to take note of a number of your banks arbitrary password rules, that one could follow to make similarly negative assumptions. ie;
"hey [bank], because my password is limited to 16 characters, does that mean you've got a varchar(16) column somewhere storing plaintext?"
>but those "hidden security features" make a significant contribution to the bank's security posture
Which is totally bullshit because I have RFP enabled in firefox, and I get asked for my security question on every log in, even though my password is randomly generated and reasonably secure.
Please report this via the US-CERT at https://www.us-cert.gov/report
This will allow you to report it, eventually from an anonymous email address, without exposing you directly to the bank which might react bad to you. CERT can handle the coordination with the bank, this is what they do.