13 ms·

They want us to be compliant, not secure

• resoluteteeth 6y ago
  Is it that unreasonable for them to want people to use FIPS approved algorithms? I mean all you're showing them is how fast the current implementations of the algorithms are, and obviously being too fast isn't great for password hashing, but your benchmark doesn't in itself actually prove the security of bcrypt as a hash algorithm so I don't know why you would expect that to convince them. Maybe the real problem is that the FIPS standards are too conservative?
  • jnwatson 6y ago
    I would say it is somewhat of a misuse of the standard. That a cryptographic hash makes an ok password function is somewhat accidental. If they had required PBKDF2 that would have made more sense. That at least confirms you used the pseudorandom function correctly.
  • TimTheTinker 6y ago
    The real problem is that security decisions are being made by bureaucrats. Full stop. Bureaucracy invariably requires compliance, and only compliance. Some problems can be cast in terms of compliance and thus solved in a bureaucracy, but security is not and never will be one them.
    • CyanLite4 6y ago
      Are you saying the auditors are the bureaucracy or the FIPS standards approvers are the bureaucracy? All the auditors are saying is that you have to use a FIPS approved algorithm. The FIPS people have real cryptography experts who research this stuff on a daily basis that also help set the security standards for the entire U.S. government. The author is coming along here saying they are using something else that’s not approved by FIPS (for good reason I might add) and they’re mad the auditors won’t let them simply because “everyone else is using bcrypt”.
      • TimTheTinker 6y ago
        > Are you saying the auditors are the bureaucracy or the FIPS standards approvers are the bureaucracy? Both. > All the auditors are saying is that you have to use a FIPS approved algorithm. ... which is a problem, because FIPS approved doesn’t imply secure. Bcrypt is a better password hashing algorithm than any FIPS-approved algorithm at this time. Don’t agree with me? Read up on it. I’m not necessarily recommending it though - there are others that may be even better, depending on the circumstance. > they are using something else that’s not approved by FIPS (for good reason I might add) What reason? Is there an expert cryptographer’s opinion or any expert cracking reports you can reference? Just because a group of experts decided a certain list of algos were “approved” several years ago doesn’t mean that newer algos designed or popularized since then are less secure. Authority alone doesn’t confer reality or truth. And unlike compliance, security is a process, not a destination.
    • dkarl 6y ago
      Bureaucrats track compliance. People who know security and bureaucracy (ideally) design the standards. Engineers are still responsible for building secure systems that happen to also check all the compliance boxes. Compliance is mostly intended to prevent really hideous errors from falling through the cracks. Nobody believes that you can't build a compliant, insecure system, or that you can't build a secure, non-compliant system.
      • TimTheTinker 6y ago
        Agreed, this is the unfortunate truth at present. Though by preventing hideous errors from falling through the cracks, compliance requirements also often prevent the best decisions from being made.
  • vlovich123 6y ago
    Sha-2 isn’t appropriate as a password hashing algorithm so there’s something wrong with the compliance team and the engineers not correcting them that they need a KDF. Apparently NIST even calls out regular hash functions as being unsuitable for hashing passwords [1]. You’d need to use PBKDF2 although maybe this advice has been updated since? Maybe they were being recommended PBKDF2 because that too is more susceptible to GPU attacks? Really should be using scrypt rather than bcrypt anyway. All that being said, using sha2 isn’t necessarily “wrong” if you can force your users to use longer passwords. My understanding (could be wrong - I’m not a security algorithms expert) is that all these “hard” hashing algorithms are trying to provide guarantees even if your user has poor security hygiene. If you can force your user to use a randomly generated 20 digit password then you can significantly reduce your server load and reduce latency by using a faster hashing algorithm. [1] https://stackoverflow.com/questions/11624372/best-practice-for-hashing-passwords-sha256-or-sha512 https://stackoverflow.com/questions/11624372/best-practice-f...
  • bostik 6y ago
    > Maybe the real problem is that the FIPS standards are too conservative? Quoting a professional cryptographer: FIPS compliance means that your code/system is sufficiently mediocre. Conservative would be one thing. Stubbornly out of date would be another.
    • jjav 6y ago
      > Conservative would be one thing. Stubbornly out of date would be another. Indeed. Also often impractical. A way to solve this is to support both a regular mode of operation and a FIPS mode of operation. I've worked on multiple enterprise products at different companies that take this approach. The full-on FIPS compliant mode is there to check all the boxes for customers who need that for their auditors. Even withing the set of those customers, a majority don't actually run the product in FIPS mode because it's too limited.
