Comment by the8472 | Hacker News Reader

Comment by the8472 | Hacker News Reader

Parent Full thread

$employer has recently been acquired by a big international corp. As part of the acquisition they have been "auditing" (really checkbox ticking and superficial API scans) our applications. One of the issues that came up is that we were using bcrypt as password hashing algo and our new overlords had a whitelist policy that only included sha2 variants and perhaps ripemd or something like that. We argued that their whitelist was totally inadequate for password hashing and pointed to multiple national standards bodies. The people doing the audit just ignored everything we explained to them and repeatedly pointed at the policy (which they weren't in charge of themselves).

Several people on my team were opining to just comply because it's the easiest way to do and they were concerned about their job security if they would go "against security".

My takeaway from that experience was that the people in charge of corporate security policies and audits are not experts in security, they are experts in reshuffling responsibility and covering asses. And many developers are easily cowed by them.

The result is compliant software, not secure software.

Compliance is really the biggest source of bullshit jobs. All the paperwork you need to get certified, the manhours spent reviewing it, all for marginal benefits.

Many (most) processes like that started because someone got burned by something, and the people ultimately responsible said "make a process so it doesn't happen again".

Often times companies go through this with internal processes as they grow, and some grow out of that phase.

Other times (especially at even larger companies) processes are adopted "from the industry". While not necessarily bad, it also requires flexibility from feedback. In parent's case, auditing to ensure sensitive data is encrypted to a minimum standard is reasonable , auditing to ensure any encryption is limited to a very narrow set of algorithms is not.

I worked on a project once that contracted out security audits to HP and those were distressingly not good security audits, just vague automated checkbox-checking of a list put together with zero context.

The loss of efficiency is still probably worth it. At least, it's worth it for systems where failure has severe consequences. You wouldn't want to ride an elevator where they skipped all the paperwork, for example.

Could you hash using both, your preferred algorithm first then theirs? That would make everyone happy.

bcrypt(sha256(pw)) works I believe, but it might not be enough to satisfy the policy.

It's actually better than plain bcrypt because you can allow long passphrases.

Is it better? The suggestion is vulnerable to a sha256 collision attack.

Except that for a collision attack to be a thing, you need to know the value you're trying to collide with - and that requires reversing bcrypt.

Reply on news.ycombinator.com