Our business-critical internal software suite was written in Pascal as a temporary solution and has been unmaintained for almost 20 years. It transmits cleartext usernames and passwords as the URI components of GET requests. They also use a single decade-old Excel file to store vital statistics. A key part of the workflow involves an Excel file with a macro that processes an HTML document from the clipboard.
I offered them a better solution, which was rejected because the downtime and the minimal training would be more costly than working around the current issues.
The library I worked for as a teen used to process off-site reservations by writing them to a text file, which was automatically e-faxed to all locations every odd day.
If you worked at not-the-main-location, you couldn’t do an off-site reservation, so on even days, you would print your list and fax it to the main site, who would re-enter it into the system.
This was 2005. And yes, it broke every month with an odd number of days.
I feel your pain. Many good ideas that cause this are rejected. I have had ideas requiring one big downtime chunk rejected even though it reduces short but constant downtimes and mathematically the fix will pay for itself in a month easily.
Then the minimal retraining is frustrating when work environments and coworkers still pretend computers are some crazy device they’ve never seen before.
cleartext usernames and passwords as the URI components of GET requests
I’m not an infrastructure person. If the receiving web server doesn’t log the URI, and supposing the communication is encrypted with TLS, which removes the credentials from the URI, are there security concerns?
What do you mean by any involved network infrastructure? The URI is encrypted by TLS, you would only see the host address/domain unless you had access to it after decryption on the server.
Even if the destination doesn’t log GET components, there could be corporate proxies that MITM that might log the URL. Corporate proxies usually present an internally trusted certificate to the client.
As weird as it may seem, this might be a good argument in favor of Pascal. I despised learning it at uni, as it seems worthless, but is seems that it can still handle business-critical software for 20 years.
Our business-critical internal software suite was written in Pascal as a temporary solution and has been unmaintained for almost 20 years. It transmits cleartext usernames and passwords as the URI components of GET requests. They also use a single decade-old Excel file to store vital statistics. A key part of the workflow involves an Excel file with a macro that processes an HTML document from the clipboard.
I offered them a better solution, which was rejected because the downtime and the minimal training would be more costly than working around the current issues.
The library I worked for as a teen used to process off-site reservations by writing them to a text file, which was automatically e-faxed to all locations every odd day.
If you worked at not-the-main-location, you couldn’t do an off-site reservation, so on even days, you would print your list and fax it to the main site, who would re-enter it into the system.
This was 2005. And yes, it broke every month with an odd number of days.
I feel your pain. Many good ideas that cause this are rejected. I have had ideas requiring one big downtime chunk rejected even though it reduces short but constant downtimes and mathematically the fix will pay for itself in a month easily.
Then the minimal retraining is frustrating when work environments and coworkers still pretend computers are some crazy device they’ve never seen before.
I’m not an infrastructure person. If the receiving web server doesn’t log the URI, and supposing the communication is encrypted with TLS, which removes the credentials from the URI, are there security concerns?
Anyone who has access to any involved network infrastructure can trace the cleartext communication and extract the credentials.
What do you mean by any involved network infrastructure? The URI is encrypted by TLS, you would only see the host address/domain unless you had access to it after decryption on the server.
Browser history
Even if the destination doesn’t log GET components, there could be corporate proxies that MITM that might log the URL. Corporate proxies usually present an internally trusted certificate to the client.
As weird as it may seem, this might be a good argument in favor of Pascal. I despised learning it at uni, as it seems worthless, but is seems that it can still handle business-critical software for 20 years.