• tomohawk 6y ago
  These drones were compliant https://www.cryptogon.com/?p=12669 https://www.cryptogon.com/?p=12669 I can't find the link, but I recall that the video feeds were unencrypted because there was no approved encryption system for the use, so the contractor was not allowed to just use commercially available solutions and left the links unencrypted.
  • TimTheTinker 6y ago
    Sounds like “approved” might be synonymous with “NSA hackable.”
• rendall 6y ago
  While I don't approve, I suspect the auditors were in a difficult position: allow bcrypt, and if it blows up down the road, suffer consequences; or insist on that which will never get them in trouble, even if it is demonstrably inferior.
  • travisoneill1 6y ago
    "Nobody ever got fired for buying IBM."
    • spiritplumber 6y ago
      In 1998, I literally got fired for buying IBM (actual IBM) over Apple. I don't think that me telling people this in the last 20 years has done much to counter this particular meme.
      • gk1 6y ago
        That sounds like a good blog post!
      • rwallace 6y ago
        Sympathies! Now I'm curious, how did it happen? What equipment was it, that your employer preferred Apple over IBM, let alone had such a vehement preference as to actually fire you over it?
      • stjohnswarts 6y ago
        That really doesn't make any sense unless you were told to buy apple but said "hey these IBM laptops are cheaper and faster! I'll get them and they'll love how much I saved them."
      • rendall 6y ago
        I would love to hear this story too. Sounds very interesting!
• hansdieter1337 6y ago
  I can confirm this. We had to install virus scanners on our self-driving car Linux boxes which are disconnected from any networks... Fun part is that the AV scanner sometimes takes so much CPU time that the pedestrian detection algorithm fails and the car has an increased chances hitting them.
  • x86_64Ubuntu 6y ago
    This sounds strange because safety systems are usually hard realtime. I can't imagine those folks tolerating something that can randomly decide to eat time slices as it pleases.
  • chokeartist 6y ago
    Secure Boot may be of interest to you. If done correctly, there should be no additional run-time overhead (no AV process). AV to me is akin to shutting the barn door after the horse has bolted. Secure Boot prevents the horse from bolting in the first place, in theory.
  • everyone 6y ago
    not sure about this one. Viruses dont need a network or internet connection to spread. They used to spread just fine via floppy disks. EDIT: Obviously the fact that the cpu cant handle virus scan + pedestrian detection at the same time is shockingly bad. ... But a self driving car with a virus that could cause it to do potentially anything is even worse. Why not just run the scans when the car is not in motion, or when charging?
    • theandrewbailey 6y ago
      In another timeline: Auditor: This internet-connected device has no floppy drive. No antivirus needed.
  • ironmagma 6y ago
    That seems like a serious engineering ethics problem that needs to be escalated to the highest level possible and if that doesn’t work, then leaked to the media.
• Ozzie_osman 6y ago
  I know this is presented as a sort of ridiculous "government bureaucracy" story, but anecdotally, a non-trivial chunk of the security/compliance industry is built on compliance over security. Not all, of course, but enough that I think it's a big problem. I've literally had auditors ask me whether I'm actually interested in security or whether I just need the sign-off ("collect dust in a corner"). Not that this is unique to security. Similar things definitely happen with accounting or any industry where you pay the people who audit you (and probably even ones where you don't but the auditors still have an interest in not pissing you off, eg a government entity where officials may want to work for your company some day).
  • garciasn 6y ago
    I have worked with a large healthcare firm at two different agencies now who outsources compliance checks to overseas teams. There is nothing but a lengthy checklist to move through and if you do not meet the standards of the checklist, you fail. There is no critical thought or evaluation of each step; it’s a simple pass/fail. Example would be “are your drives encrypted at rest?” It doesn’t matter if you’re in a SOC3 facility, located 25 feet below street level in 8 foot thick concrete walls and your files are distributed in pieces across millions of drives throughout the data center. Nope. The drives must be encrypted at rest. Pass. Fail. Sigh.
    • edrobap 6y ago
      > SOC3 facility, located 25 feet below street level in 8 foot thick concrete walls One of objectives for encryption at rest is shredding. The drives may not remain in the secure facility after the end of life. > your files are distributed in pieces across millions of drives throughout the data center Distributing data could actually secure it if individual pieces are meaningless.
      • garciasn 6y ago
        Shredding happens on site but your point would stand otherwise.
    • 6y ago
