4 ms·

$employer has recently been acquired by a big international corp. As part of the acquisition they have been "auditing" (really checkbox ticking and superficial

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

yread 7y ago
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.
- zdragnar 7y ago
  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.
- jniedrauer 7y ago
  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.
cheerlessbog 7y ago
Could you hash using both, your preferred algorithm first then theirs? That would make everyone happy.
- judge2020 7y ago
  bcrypt(sha256(pw)) works I believe, but it might not be enough to satisfy the policy.
  - Dylan16807 7y ago
    It's actually better than plain bcrypt because you can allow long passphrases.
    - bouke 7y ago
      Is it better? The suggestion is vulnerable to a sha256 collision attack.
      - DuskStar 7y ago
        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.

yread 7y ago

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.

zdragnar 7y ago
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.
jniedrauer 7y ago
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.

cheerlessbog 7y ago

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

judge2020 7y ago
bcrypt(sha256(pw)) works I believe, but it might not be enough to satisfy the policy.
- Dylan16807 7y ago
  It's actually better than plain bcrypt because you can allow long passphrases.
  - bouke 7y ago
    Is it better? The suggestion is vulnerable to a sha256 collision attack.
    - DuskStar 7y ago
      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.