Consultant: "I will investigate the feasibility of this."
... two days pass ...
Consultant: "I have considered your proposal. I believe we should encrypt your data with SHA-256. md5 is insecure, here's several references. SHA-256 is much more secure and more popular. It is a NIST standard, and just as cheap."
Client: (probably) "OK, if it costs the same and is more secure, sounds good to us."
Ignoring the encryption/hashing problem, what happens if your client is moderately technical and also researches the problem, and finds the same answer in 5 minutes? You look like you're incredibly slow (or over-billing) if it takes you two days to come back.
I think that, often, there's confusion between someone's position and their interest.[0] It's easy to think that if they asked for "MD5", they must want "MD5", right?..
An easy illustration of this is someone with a runny nose asking you for a "Kleenex". You have tissues of another brand, so you tell them you don't have a Kleenex. This is being an asshole who hasn't done any Physics but watches too much Big Bang Theory and wants to be "like logical/analytic". That kind of stuff is only cool when Paul Dirac does it, whom the asshole knows nothing of. Of course we laugh because "nobody" would act like that..
"MD5" is "Kleenex". The runny nose is their concern for security. "Tissue" is "something to clean that runny nose.. or shine their shoes". They might want the tissue to do something else than clean their nose, because they have a handkerchief for that.. So our assumption they want to use it to clear their nose is wrong.
If their only options are "no password-hashing" and "that crypto thingy, what was it? DM5, MD5 or something?", choosing MD5 is actually a sane decision and request.
The underlying interest here is "security", communicated with a request for "MD5" (position) which makes them seem clueless to someone with a broader view and who must, in my opinion, recognize their request for what it is.
One could ask for the specific reason they chose MD5 and not something else? They may be unaware of other options, or give constraints they were trying to satisfy with that choice.
Someone who says the site must be in PHP might mean they want a "dynamic site". Someone who specifies "Bootstrap" might mean "responsive", etc.
We clear assumptions by asking questions, and noses by blowing them.
Exactly. To me a senior consultant should be able to spot the obvious error and then focus on trying to understand what the customer need and move the solution to something that meets the intent.
If it is confidentiality the customer need, provide good solutions to that. But check if confidentiality is really the thing needed. Quite probably, authentication and integrity protection is what is really needed. So AES in CTR mode might not be what the customer should want instead of MD5, but possibly AES-GCM, AES-CMAC or even a Ed25519 signature mechanism using public key.
Actually you can use a cryptographic hash function such as SHA-256 (or MD5, but lets not go there) as the core of a stream cipher. Basically stick a seed (key) combined with a counter as input to the hash functiom. Use the output as the keystream. Stream ciphers such as ChaCha are basically block based PRFs that operates like this.
Of course the performance would be silly compared to dedicated functions. ChaCha20 has less than a third the number of iterations compared to SHA-256. And each iteration is much faster.
I once saw that particular confusion in a security audit report that a company was using as part of their sales materials.
I did flag it up as indicating that there might be something a bit fishy about the security audit if they made such an elementary error but I suspect the CEO (multi billion pound company) had already made the decision so what I thought was irrelevant :-)
This might be "fix my plumbing with a wrench", you can't, you also need a replacement pipe, but that wan't what was meant, more like "utilise a wrench in the fixing of my plumbing"...
In the events that this have happened I have directly, as diplomatically as I can be, explained that (1) MD5 is not a cipher, but a hash function that does not provide confidentiality. And (2) It is not a hash function one should use . Ever. Never. In a million years. Or more.
And at this stage start to enquire what security the customer think their system/product/service needs and try to move forward from that point. And we usually also talk about MD5 and its brokenness. Than if a secure hash function is needed, there are several good ones to choose from. And if they really don't need a secure hash function, there are others, much faster hash functions to use.
The point is that sometimes things need to be handled directly and up front. This for me is one of those things.
Client: "Encrypt our data using the md5 cipher."
Consultant: "I will investigate the feasibility of this."
... two days pass ...
Consultant: "I have considered your proposal. I believe we should encrypt your data with SHA-256. md5 is insecure, here's several references. SHA-256 is much more secure and more popular. It is a NIST standard, and just as cheap."
Client: (probably) "OK, if it costs the same and is more secure, sounds good to us."