• neurobashing 6y ago
  We had to delay rolling out one of the more recent Mac OS releases (Catalina, maybe) because it used the more secure “encrypt the data and throw away the key” instead of “write 0 to the sector 5 times” secure delete thing. Microsoft did research on how bad password rotation is, but it’s still the rule. Regs that can’t keep up with the pace of the thing they’re regulating are as bad as none at all, I think.
  • CyanLite4 6y ago
    NIST finally jumped on the “long passwords are stupid and password rotations are for suckers” bandwagon about 3 years ago. Problem is PCI, HIPAA and others haven’t changed their rules to accommodate. However, auditors aren’t stupid. I’ve told mine, “here, look at the new NIST standard” and they say “okay, yea MFA is better”. As long as you can point to their technology standards agency (NIST, FIPS, DISA, etc) you should be good to go.
    • whydoyoucare 6y ago
      This has been my experience too. Typically, standard bodies move at a different pace, and as long as you use a reputable known standard, you're good to go.
• tootie 6y ago
  I think it's more apt to say they lack the expertise to second guess the established best practices. There's also the question of indemnity. In case of a breach, they need to prove they followed established best practice in writing.
• scjody 6y ago
  The product I work on is geared towards big corporate IT environments, and I can confirm that this sort of thing is not unusual at all. A recent support ticket went along the lines of: Customer: An audit discovered that JDK version X was installed as part of your software. It has a vulnerability and we demand a way to upgrade to JDK X+1 that has the fix. Our support team: We're already aware of that and the latest point release of our software bundles JDK X+2, which fixes that vulnerability and 2 others. Please upgrade. Customer: Our compliance team requires JDK X+1. Please provide a way to install this version. We eventually solved the problem by having them upgrade to the latest major release of our software, which doesn't use Java at all, but it boggles my mind that they wanted a _less_ secure JDK.
  • noisy_boy 6y ago
    I doubt they cared as much about security as ticking the compliance checklist.
    • skrebbel 6y ago
      That was the point of the comment.
    • nicoburns 6y ago
      True, but competent company management / security professional would see version x+2 and go ahead and tick the x+1 item off the list.
      • OldHand2018 6y ago
        That’s not really the case. Version X+2 is not automatically better than Version X+1. It may have fixed known vulnerabilities a,b, and c but introduced vulnerabilities d, e, f, and g. How would anyone know?
        • whydoyoucare 6y ago
          Correct! And for the auditor, version X+2 has not been evaluated and certified, so they cannot really "approve" it. When one realizes the auditors are simply doing their job, and the end goal is more or less the same, the going gets much smoother. :-)
• seancoleman 6y ago
  Compliance is security, or said differently, non-compliance is a security vulnerability. In an isolated instance, it may seem obvious that bcrypt is superior to SHA-2 (it sure is to me). But managing security posture at scale, across a massive enterprise with disparate teams is tough. Rogue groups make bad security decisions all the time. Committees are formed, and policies are put into place to guard against this. Auditors are charged to enforce those policies. Changing policy itself presents risk (both organizational and personal/job-related risk). Therefore committees are conservative with adapting to evolving environments. This is the Occam's Razor explanation for why Things Just Don't Make Sense around many corporate IT security policies.
• whydoineedthis 6y ago
  Work for the govt, can confirm.
• cebert 6y ago
  I work in the Public Safety space where we are subject to a long list of CJIS guidelines. Some of the regulations, particularly like FIPS seem quite outdated and actually require systems to be less secure than they could be.
• deleted 6y ago
  [deleted]
• GartzenDeHaes 6y ago
  Here's a fun read for anyone interested in government compliance requirements. As a side note, many state government agencies also use this because they have your IRS tax returns. https://www.irs.gov/pub/irs-pdf/p1075.pdf https://www.irs.gov/pub/irs-pdf/p1075.pdf
