One could always reason about things. But to promise to investigate (and then deliver) looks (and is) professional.
But I will never say yes when a customer suggests to "encrypt dsta using the cipher md5". Yes it has happened. More than once.
One could always reason about things. But to promise to investigate (and then deliver) looks (and is) professional.
But I will never say yes when a customer suggests to "encrypt dsta using the cipher md5". Yes it has happened. More than once.
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."
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 :-)
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.
Good thread: http://crypto.stackexchange.com/questions/48/is-it-feasible-...
Don't assume your client is an idiot.
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.
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.
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.
There's a sentiment that, if you hire an expert, you should do what they tell you to do - why hire them in the first place if you don't trust them - and that's valid in some ways. Still, if an expert can't communicate to their clients why they think an approach is good or bad, it seems to me something's very wrong with the process.
Totally, but there are good and bad responses. I usually go with something like, "It seems we're not capturing or making some important information available, so can you describe the core problem that your suggestion solves so we can better understand how to implement it?" Usually a better solution arises from the ensuing back and forth.
Everyone solves problems by drawing on their domain of knowledge, and customers' knowledge is simply more limited than a software developers' when it comes to computing. The software developers' domain knowledge is much more limited when it comes to the customers' business though, so some humility on both sides is warranted.