Comment On Encapsulation in the Hot Seat

Now that is some Enterprise-ready code.

What kind of auditor is this? Most auditors I've encountered just say things like "your passwords aren't being changed every 30 days."

If you ask "why 30 days and not 90?" they reply "because that's what it says on my checklist here."

Wow, Some intern, and some auditor!

To make matters worse, the after effects of the two coffees from earlier this morning had just hit his lower regions.

This is called a setup with no payoff.

Perhaps we should do like yesterday and write our own story endings.



Santosh figured he could endure one more question before he simply had to go. Go, as in leave the room. Or, as in, well, go.

The auditor seemed to be a mind reader...

Have you considered what will happen under high pressure situations?

Some transactions are so urgent they can't wait for delays like this, wouldn't you agree?

What is your defense against overflow conditions?

You seem to understand setters and getters, but do you have any experience with wetters?

So the real WTF is not going to the lavatory immediately before the code review? That's Meeting 101.

It reminds me of a novel I read some time ago (can't remember what, might have been Michael Moorcock) where it was pointed out that the protagonist was fairly desperate to void his bladder. And that was the last time the matter was mentioned. For the whole of the rest of the book your legs were crossed for the poor guy.

Rick:

To make matters worse, the after effects of the two coffees from earlier this morning had just hit his lower regions.

This is called a setup with no payoff.

Perhaps we should do like yesterday and write our own story endings.



Santosh figured he could endure one more question before he simply had to go. Go, as in leave the room. Or, as in, well, go.

The auditor seemed to be a mind reader...

Have you considered what will happen under high pressure situations?

Some transactions are so urgent they can't wait for delays like this, wouldn't you agree?

What is your defense against overflow conditions?

You seem to understand setters and getters, but do you have any experience with wetters?

Santosh casually replied, "Mind if we take a comfort break?"

Andy:

What kind of auditor is this? Most auditors I've encountered just say things like "your passwords aren't being changed every 30 days."

If you ask "why 30 days and not 90?" they reply "because that's what it says on my checklist here."

Auditors like this drove the final nail in any chance of remembering your password. Thanks to them, I haven't known any of my passwords in 5 years, except the passwords I need to get to my password vault.

Talk about a high-risk target! And it didn't exist, until the auditors forced it on me.

The real WTF is that this actually seemed to work...
And the unexpected twist is that the auditor wasn't a WTF. Totally caught me by surprise.

[edit: are there any other cases at all where someone posts their own WTFs?]

First rule of audit inspection is let auditor find thing for herself. Don't dig yourself in hole or put axe on your own foot.

TRTWF is the SQL injection.

Suddenly the president's sick daughter walked in.

"But we thought you died!" exclaimed the Auditor.

"I did" she replied.

Suddenly there was piss everwhere.

QJo:

So the real WTF is not going to the lavatory immediately before the code review? That's Meeting 101.

Correct as great swami always say - He who can hold bladder for longest time will win argument. That is why women win most arguments.

And fun fact: there's never actually been a study done to see if frequent password changes actually improve security. And there's no reason to think it would- at best, you're revoking an already compromised password. But on a 90 day password cycle, that means you have an average of 45 days of unfettered access. On a 30-day password cycle, it's an average of 15.

And what's the average amount of time an attacker needs to exploit a compromised password? I'm sure it varies, but I can guarantee that the number isn't measured in days.

It's cargo-cult logic.

requestQueue.take() is non-blocking and will not wait for something to be in the queue. It seems it will fail as soon as there are no requests waiting. Since it catches and logs the exception and continues in the while(true) loop, this function will run at 100%, working at logging as many errors as possible, until there is a new request to handle.

Andy:

What kind of auditor is this? Most auditors I've encountered just say things like "your passwords aren't being changed every 30 days."

If you ask "why 30 days and not 90?" they reply "because that's what it says on my checklist here."

There is one PWC company in India that come and run script against your database so auditor don't want to have to ask useless question like that one.

Except requestQueue.take() IS blocking, just as it says in the article. So what I described was only hypthetically true, also known as false.

mmmok:

Suddenly the president's sick daughter walked in.

"But we thought you died!" exclaimed the Auditor.

"I did" she replied.

Suddenly there was piss everwhere.

I will await the continuation of this story tomorrow when we add the next setup that wasn't concluded.

seriously, if no one else does it tomorrow, I'll do it myself.

So we conclude that TRWTF is the object-oriented programming terminology of SmallTalk (or maybe SmallTalk itself, not sure).

In ST, you see, the terminology is that one object sends a (named) message to another, possibly with parameters, and the other handles the message by dispatching the parameters to a matching-named method.

Other languages, like C++, say, dispense with all that and merely invoke the method directly (or via a hidden method pointer in the case of overrideable methods called against pointers or references).

This last brings me to an interesting and slightly non-obvious question: in what circumstances are virtual methods of C++ objects called directly without passing via the dispatch process?

Answers on a postcard...

Andy:

What kind of auditor is this?

I was the auditor. Santosh is on my team and sits nearby. Nobody likes this guy, mostly because he talks the talk, but codes like this (actual, unaltered code presented). I was doing a routine code review, stumbled upon his latest creation and showed it to our boss who insisted on the public code review, in front of the whole team!

Nagesh:

First rule of audit inspection is let auditor find thing for herself. Don't dig yourself in hole or put axe on your own foot.

+1
Frankly, after Santosh confession, I was expecting the auditor to say something like "Wow. I was about to point that the text formatting on your code was not using the correct indentation, but I will [happily] add this to the report [to show your bosses that I am a friggin' genious]. Be sure to fix this and the text indentation before next review [and don't expect a raise this year, BWAHAHA!]."

Captcha: ideo, as in "don't give away any ideo before knowing what's happening".

georgir:

The real WTF is that this actually seemed to work...
And the unexpected twist is that the auditor wasn't a WTF. Totally caught me by surprise.

[edit: are there any other cases at all where someone posts their own WTFs?]

He didn't post his own WTF. Snoofle (author) is the auditor.

Edit: oh well, snoofle beat me to it

So, fire the guy? Why just tell him he's doing good to his face and then mock him on the internet?

Santosh was obviously from India and "cheap" labour for this company.

I guess they get what they paid for.

Most companies wouldn't realize their mistakes by outsourcing development to third world countries where the "senior" developers are actually interns like this clown.
They would find out once the software was deployed to production and their maintenence costs (being handled by the same outsourcing company) are 10 times would they should have been.

So much for saving money.

Remy Porter:

And fun fact: there's never actually been a study done to see if frequent password changes actually improve security. And there's no reason to think it would- at best, you're revoking an already compromised password. But on a 90 day password cycle, that means you have an average of 45 days of unfettered access. On a 30-day password cycle, it's an average of 15.

And what's the average amount of time an attacker needs to exploit a compromised password? I'm sure it varies, but I can guarantee that the number isn't measured in days.

It's cargo-cult logic.

How about if the hashes (especially salted ones) are compromised instead of the passwords themselves?

As for what I think on the topic, I prefer a large password size and no cycle to a <10 char password with rotation.

A developer:

Santosh was obviously from India and "cheap" labour for this company.

About 71% of this company is cheap foreign labor. Mostly young and inexperienced. They do it to save money. Then they hire a couple of guys like me to come in and make it better.

That's where I keep getting all these stories!

snoofle:

Andy:

What kind of auditor is this?

I was the auditor. Santosh is on my team and sits nearby. Nobody likes this guy, mostly because he talks the talk, but codes like this (actual, unaltered code presented). I was doing a routine code review, stumbled upon his latest creation and showed it to our boss who insisted on the public code review, in front of the whole team!

That's mean. I like it.

Note to self: try to avoid working for snoofle. Secondary note: if you fail to avoid this, keep your code clean.

Note to snoofle: warn the boss about constructive dismissal.

I don't find anything wrong with the code.

I love that the articles are being refactored ... Brillant!

Andy:

What kind of auditor is this? Most auditors I've encountered just say things like "your passwords aren't being changed every 30 days."

There are auditors and then there are auditors.

I work for an organization that has to be accredited. We just switched accrediting organizations, from one here in the U.S. to one out of Europe.

We were warned they might drop by our office, which is...not centralized. We get that warning every time the auditors are in town and someone said something about that "never having happened" before and I responded that, with auditors out of Europe, they were likely to audit (as in doing real work) which meant: "Who knows where they'll show up?"

Then someone else spoke up, saying that was right, because, "The auditors already visited a [remote supply warehouse where no auditor has EVER visited before]." And not only that, but the auditors discovered an omission at that warehouse that has been omitted for 20 years...and made the organization fix it.

See, some auditors are lazy, and ask lame questions like, "How come you don't change your password enough?" Other auditors are not afraid of work and will actually visit remote places, or tear apart your code and expose every drop of poor quality to the light of day.

But that doesn't mean you should be afraid of good auditors (except at the IRS). Good auditors are there to find deficiencies and show you how to do better, and you should be afraid only if you have an aversion to doing better.

Quite a few WTF's related here could stand a review--and exposure--by a good auditor. (Wait...that means...good heavens we ARE auditors!)

Yes the biggest problem with the education system is its stress on individual effort. There is nothing more upsetting than to find that a recent grad spent a week working on a problem which is already solved in your code base. Homework is for school, not the real world. Ask before you do things on your own.

Steve The Cynic:

snoofle:

Andy:

What kind of auditor is this?

I was the auditor. Santosh is on my team and sits nearby. Nobody likes this guy, mostly because he talks the talk, but codes like this (actual, unaltered code presented). I was doing a routine code review, stumbled upon his latest creation and showed it to our boss who insisted on the public code review, in front of the whole team!

That's mean. I like it.

Note to self: try to avoid working for snoofle. Secondary note: if you fail to avoid this, keep your code clean.

Note to myself: Apply for any work with soofle!
During my career I have had the good fortune twice to work with exceptionally knowledgable and competent individuals. (One of them qualified for the "database $deity" title.) By listening, observing and asking, they were amazing learning situations.

mmmok:

Suddenly the president's sick daughter walked in.

"But we thought you died!" exclaimed the Auditor.

"I did" she replied.

Suddenly there was piss everwhere.

Award-winning job of tying two WTFs together! ++

Scott:

Andy:

What kind of auditor is this? Most auditors I've encountered just say things like "your passwords aren't being changed every 30 days."

If you ask "why 30 days and not 90?" they reply "because that's what it says on my checklist here."

Auditors like this drove the final nail in any chance of remembering your password. Thanks to them, I haven't known any of my passwords in 5 years, except the passwords I need to get to my password vault.

Talk about a high-risk target! And it didn't exist, until the auditors forced it on me.

+1

Remy Porter:

And fun fact: there's never actually been a study done to see if frequent password changes actually improve security. And there's no reason to think it would- at best, you're revoking an already compromised password. But on a 90 day password cycle, that means you have an average of 45 days of unfettered access. On a 30-day password cycle, it's an average of 15.

And what's the average amount of time an attacker needs to exploit a compromised password? I'm sure it varies, but I can guarantee that the number isn't measured in days.

It's cargo-cult logic.

So true. If I get your password, I'm going to get it in one second, not by brute forcing it. Brute force cracking is so 1980s, and can be easily detected and thwarted today. So what are you going to do? Change everybody's password every second? I think that's called a hardware token, two-factor authentication, because the first factor sucks and we all know it.

Anyone who claims to be in the security field and can't take you through an informed discussion of various risks, attacks, defenses and their relative ranking doesn't deserve a nickel of their pay. "Checklist" auditors need to start following janitors around, or something.

Steve The Cynic:

In ST, you see, the terminology is that one object sends a (named) message to another, possibly with parameters, and the other handles the message by dispatching the parameters to a matching-named method.

Serious question (I know, wrong site) but how is "sending a message to an object" any different from calling a function, and why does it matter? I mean, either way, the CPU is going to go "time to bundle up these bits of data and execute this chunk of code" right?

Yes I can google it. I'm looking for less than 234,521,754 pages of answers.

After that, I resigned in disgrace and felt obligated to commit ritual suicide. My family in India starved when the money stopped coming in, but it's OK because it gave the family living in the adjacent cardboard box some fresh protein to eat.

I thought I was doing great! I mean, the code compiled. Do you have any idea how much effort I put into getting just that far?

Sam The Student:

Steve The Cynic:

In ST, you see, the terminology is that one object sends a (named) message to another, possibly with parameters, and the other handles the message by dispatching the parameters to a matching-named method.

Serious question (I know, wrong site) but how is "sending a message to an object" any different from calling a function, and why does it matter? I mean, either way, the CPU is going to go "time to bundle up these bits of data and execute this chunk of code" right?

Yes I can google it. I'm looking for less than 234,521,754 pages of answers.

It is *called* "sending a message", but there are many other things that are called "sending a message", including 1001 variations on actually sending a message. The bozo intern didn't know that in OOP, "sending a message" doesn't mean sending a message, but rather it means "calling a member function, but that's too obvious so we'll call it something that's also used for a completely different thing". Because he didn't know that, he wrote code to actually send the message, and he got it wrong, not least because he arranged for the object to send a message to itself when a member function was invoked...

HowItWorks:

Steve The Cynic:

That's mean. I like it.

Note to self: try to avoid working for snoofle. Secondary note: if you fail to avoid this, keep your code clean.

Note to myself: Apply for any work with soofle!
During my career I have had the good fortune twice to work with exceptionally knowledgable and competent individuals. (One of them qualified for the "database $deity" title.) By listening, observing and asking, they were amazing learning situations.

Your joke detector failed here, dude. I also like working for demonstrably smart+competent[1] people, for much the same reasons as you.

[1] It isn't actually guaranteed that these two characteristics are both present. Either may be present without the other. If I had to choose one for a colleague to be (i.e. smart XOR competent), I'd prefer competent-but-not-not-stellar-brains to smart-but-sloppy.

Shawn H Corey:

There is nothing more upsetting than to find that a recent grad spent a week working on a problem which is already solved in your code base. Homework is for school, not the real world. Ask before you do things on your own.

Upsetting because you could have avoided it by asking for their status each day.

Steve The Cynic:

The bozo intern didn't know that in OOP, "sending a message" doesn't mean sending a message, but rather it means "calling a member function, but that's too obvious so we'll call it something that's also used for a completely different thing".

QFT

Steve The Cynic:

Your joke detector failed here, dude.

Protip: every time you have to say this, it means your joke failed.

ZoomST:

Nagesh:

First rule of audit inspection is let auditor find thing for herself. Don't dig yourself in hole or put axe on your own foot.

+1
Frankly, after Santosh confession, I was expecting the auditor to say something like "Wow. I was about to point that the text formatting on your code was not using the correct indentation, but I will [happily] add this to the report [to show your bosses that I am a friggin' genious]. Be sure to fix this and the text indentation before next review [and don't expect a raise this year, BWAHAHA!]."

Captcha: ideo, as in "don't give away any ideo before knowing what's happening".

Nagesh got a +1?

Ironside:

Upsetting because you could have avoided it by asking for their status each day.

Is your name really Murray?

Scott:

Andy:

What kind of auditor is this? Most auditors I've encountered just say things like "your passwords aren't being changed every 30 days."

If you ask "why 30 days and not 90?" they reply "because that's what it says on my checklist here."

Auditors like this drove the final nail in any chance of remembering your password. Thanks to them, I haven't known any of my passwords in 5 years, except the passwords I need to get to my password vault.

Talk about a high-risk target! And it didn't exist, until the auditors forced it on me.

Password validation algorithms force password generation algorithms. Here's mine:

1. Pick a word whose letter count is greater than 2x then umber of previous passwords the algorithm remembers

2. Pick a separator character sequence that includes whatever characters the password validation algorithm requires (one special character and two numbers, for example)

3. Spell the first two letters of the word chosen in #1, phonetically (e.g.: Alpha Bravo)

4. Insert the separator sequence between the two phonetics

5. When password change time comes, use the next two letters in "the word", and the same separator characters.

Saves me from trying to remember a new password every 30 days, and is "unique enough" to pass the automated filter. All I have to remember is the original word and the separator sequence.

Remy Porter:

And fun fact: there's never actually been a study done to see if frequent password changes actually improve security. And there's no reason to think it would- at best, you're revoking an already compromised password. But on a 90 day password cycle, that means you have an average of 45 days of unfettered access. On a 30-day password cycle, it's an average of 15.

And what's the average amount of time an attacker needs to exploit a compromised password? I'm sure it varies, but I can guarantee that the number isn't measured in days.

It's cargo-cult logic.

While I agree with your conclusion (that frequent password changes may not improve security), I'm not sure your argument really supports it. In the first case, you're saying that, on average, it takes 45 days to get someone's password. Assuming the same password strength in both cases, that should remain constant regardless of how frequently the passwords are changed. So in the second case, on average, the attacker would be cracking the password 15 days after it had been changed to something else.

Peter:

Scott:

Andy:

What kind of auditor is this? Most auditors I've encountered just say things like "your passwords aren't being changed every 30 days."

If you ask "why 30 days and not 90?" they reply "because that's what it says on my checklist here."

Auditors like this drove the final nail in any chance of remembering your password. Thanks to them, I haven't known any of my passwords in 5 years, except the passwords I need to get to my password vault.

Talk about a high-risk target! And it didn't exist, until the auditors forced it on me.

Password validation algorithms force password generation algorithms. Here's mine:

1. Pick a word whose letter count is greater than 2x then umber of previous passwords the algorithm remembers

2. Pick a separator character sequence that includes whatever characters the password validation algorithm requires (one special character and two numbers, for example)

3. Spell the first two letters of the word chosen in #1, phonetically (e.g.: Alpha Bravo)

4. Insert the separator sequence between the two phonetics

5. When password change time comes, use the next two letters in "the word", and the same separator characters.

Saves me from trying to remember a new password every 30 days, and is "unique enough" to pass the automated filter. All I have to remember is the original word and the separator sequence.

Interesting. I too, use an algorithm. I have 24 passwords I rotate through. Starting with "Z", go diagonally up, over one and down the next row, capitalizing the first letter encountered. For example: Zaq12wsx. The next password change, start with X, then C, V, B and finally N. The do the same thing in reverse, but diagonally the other way: Zse45rdx. Then repeat, but from the numbers down and back up: 1Qazxsw2, ..., 0Okmnji9. If you need a character from !, @, #, ..., (, ), just use it as the first (last) character, depending upon which end of the keyboard from which you start.

It's pretty secure as I can't even remember them unless I'm looking at a keyboard, but trivial to type. And even when I tell someone what the current password is, they invariably get it wrong.

The best part is all you have to remember is the starting character and which way to zig-zag.

don:

you're saying that, on average, it takes 45 days to get someone's password

Reading comprehension time: "an average of 45 days of unfettered access"

That means that if you do somehow get the password, the average time in which it is useful is half the forced password change time, assuming that when you get it is independent from when the change happens. (such as by keystroke logging)

Nagesh:

QJo:

So the real WTF is not going to the lavatory immediately before the code review? That's Meeting 101.

Correct as great swami always say - He who can hold bladder for longest time will win argument. That is why women win most arguments.

I was about to argue that women absolutely cannot hold their bladder longer than men, then I saw that I would be arguing with Nagesh.

Carry on.