• GordonS 6y ago
  I sell B2B security software, which is mainly used for compliance in a niche market. The software, of used correctly and integrated into processes, really can add a meaningful extra layer of security. However, lots of our customers just want to tick a compliance box that they can point assessors to. Kind of sad :(
  • Spivak 6y ago
    When you’re protecting someone else’s data you have no incentive to keep it secure beyond the minimum to cover your ass from regulators and lawsuits. It’s not so sad so much as maligned incentives. Data breaches are common, companies aren’t really punished for them, and the harm to the user is vague and doesn’t typically materialize in any visible way so they’re little outrage outside our bubble.
• ZiiS 6y ago
  Isn't the issue here that the FIPS equivalent of bcrypt is PBKDF2 which uses SHA512 like bcrypt uses Blowfish? (FIPS do not directly certify PBKDF2 only the underlying SHA512, but that is good enough for NIST).
• croes 6y ago
  Imagine you have no idea of cryptography and someone says to you: "We use foocrypt. It's fast, it's safe." How do you know?
  • deleted 6y ago
    [deleted]
• SirensOfTitan 6y ago
  The author doesn’t really try to identify from the regulator’s perspective, and it weakens their argument. To the state, one of the most important goals is legibility. The state has an enormous burden of regulation in its various enterprises, and the less variance the easier the job. This certainly isn’t ideal in many, many cases, but in this case a person who likely didn’t make the standards quite rationally trusts a vetted standard over one small trivial test given to them by a company they’re evaluating. FIPs standards are probably much more exhaustive than just a hashing performance test on one piece of hardware.
  • paultopia 6y ago
    ^^^^^^. This x1000. Yes, it's bad when bureaucracy means that individual bad decisions are made. But casually saying "oh, well, this is idiocy, the government doesn't care about security" ignores the fact that organizing the regulation of human behavior is immensely costly, and the government needs to optimize on those costs. A good dev analogy is using a library function vs rolling your own. The government's library is the list of things that its own engineers approved. The equivalent of rolling their own is for some individual auditor to make an independent decision to deviate from the list. Now, it might be that you can squeeze out an extra tiny bit of performance[/the government can squeeze out some extra security] by rolling your own sort function or whatever, but most wise devs will balance that off against the risk of introducing extra bugs, the extra writing and maintenance time involved, etc. Reality is that this sucks. It would be amazing if it wasn't actually super-super costly to organize human beings to all point in the same direction and make sure that people don't cheat. Government would be a lot cheaper and more efficient. But, alas, reality does suck.
    • richardwhiuk 6y ago
      Yeah - utterly agree. The point raised in the article is valid - but the correct thing to do isn't to persuade the auditor they are wrong, it's to push FIPS to include bcrypt instead of SHA2 (although as below, this isn't the right answer either - it should use PBKDF2 or similar).
• garritfra 6y ago
  There are always two sides to the coin. The auditors are just doing their job, telling you that the software you use is not compliant. What could have been done here is to demonstrate the safety of the algorithm to the organization behind FIPS, so that they can approve it.
• marcus_holmes 6y ago
  It's always difficult to assess these kinds of decisions without all the information, though. There might have been very good business reasons for this. Maybe to qualify for the insurance cover for intrusion, there was a specific list of algorithms that the insurance company said had to be used. Maybe it costs the insurance company so much to update its actuarial model for the policy that it's only worth doing every 10 years even if that means it's less secure. I'm not saying that this is true for this case. But it could be.
• beardedwizard 6y ago
  Many people need to fail, including the author, for such a situation to arise. The author failed to understand the mission of the business and how non-compliant technology posed a risk to it. The auditors failed to understand the developer, and educate them on the compromises needed to remain compliant. They also failed to engage in a discussion around alternatives. Everyone failed to actually care enough to solve this problem, but the author still found time for a snarky misinformed article. The vast majority of grating security/compliance tales come from a similar place of ignorance, apathy and snark. The people are the problem, and the misperception that they don't need to own these requirements for the business and are just in a hurry to check a box (on all sides).
  • cushychicken 6y ago
    The people are the problem, and the misperception that they don't need to own these requirements for the business and are just in a hurry to check a box (on all sides). Agreed. I think the framing of compliance in most companies helps reinforce this mindset. It comes from a place of compliance as "avoiding downside in the form of fines or gov't censure", not compliance as "a set of standards we abide by, that provides upsides to all of our customers by virtue of our following them".
  • ISL 6y ago
    Agreed. I generally encounter these kinds of complaints from safety-compliance perspectives. At the core is a lack of alignment and collective ownership of the necessary final outcome. My overriding impression has always been that at the high level, both safety inspectors and the people in the labs want the same thing: a safe working environment and the ability to get science done. There is always some tension there (scientists, especially young scientists, are sometimes willing to accept more risk to get science done, as it is their time, and hence lives, being gradually consumed by additional measures to improve safety), but there is general agreement that safe working conditions are a huge net benefit. It is difficult for the workers in the labs to place themselves in the shoes of the safety inspectors -- what seems like paperwork is actually a surface check to see if you are organized. If you can't explain your safety procedures to someone versed in scientific safety, how can you possibly explain them to an untrained worker/student? The one thing that can frustrate the entire process, which I suspect is at the root of most university troubles, is a lack of goal-alignment between departments within the organization. If safety inspectors don't feel ownership of getting quality science out the door and only want to reach internal safety targets and scientists are only interested in holding their small lab's accident rate to zero, rather than that of the much-larger university as a whole, nobody's goals will ever get met. When things are going right, inspections are a chance to show off how awesome your systems are and an opportunity to improve.
• djohnston 6y ago
  As an engineer I think all you can do is respectfully and publicly (within org) raise your concerns. If shit hits the fan 5 years later you have a life jacket and they are the ones looking like idiots.
• Ekaros 6y ago
  Compliance is important when you are selling stuff to customers. As they also often want compliance. So less secure, but compliant solution is sometimes needed from business perspective... Which I think is likely be better than just telling customers "trust us". Fault is really with standards moving too slowly, though this might not really be negative thing as sufficient time for researches to reach conclusions is also needed.
• CyanLite4 6y ago
  I empathize with the author, but definitely they are missing the Big Picture. Just because everyone’s using SolarWinds, does that make it safe to use? No. Now replace “SolarWinds” in that previous sentence with “bcrypt”. Author’s sole argument for security is that ‘everyone’s doing it’. Auditors also can’t just allow any Tom, Dick, or Harry to write their own cryptography hashing algorithm and call it secure.
• Havoc 6y ago
  >“They want us to be compliant, not secure.” No they just want to do their job & go home to their family. Arguing about every variance and merits of crypto with the counterparty is not their job, especially when there is central team - FIPS - specifically set up to centralize this and avoid the exact thing the authors team did: Every department freestyling it.
  • deleted 6y ago
    [deleted]
• catears 6y ago
  I tried looking up if there are any previous examples of FIPS 140 that allow bcrypt. I can find 37 matches when searching for "bcrypt" here: https://web.archive.org/web/20141226152243/http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm https://web.archive.org/web/20141226152243/http://csrc.nist.... . Seems that BitLocker in Windows used BCrypt at one point. Author doesn't mention how old this is, but BCrypt seems to have been approved for FIPS 140-2 compliance since 2008. If the event described was after 2008, I would not hire those same auditors again...
  • bladegash 6y ago
    There is a difference between FIPS validated and FIPS compliant. I may be mistaken, but from looking on CVMP, it does not appear that Bcrypt itself is FIPS validated algorithm. Edit: List of approved security functions for FIPS 140-2 can be found here: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf#page4 https://csrc.nist.gov/csrc/media/publications/fips/140/2/fin...
• cstuder 6y ago
  Cryptographic question: Why don't you just SHA-2-hash the Bcrypt hashes? hash = sha2(bcrypt(plaintext))
  • ccouzens 6y ago
    bcrypt(plaintext) != bcrypt(plaintext) The output of the function includes a random salt. The verify function looks like verify(plaintext, hash) This is why the bcrypt cyphertext needs to be stored
  • onei 6y ago
    You could use hash the password with sha2 and then with bcrypt, but not the other way around. Hashing with sha2 will give you the same result every time. That's why it's appropriate to use as a checksumming algorithm - the results are repeatable. Bcrypt on the other hand does not generate the same result every time by design due to it using a randomly generated salt. However, if you did hash with sha2 the first time, you may end up regretting that decision if sha2 collisions end up being possible and/or practical.
  • daneel_w 6y ago
    That would not be possible, but one could use bcrypt to generate a salt to use with SHA2 as the last step.
• zenexer 6y ago
  The author’s assertions are misleading at best, outright false at worst. Their testing is inherently flawed, and they’re misinterpreting the output from hashcat. Although their choice of bcrypt is a good one, they clearly don’t understand how to actually evaluate different algorithms, and I commend the auditor for not allowing them to do so. The author’s process doesn’t prove that bcrypt is more secure than whatever SHA2-based alternative was being proposed (from the example, seemingly sha512crypt). It simply proves that the number of rounds they chose for sha512crypt didn’t match the timing factor they chose for bcrypt. That’s just dumb. I could just as easily provide a counter-example by stacking the odds in my favor. The time it takes to brute force a bcrypt or sha512crypt hash is configurable when generating the hash; I could just as easily choose options that appear to support sha512crypt being more secure. What matters here is that the company wanted to use an algorithm that wasn’t requested by their customer. Their customer had a detailed document explaining which algorithms they would prefer. Although bcrypt is generally considered top notch security, vulnerabilities have certainly be found in various implementations over time.[0] This company’s customer—the US government—wanted something they had personally vetted and approved, which is understandable. Even if you could prove that one algorithm is slower than another, that doesn’t necessarily mean it’s more secure; it’s just more resistant to brute force attacks. Furthermore, the author says “SHA2-based” without elaborating, causing several HN commenters to assume raw SHA2 was used here. However, the author’s hashcat example shows sha512crypt. That means it’s not raw SHA2; it’s been adapted to be made proper for password hashing, including salting and multiple rounds. It’s the same as calling bcrypt “Blowfish-based:” yes, it’s true, but it’s somewhat misleading if you completely omit any mention of bcrypt. Raw Blowfish should never be used for password storage; it isn’t designed for that, much like SHA2. [0]: https://en.wikipedia.org/wiki/Bcrypt#Versioning_history https://en.wikipedia.org/wiki/Bcrypt#Versioning_history
• throwaway2245 6y ago
  In a well-functioning system, the auditors ensure the agreed security policy is implemented; they shouldn't have any power over what the policy says. As such, the author cannot (should not be able to!) change the policy by appealing to the auditors. Explaining why you are non-compliant to the auditors is a wasted effort: you are talking to the wrong people.
• dragonwriter 6y ago
  Yes, software often has requirements from the people paying the bills, and when those people are from large bureaucracy, requirements are often shaped by bureaucratic rules that move much slower than understanding of the subject area. It's even more fun when there is a chain of those involved, because then you can get bureaucratic rules that move slower than the external bureaucratic rules which they are serving, which in turn move slower than knowledge of the subject domain.
• tromp 6y ago
  Couldn't you have satisfied the auditor's need for compliance as well as your own sense of security by simply composing SHA2 with bcrypt? Hash(password) = SHA2(bcrypt(SHA2(password))) A SHA-2 based hash with similar performance as bcrypt...
  • deleted 6y ago
    [deleted]
• henvic 6y ago
  * Someone had access to a delivery system that could be used to attack thousands of people's machines by rolling out a rogue release. * This someone was forced to install a specific antivirus due to compliance with an industry certification. This antivirus called home, and was from an obscure vendor. This someone wasn't able to change any of this, and also didn't have power to choose another vendor. If you followed the rules by the book, you couldn't even introduce a third machine to authenticate things without this silly protection. So, what should did they do? Installed the antivirus on a virtual machine with no access to the host computer, and program it to be fired up for a couple of minutes a day, just to keep the stupid antivirus happy by calling home.
• cratermoon 6y ago
  Well, this article at least explains why Microsoft is touting their "highly secure" salted SHA password hashing for Azure and not using bcrypt, PBKDF2, or Argon2. They must be aiming for FIPS compliance.
• jariel 6y ago
  a) Consistency and standards are important b) I'm not sure if such a test really proved anything. Crypto is hard, we don't like to do experiments, it may take time for larger orgs to accept new crypto. c) The standard algs were almost assuredly 'good enough' for the job. By introducing new tech, you introduce risk, fragmentation etc.. In the bigger picture, the regulators were probably correct. They were keeping the system pragmatically 'more secure' even if not so much on a theoretical basis. There are examples of bad bureaucracy, this isn't one of them I think.
