Hacker News Reader

Comment by shove | Hacker News Reader

I’ve worked for Fidelity and while there’s a grain of truth here, this is mostly horseshit and conjecture. Upgrading SQL or whatever isn’t going to happen without a very good reason because you risk fucking something up in the process. Enterprise orgs can’t move fast and break things. By definition that means they’re permanently behind the curve.

View on HN

Not doing anything also risks fucking up something in the process: customers' money because of the lack of security. But assuming that staying within "accepted standards" for secutiry indemnifies the bank, it's obvious that they shouldn't care about lost savings. In case shit hits the fan, they would be covered, and it's the problem of the customer.

I'd like to be proven wrong here - that banks take responsibility for behind-the-curve security practices.

> Not doing anything also risks fucking up something in the process: customers' money because of the lack of security.

Sure, but the cost of dealing with a few customers worth of problems is substantially lower than the entire org grinding to a halt because the infrastructure doesn't work anymore.

Ah, this would be the same Fidelity that within the last five years limited users to 12 character passwords?

Yes, and yes passwords are encrypted / salted. They’re not morons.

>> ... limited users to 12 character passwords?

> Yes ... They’re not morons.

That seems debatable.

To be fair, some of them are morons. There are morons at any organization of sufficient size.

I wasn't on the teams handling security, account login / access, etc so I can't speak to specific implementations (nor would I), but the folks I interacted with were super sharp.

Encrypted? You mean reversible encryption. I hope not.

Salted? Just once? Or through something like bcrypt or scrypt? Because just salting nowadays is pretty much useless.

You're misunderstanding the terms a bit. Salting is only done once because it's a random string you apply to the users password so that if two users use the same password they do not result in the same hash. This is primarily meant to combat pre-generated rainbow tables and forcing each password to be broken individually.

You're thinking of multiple rounds of hashing, designed to increase the computation cost of the hashing. For example Bcrypt has a built in cost factor. While this is definitely important it's not quite the same as salting.

Can you provide a reference to the uselessness of salting. If it is useless many people need to know!

Reply on news.ycombinator.com