[bjeds]

I feel bad for the author for publishing this article.

If your (the author) mindset is that "everyone else is an idiot", be it management, or regulators, auditors or some other group that is not your group (engineer?), then unfortunately you have an attitude problem.

If furthermore you maliciously misinterpret the other group, saying "they want us to be compliant, not secure", based on misunderstanding the domain expertise _of your own group_ (!), then you are a liability to your business and should be kept at arms length from external auditors.

Because the author clearly has no clue what he is doing, and based on his technical shortcomings he is speaking down on others who are _actually_ doing their job correctly: the auditors.

Why is the author comparing bcrypt using 32 iterations with sha512crypt with 5000 iterations? Why not increase the sha512crypt iteration count by orders of magnitude if he want the hashcat test to fair equal or better under the testing methodology in use? Why is he using hashcat and basing decisions solely on that tool? Why is he using shacrypt at all and not a a proper KDF, such as PDKDF2, plugging in SHA2?

[tensor]

Compliance is in fact not the same as security. Just like our non-technology laws are not equivalent to ethics. Laws exist for many reasons, and change over time as societies ideals and requirements change.

For example, just because we have laws against burglary, it doesn't mean that you can leave your door unlocked. Being "compliant" in no way means you are being secure. This is highly dangerous thinking that many many many organizations are guilty of.

As for the regulators, yes, they care about you being compliant not secure. Just like lawyers care about things being legal, not "right." It's their job to make sure you comply with the law, it's not their job to make sure the law is correct, or that you are doing things in your best interest outside of what the laws say.

Also, just like every law, security compliance regulations do become outdated, in some cases even being actively harmful. For instance, look at how password compliance has been overhauled in the last several years. Previous to this, many people knew based on technical data and research that old password compliance rules were not best practice, or even outright harmful. The auditors didn't care, it wasn't their job to evaluate whether the existing compliance rules were right. Eventually standards bodies caught up, but even today you have some compliance people who won't let go of the old ways.

So in my opinion, the author has a very good and correct point, compliance isn't about being secure. It's necessary to have, like many of our laws and regulations, but it's not the same as security. We should strive that our laws always match outcomes and current understanding of best practices, but there is never a 1:1 equivalence.

[feoren]

You're criticizing the author for not adequately understanding the regulatory concerns but letting the regulators off the hook for not adequately understanding the engineering concerns. Frankly the latter feels more important and more beneficial (to everyone) to improve upon.

[CaptArmchair]

The author didn't relate how the exact conversation went down. The closest we get is this:

> But the auditors were adamant. They did not care that the approved algorithms were weaker. Nothing would change their decision.

That's the 100% the author's perspective. It's quite possible those auditors were aware of the existence of bcrypt and what it does.

Even so, their personal opinions simply didn't matter. And they, quite likely, tried to point this out to the author. Yes, a stronger algorithm - bcrypt - existed, but as long as it wasn't a formally vetted FIPS approved algorithm, it simply wasn't an option for operational use.

Compliance isn't bad in itself. It's a tool. Compliance is implemented to ensure that large and complex organizations can continue to function as a structured system. It helps ensure accountability, audit-ability, integrity, reliability, sustainability and other "abilities".

There is a trade-off, though, when it comes to day-to-day operations. You simply can't improvise. In a large organisations, that's a good thing, which the author clearly hasn't understood.

While the direct result is that their systems security is now weaker, that same compliance also shields them from any legal repercussions. If those systems get compromised, they can always point to the list of sanctioned algorithms and the oversight. That's how accountability works.

You'll find the freedom and the flexibility to implement your own solutions in smaller organizations. However, that comes at a price: The buck stops at your desk. When something breaks, all eyes will turn to you in order to fix it. And there will be little to hide from.

Of course, I'm well aware that there's more nuance to it. There are plenty of stories on both sides of the aisle were the lack of or very existence of formalisms either saved the day or directly lead to catastrophe. That doesn't imply that one is always better then the other.

[pnutjam]

The way to approach infosec is, don't trust anyone and verify everything. This is just part of the IT world.

I'm not an auditor, but my impression is they not only don't trust each other, they also hate each other. Auditing is a job for people who don't like other people, which is ok. Just be aware.

[bostik]

I'm going to take flak for this, but I believe it needs to be said. (And for the record, I have been dealing with audits and auditors continuously for the last 5 years. In 2019 I spent 25% of all my working hours directly working on audits or babysitting auditors.)

Auditors are accountants, who secretly harbour dreams of being lawyers. With years of disappointment and self-loathing, they do the human thing: take it on everyone else.