• ilaksh 6y ago
  It makes me suspect that the government standard was deliberately insecure to make a more "thorough audit" easier.
• throwaway316943 6y ago
  Box tickers are the bane of a free and competent society.
• hannob 6y ago
  People without a cryptographic background may not be aware that this is even worse than how it sounds. SHA-256 is a cryptographic hash function. It's a good cryptographic hash function. But it's not a password hash function. They have different goals. Particularly a cryptographic hash is trying to be fast, while a password hash is trying to be slow. You can use a cryptographic hash function as a password hash, it's better than nothing. But it's a really poor choice. If this story happened as it's told, it not only means that compliance is making wrong decisions, it also means the auditor didn't know what he was talking about. There are FIPS-approved password hashes, even ones building upon SHA256 (PBKDF2-SHA2-256). It would've been less bad to propose to move from bcrypt to such a function. (Still not really justified, as bcrypt is a fine password hash function.)
• eximius 6y ago
  So roll your eyes and use PBKDF2 with SHA2. Regulators have a job and auditors are not intended to evaluate everyone's hand-rolled crypto (obviously a bit if an exaggeration calling bcrypt hand-rolled...).
• jancsika 6y ago
  > “They want us to be compliant, not secure.” Suppose the auditor looked at the output from the author's single test and said, "Oh, ok, you're good to go." In this version of history, perhaps the author's organization saw a moderate benefit from the more resilient crypto. However, the set of all organization audited would be significantly less secure because the audit becomes nearly meaningless.
