> As in every job, you will sometimes have incompetent people in your environment. Working with them is very frustrating. They waste so much time and create a toxic environment. On top of that, they are extremely unproductive.
That is not even the worst case. There are incompetent people out there that look like they are productive.
An example: once we had to implement a bridge to an API to some piece of software from some third party vendor that one of our customers used. This started with authentication. Of course they didn't use OAuth or anything like it but their homegrown bastardised version: you authenticate with a username + password - nope, not a refresh token - and it hands you a temporary token that you then use to hit the API until it expires.
Of course it didn't hand you expiration time so you'd have to do requests until they failed, at which point you did the login dance to get a new temporary token.
Of course it didn't fail with a 403 or any other status code or in-band information you could use: everything failed with a 500 and an empty body. But that's not even the worst part.
Of course there was no HTTPS, so everything went in clear over the interwebs. Not to fret, they thought of that: they implemented encryption. Oh, before you ask no they did not use a Authentication header or anything remotely like it, for the login phase they had us pass username+password on a GET request query string, with values encrypted.
Of course they did not use anything cryptographically reasonable that you could find off the shelf, instead choosing to shoot themselves in the foot with using the OpenSSL API to come up with their own thing. So they picked the worst possible thing ever, ECB - If you have no idea how bad ECB is, click the following link and let it sink for a moment that you're looking at the ciphertext.
Of course they provided documentation with three code examples (C#, Java, PHP) so as to implement it. Of course each one of these four had gaps covered by the others, yet the overlaps had none of these four things agreeing.
Of course the code for the statically typed languages did not even pass the compiler.
Of course the code examples were ostensibly copy pasted from StackOverflow, and then further butchered (with localised names).
Of course the actual server implementation was a fifth thing that disagreed with the four above. So the easiest way was to "simply" MITM their official Flash client and brute-force-reverse-engineer the payloads, tuning OpenSSL arguments until your code produced the same output as what you intercepted. In a twist of irony, this being ECB helped.
And no they did not use anything like public+private keys, DH, or even a PSK, however fancily implemented. See, values were encrypted for every payload, but how do you make the API server understand your first request ever: the login? Of course you would not send the username and password in the clear over the web! So it has to be encrypted! So you encrypt it and stuff it as a value in the query string! But now how does the server which has no idea what the key is can decrypt it? Easy! Base64 the key and pass it as a second query parameter! Now auth is encrypted and the server can decrypt it! To hell with "PS" in "PSK", that's for losers!
Of course, somewhere, someone got accolades for having implemented that API in record time complete with full documentation and examples, ready for folks like us to peruse.
Of course we had to vigorously defend ourselves for being comparatively unproductive in front of two CEOs (including ours), a CTO, a contractor, and an employee that implementing a client to this API is taking us more than an afternoon, and that, glossing over the details about the fitness of ECB, it was a stupendously pointless loss of everyone's time when the API vendor required us to pass the key in cleartext alongside the encrypted payload, a fact that probably still eludes all of them to this day.
That is not even the worst case. There are incompetent people out there that look like they are productive.
An example: once we had to implement a bridge to an API to some piece of software from some third party vendor that one of our customers used. This started with authentication. Of course they didn't use OAuth or anything like it but their homegrown bastardised version: you authenticate with a username + password - nope, not a refresh token - and it hands you a temporary token that you then use to hit the API until it expires.
Of course it didn't hand you expiration time so you'd have to do requests until they failed, at which point you did the login dance to get a new temporary token.
Of course it didn't fail with a 403 or any other status code or in-band information you could use: everything failed with a 500 and an empty body. But that's not even the worst part.
Of course there was no HTTPS, so everything went in clear over the interwebs. Not to fret, they thought of that: they implemented encryption. Oh, before you ask no they did not use a Authentication header or anything remotely like it, for the login phase they had us pass username+password on a GET request query string, with values encrypted.
Of course they did not use anything cryptographically reasonable that you could find off the shelf, instead choosing to shoot themselves in the foot with using the OpenSSL API to come up with their own thing. So they picked the worst possible thing ever, ECB - If you have no idea how bad ECB is, click the following link and let it sink for a moment that you're looking at the ciphertext.
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
Of course they provided documentation with three code examples (C#, Java, PHP) so as to implement it. Of course each one of these four had gaps covered by the others, yet the overlaps had none of these four things agreeing.
Of course the code for the statically typed languages did not even pass the compiler.
Of course the code examples were ostensibly copy pasted from StackOverflow, and then further butchered (with localised names).
Of course the actual server implementation was a fifth thing that disagreed with the four above. So the easiest way was to "simply" MITM their official Flash client and brute-force-reverse-engineer the payloads, tuning OpenSSL arguments until your code produced the same output as what you intercepted. In a twist of irony, this being ECB helped.
And no they did not use anything like public+private keys, DH, or even a PSK, however fancily implemented. See, values were encrypted for every payload, but how do you make the API server understand your first request ever: the login? Of course you would not send the username and password in the clear over the web! So it has to be encrypted! So you encrypt it and stuff it as a value in the query string! But now how does the server which has no idea what the key is can decrypt it? Easy! Base64 the key and pass it as a second query parameter! Now auth is encrypted and the server can decrypt it! To hell with "PS" in "PSK", that's for losers!
Of course, somewhere, someone got accolades for having implemented that API in record time complete with full documentation and examples, ready for folks like us to peruse.
Of course we had to vigorously defend ourselves for being comparatively unproductive in front of two CEOs (including ours), a CTO, a contractor, and an employee that implementing a client to this API is taking us more than an afternoon, and that, glossing over the details about the fitness of ECB, it was a stupendously pointless loss of everyone's time when the API vendor required us to pass the key in cleartext alongside the encrypted payload, a fact that probably still eludes all of them to this day.