Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: A major USA bank is storing passwords in cleartext – what to do?

news.ycombinator.com

Post reply on HN
Print view View original

121–130 of 328 posts

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#121

Post by helen___keller »

wj wrote: post #105

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…

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.

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#122

Post by cranium »

bodhi_mind wrote: post #109

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), decrypti…

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.

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#123

Post by lb1lf »

giancarlostoro wrote: post #77
crispyambulance wrote: post #75

> 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 kin…

> 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…

> 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.'

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#124

Post by acranox »

wj wrote: post #105

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…

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.

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#125

Post by SkyBelow »

chris_overseas wrote: post #80

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: https://banking.westpac.com.au/ I complained to them about this…

Expect this to keep happening until we put the full and entire cost of identify theft onto the companies who are defrauded by the thief.

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#126

Post by 0xcde4c3db »

wj wrote: post #105

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…

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.

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#127

Post by matz1 »

diffeomorphism wrote: post #114
matz1 wrote: post #97

Earlier quoted context omitted.

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 . 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, at the end of the day, as long as the money is there when i need it, I don't really care how you store it.

Re: Ask HN: A major USA bank is storing passwords in cleartext – what to do?

#128

Post by jcims »

slumdev wrote: post #117

Name and shame. I'll start: 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.

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.

Post reply on HN