• kennydude 6y ago
  I think some of this is things with good intentions. For example to prevent someone trying to blab it's secure, when it's really not https://www.troyhunt.com/lessons-in-website-security-anti/ https://www.troyhunt.com/lessons-in-website-security-anti/
• deleted 6y ago
  [deleted]
• amingilani 6y ago
  I'm curious: If the regulators required SHA-2 hashes, and the author desired blowfish, why couldn't they implement blowfish+SHA-2? I.e. sha2(cost(blowfish(password, salt), cost_factor))
• artellectual 6y ago
  I’m facing this challenge right now with a regulator. We have a financial system, that uses managed cloud SQL hosted in one of the regions. The database is also in high availability mode and has daily backup scattered all over the various regions. All this is being managed by the cloud provider we are using. One of the regulator has asked us to maintain a “local backup” of the database. When I asked what the reason is they just said “we require it”. Since creating another copy of the database outside the managed environment increases risk I told them “based on my assessment we are deliberately increasing risk of a vulnerability, it’s my job to report and you to sign that you have acknowledged the increase in risk based on assessment”.... No response from the regulator that this is now required. I can relate to what these guys are going through mostly I find regulators just read an old book and since they are usually regulators not engineers they use the rule book to make engineering decisions. While regulators have to follow a book and its their job its also important for them to understand that every system is different and that they are not experts, and that the book they follow are not always up-to-date. Sometimes the regulators job is also to say “let me check on that” and find another expert or better yet consult with the person who wrote the book to “update” and improve on the “standard” to ensure that the highest standard is being propagated to all the parties they manage.
  • nalekberov 6y ago
    Without local backup you cannot be sure of integrity of the data. In that sense the regulator is right. I would even question why the data is stored in cloud?
    • artellectual 6y ago
      Lol you obviously didn’t read my comment. We have backups... scattered all through out the multiple regions. They just want it on “local soil”. As in it should not be in another country. > why is it in the cloud? Because we’re allowed to use cloud.
      • nalekberov 6y ago
        nevertheless you cannot completely trust public cloud provider when it comes to data integrity.
