Coder wrote a bug so bad security guards wanted a word when he arrived at work

I worked for a large retailer on their iPhone app and our test environments were terribly slow so we tended to do most of our development against production.

This retailer is pretty old and had issued their own credit cards that didn't have any sort of checksum validation. This made making test orders easy because any sequence of numbers for that credit card type would let the "checkout" call succeed, and then the order wouldn't actually be fulfilled because the card would turn out to be invalid.

We usually used a sequential list of numbers because that was so fast to type and we used a made up Address in Tok Alaska. The state picker had Alaska first and Tok (also Eek) were the shortest city names we could find in Alaska.

One day someone took a look at one of our test account's order histories and noticed that there was a tracking link for the order. That "fake" credit card number turned out to be quite real. We shipped a dress to Alaska, which was then returned to sender because the address (1 A St) didn't exist.

We were much more careful after that but as far as I know, nobody ever complained and we never heard about it from anyone outside our team.

Several payments and financial posts within as money mistakes often leave impacting memories for those involved.

As a dotcom kid who founded and wrote the core systems for several payment processing companies over the decades I recall 2005 when a company using one of our partner banks was breached. This was CardSystems, the largest publicly known breach at the time, and I was tasked to perform a full code review of their systems to find any issues. The payments gateway contained a valid crc nontest card number compiled into authorization logic that had no deployment switching control and recorded no transaction information when that card number was used. Any merchant using CardSystems under this payment gateway suffered unknown losses from approved transactions that were never recorded into any system. I postulated who had done this but federal law enforcement around the breach buried this and other key discoveries I had found since the company was being dissolved and my findings were therefore deemed immaterial.

In the early wild-west days of ecommerce a friend working as a tester at a well known British supermarket discovered that the backend card-validation logic on their payment form was essentially "return true" ... good thing the volumes were miniscule I guess?

Are all these articles this "lightweight" and short on details and sound like a made up coding morality tale?

Just the style here throws me.

This reads a bit like an article from "the daily wtf", I used to frequent that one often [0].

[0] https://thedailywtf.com/

Working at a fortune 500 way back in 2011, I was assigned a ticket which was about asynchronously rotating an ad block at the top of a public search page on an extremely busy site.

There was a tiny bit of logic in there if I remember correctly, relating to when and whom to show the ad to.

I implemented it, tested in dev, assigned it to QA, QA approved it and rolled it out that afternoon.

The next morning when I showed up to work one of the other team leads walked straight up to me as I entered the campus, laughing hysterically.

Turned out that in production it behaved differently. The ad appeared, correctly. Then doubled every couple of seconds,1 ad, 2 ads, 4 ads and so on, until the client browser exploded into flames.

As luck would have it there was zero consequence, only chuckles all over the place. It was something to do with order of inclusion of a mad number of js libraries which differed in production and went unnoticed. The End.

I wrote industrial control software that bumped a very expensive piece of equipment against the wall because I miscalculated the encoder position. Since then, special limit switches were added, colloquially known as anti-EVa5I7bHFq9mnYK switches.

Long story short, as a junior programmer I did not fully appreciate the difference between credit and debit and ended up putting a bunch of money on customer credit cards instead of deducting it. And yes the app somehow passed our payment processor's validation exercises. Total damage was maybe $10k, but I think we managed to roll most of it back.

This read to me as if someone asked a LLM to create a facebook urban legend about a bad programmer and prompted it with a couple bullet points.

If it contained the words “you’ll never believe what happened next…” they would be completely at-home.

>Regomize is a made-up word that combines "The Register" and "Anonymize." We coined the term to reflect our practice of inventing names for contributors to On Call and its sibling column Who, Me?. We offer this explanation as in recent weeks we've had readers suggest the word is a spelling error.

Stories like this are why I'm happy that the company is understanding that OPs, stability and control vs Dev, Fast changes and Agility aren't binary, polar opposites, but more of a throttle.

Like, for a lot of state free application logic, or even read-only frontend stuff, just do. A roll-back or a roll-forward is easier than heavy-weight procedure.

But if payment, customer authentication, migrations of large databases comes in... Suddenly these ops-guys with their careful rollout, validation functionality, dry-runs and ring rollouts are pretty good at keeping the day boring.

This belongs to the class of bugs/"features" that one could refer to as "Superman 3" issues.

Reminds me of a similar bug in a payment processing system the company I worked for used. Long story short, overflow in Java numerical types (counting milliseconds for durations in weeks...) caused the system to go haywire and charge customers 1000x the normal amount...

It turned out very profitable for the company though. Stonewalling customers and refusing charge backs is too easy. Not picking up the phone is a good business strategy.

A couple of years ago, I lived in an apartment and made a doorbell repurposed from an Amazon Dash button. Basically I have a daemon that sends a message each time a button press is detected to my homebrew mqtt server.

Then I have a bash script that runs on the raspberry pi board that has a speaker installed, something of this sort to play the doorbell chime:

  while [ true ]; do
    mosquitto_sub --exit-after-first-message /my-topic
    play_wav my-file.wav
  done

One day, when I was out and about, I got a call from my neighbor saying the doorbell was making noise non-stop and bothering him. Turns out the mqtt server crashed, the mosquitto_sub command exits right away... We had a good laugh about it as we are both software engineers.

This reminds me of the bug in the stealing script in Office Space. The script was supposed to steal fractions of a cent, but, instead, it was stealing dollars.

In the end, it turned out OK. The joint burned down, and Milton ended up on a beach, sans Swingline.

It's unstated but are we to understand that he set up the test to send money to a test account which was his own personal account?

I wrote a faxing queue because our fax server at the time was horrible at converting pdf's to fax appropriate tiff's. I didn't think to block an area code that was 911. The cops showed up when a user accidentally fat fingered 911 as an area code.

I always liked this clause from the Underhanded C Contest:

"The Underhanded C Contest was a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake even if discovered."

Office Space just keeps replaying in my head. All he needed was a timely fire to get away with it.

Ship fast they say, but do not ship that much faster.

What’s that boast again,

“move fast and break things” …