• nalekberov 6y ago
  OP is biased, in a sense that there is no such thing as “X is better than Y, because test proves that”. And it’s not regulator’s responsibility to decide whether X better than Y, there are rules, list of approved algorithms and whatnot. It’s that simple. If one can violate the rules, virtually everyone can violate the rules. Whether X is better than Y that thing can be debated of course.
  • WarOnPrivacy 6y ago
    This seems to blow past the issue where rules are creating the precise problem (increased vulnerability), that they were expected to minimize.
    • nalekberov 6y ago
      Then the right action would be to fight for including bcrypt in the approved algorithms list.
      • WarOnPrivacy 6y ago
        > right action If a fight is required, 'energy-draining', 'needless' or 'counterproductive' would be more appropriate adjectives than 'right'.
• AtlasBarfed 6y ago
  Security people come from auditing and government backgrounds. They aren't about providing solutions or even keeping up with cracked algorithms, exploits, and hacking techniques. They are almost solely about establishing a policy and enforcing it. In large IT organizations, security managers keep their jobs by doing things that upper management understands: policies and enforcement. In reality what will help things are providing reference implementations of things like login flows, secured operating systems, secured web browsers, etc. In the age of AMI and docker images, providing key building blocks for secured systems would go a lot longer than a lot of the insanity I've seen over the years.