Encapsulation in the Hot Seat

« Return to Article
  • Remy Porter 2013-02-06 08:04
    Now that is some Enterprise-ready code.
  • Andy 2013-02-06 08:09
    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."
  • CleanCode 2013-02-06 08:14
    Wow, Some intern, and some auditor!
  • Rick 2013-02-06 08:17
    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?
  • QJo 2013-02-06 08:18
    So the real WTF is not going to the lavatory immediately before the code review? That's Meeting 101.
  • QJo 2013-02-06 08:20
    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.
  • QJo 2013-02-06 08:21
    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?"
  • LoremIpsumDolorSitAmet 2013-02-06 08:44
    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?

    Fantastic. This has to be featured.
  • Scott 2013-02-06 08:46
    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.
  • georgir 2013-02-06 08:48
    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?]
  • Nagesh 2013-02-06 08:51
    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.
  • imgx64 2013-02-06 08:52
    TRTWF is the SQL injection.
  • mmmok 2013-02-06 08:52
    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.
  • Nagesh 2013-02-06 08:52
    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.
  • Remy Porter 2013-02-06 08:53
    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.
  • Gyxi 2013-02-06 08:54
    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.
  • Nagesh 2013-02-06 08:55
    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.
  • Gyxi 2013-02-06 08:56
    Except requestQueue.take() IS blocking, just as it says in the article. So what I described was only hypthetically true, also known as false.
  • Yojin 2013-02-06 09:00
    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.
  • Steve The Cynic 2013-02-06 09:25
    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...
  • snoofle 2013-02-06 09:27
    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!
  • ZoomST 2013-02-06 09:30
    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".
  • darkmattar 2013-02-06 09:32
    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
  • chris 2013-02-06 09:36
    So, fire the guy? Why just tell him he's doing good to his face and then mock him on the internet?
  • A developer 2013-02-06 09:42
    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.
  • portablejim 2013-02-06 09:45
    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.
  • snoofle 2013-02-06 10:03
    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!
  • Steve The Cynic 2013-02-06 10:06
    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.
  • Sans Tho K. 2013-02-06 10:11
    I don't find anything wrong with the code.
  • pbean 2013-02-06 10:18
    I love that the articles are being refactored ... Brillant!
  • Coyne 2013-02-06 10:19
    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!)
  • Shawn H Corey 2013-02-06 10:20
    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.
  • HowItWorks 2013-02-06 10:21
    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.
  • Andy 2013-02-06 10:29
    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! ++
  • Annoying Cowherd 2013-02-06 10:31
    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
  • Kenneth 2013-02-06 10:33
    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.
  • Sam The Student 2013-02-06 10:39
    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.
  • Santosh 2013-02-06 10:45
    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?
  • Steve The Cynic 2013-02-06 10:52
    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...
  • Steve The Cynic 2013-02-06 10:57
    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.
  • Ironside 2013-02-06 11:00
    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.
  • ¯\(°_o)/¯ I DUNNO LOL 2013-02-06 11:02
    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
  • Dave 2013-02-06 11:20
    Steve The Cynic:
    Your joke detector failed here, dude.


    Protip: every time you have to say this, it means your joke failed.
  • laoreet 2013-02-06 11:34
    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?
  • Steve The Cynic 2013-02-06 11:35
    Ironside:
    Upsetting because you could have avoided it by asking for their status each day.

    Is your name really Murray?
  • Peter 2013-02-06 11:43
    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.
  • don 2013-02-06 11:57
    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.
  • snoofle 2013-02-06 12:10
    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.

  • ¯\(°_o)/¯ I DUNNO LOL 2013-02-06 12:12
    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)
  • C-Derb 2013-02-06 12:12
    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.
  • Rob 2013-02-06 12:25
    imgx64:
    TRTWF is the SQL injection.

    Don't forget the closing of the ResultSet, PreparedStatement and Connection that will never happen if executing the statement throws an exception. Did Santosh never hear of finally blocks?
  • Daniel 2013-02-06 12:48
    Is the real wtf that the comment worth featuring wasn't?
  • Andrew 2013-02-06 12:48
    The auditor was reasonable, supportive, and actually correct about our protagonist's code, and he learned something by trying to justify his design to someone else.

    Where's the WTF, TRWTF, and the PHB?!
  • chubertdev 2013-02-06 12:49
    C-Derb:
    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.


    Maybe he hangs out with whales.
  • Bruce W 2013-02-06 12:53
    snoofle:
    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.



    Note to self - add Snoofle's 24 passwords to rainbow table.
  • Zylon 2013-02-06 13:00
    Snoofle, you're on a computer, not a typewriter. It's okay to use italics instead of is-that-a-hyperlink-oh-no-its-just-an -underline underlines now.
  • ubersoldat 2013-02-06 13:06
    I had to read the story two times to understand who was talking when. And at the end TWTF is not from the auditor? I don't like that.


    On the other hand, if I was that auditor I wouldn't even wasted my time explaining to Santosh how stupid his getters were and what an awful PoS all that code is.
  • Nagesh 2013-02-06 13:14
    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.


    Ask keePass to generate password every once in 30 days.
    Keep it simple silly!
  • Nagesh 2013-02-06 13:15
    C-Derb:
    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.


    is clear that swamiji and you're on different astral plain. in my company women beat mean at this game every time. coffee or not no make difference.
  • Nagesh 2013-02-06 13:16
    chubertdev:
    C-Derb:
    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.


    Maybe he hangs out with whales.


    Hey don't judge fat women!
  • Xaser 2013-02-06 13:24
    Today's article rubs me the wrong way. The code is feature-worthy, but the presentation is all backwards: why is the story not written from the submitter's perspective (and the wrong name bolded)? It reads really awkwardly as a result, especially after checking the comments and finding out it wasn't a confession post.

    I'm being a whiny arse, of course, but I was similarly un-thrilled with yesterday's article for various reasons (confusing presentation and unclear ending) and I'm hoping this doesn't mark a shift away from the TDWTF we all know and love. TRWTF would be if this trend continues. :P

    On second thought, though, perhaps I should be thankful. Without these two articles, mmmok's comment on p.1 wouldn't exist, which provided the heartiest laugh I've had all week.
  • snoofle 2013-02-06 13:34
    Xaser:
    ...finding out it wasn't a confession post...
    It actually was a confession - the guy nearly broke down after being forced to explain his code to the entire team. It was just related by me from his perspective.
  • Anon 2013-02-06 13:51
    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!


    Wait...then how do you know so much about the current status of Santosh's bladder? Is this a thing where you work?
  • Anon 2013-02-06 13:52
    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.


    Good point. This is why I change my password every 5 minutes.
  • SomeCoder 2013-02-06 13:54
    Is it bad that this code - presumably from Snoofle's intern - looks like the regular stuff coded up by our SENIOR ENGINEERS/ARCHITECTS at my work?

    *SIGH*
  • snoofle 2013-02-06 14:09
    Anon:
    Wait...then how do you know so much about the current status of Santosh's bladder? Is this a thing where you work?
    The dance
  • mihi 2013-02-06 14:16
    And:

    Using a String array instead of an object with named fields to store the messages.

    Use "stringly typed enums" for deciding which action to perform.

    Using equalsIgnoreCase for comparing the (upper case) string values in case you forget to press the Shift key later.
  • Evan 2013-02-06 14:16
    I just start with hunter2 and increment the ending number.
  • DrPepper 2013-02-06 14:42
    Oh, I’m safe, all my code has been in Production and working fine, surely someone would have complained!


    How many times I've made the same invocation!!!

    Seriously, didn't anyone ask this person for a code sample before hiring them?
  • Matt Westwood 2013-02-06 14:51
    Santosh:
    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?


    It's a fuck of a lot bloody further than the shit that one of my arsebrained colleagues used to check into our codebase.
  • Geoff 2013-02-06 15:21
    Guys you know there is more than one type of risk associated with passwords right? Most of they are an identity mechanism and most systems are still single factor.

    Its true 'external' brute force attempts are easy to detect and defend against? What about offline attacks? Most of the time password resets/changes are logged, modifying a password store or even the reading of it by any unusual process might also be logged, but not recovering it from a backup tape etc. So there may be a number of IT administrative people in an org that at least on occasion have access to this data.

    Password rotation is an important control. If can get the passwd/shadow/sam etc file off a machine I can brute force the password undetectably but assuming they are of a decent length and complexity it will take weeks or months. Once I have one of these passwords I can use the identity of that individual as much as like with little chance of any audit mechanism showing conclusively that its someone other than the account owner performing these activities; let alone produce conclusive evidence of who the perp is. For there other controls might be effectively thwarted, perhaps someone who is not on the insiders SEC list can now access insider data, etc.

    This is one hole password rotation + complexity can at least help to close.
  • WhatsMyName 2013-02-06 15:52
    correcthoursebatterystaple

    Enough said
  • Dann of Thursday 2013-02-06 16:23
    Evan:
    I just start with hunter2 and increment the ending number.


    How did you know my password?!
  • Spits Coffee Through His Nose 2013-02-06 16:30
    ...all my code has been in Production and...


    “Just remember - after you’re hired when your internship is over,...


    *faint*
  • pn 2013-02-06 16:39
    snoofle:
    It actually was a confession - the guy nearly broke down after being forced to explain his code to the entire team. It was just related by me from his perspective.
    Since a few years ago, all code in our shop goes through peer review before it gets merged into the mainline. It does wonders even when there are no interns in the team.
  • david 2013-02-06 17:00
    portablejim:

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


    (a) I think you mean "especially unsalted" instead of "salted" in which case just go out back and shoot yourself. Salting is easy, there is no excuse for not salting.

    (b) If your concern is that someone may spend months trying to crack a salted hashed password then just increase the number of hashing rounds by a magnitude or two. If you are concerned that someone will spend years trying to crack a salted hashed password... you are the NSA and have other weaknesses to spend your time on.
  • Chris Lively 2013-02-06 17:07
    WTFs not previously mentioned
    1. Potential leaked sql connections - no using statements and lack of try..catch/finally clauses near where the error will occur.
    2. Badly named method: "selectQuantityFromDB" may as well have named it: SelectCountFromAnyTableHopeItDoesntBlow
    3. Potential SQL injections in "selectQuantityFromDB"
    4. Complete lack of parameter checking in "selectQuantityFromDB".
    5. Impossible to debug SQL due to using that dumb ass "selectQuantityFromDB" method.
    6. Threading for apparently no other reason than because it looks cool.

    That last sentence of the Auditor should have been:
    "Just remember - Never be afraid to ask for help from your next employer."
  • Tim 2013-02-06 17:20
    Shawn H Corey:
    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.


    I can think of two things more upsetting off the top of my head.

    1. Finding that a senior developer spent a week working on a problem that is already solved in your code base, and them then refusing to refactor to use the better of the two solutions.

    2. Finding that you just spent a week working on a problem that is already solved in your code base. Bonus points if the existing solution is better than your solution.

    Note that #2 is different to discovering that the problem is already solved badly in your code base and you spend a week improving it.
  • someone 2013-02-06 18:05
    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.


    On the other hand I have hacked a system two years ago and still have full access to everything (from webserver over NAS to switches), because no one of them has changed their password...

    And how did I hack them? A file traversal bug in on of their custom written cgi scripts that let me view a 3 year old database dump. Which contained the unchanged webadmin password...

  • bambam 2013-02-06 18:45
    Peter:

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

    I prefer to use the color burnt umber in my passwords.
  • F 2013-02-06 18:50
    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.

    ... and where you have got to in the series. Or do you expect the login routine to allow several dozen failed attempts?
  • Norman Diamond 2013-02-06 19:26
    Coyne:
    But that doesn't mean you should be afraid of good auditors (except at the IRS).
    No exception. If the "IRS" had good auditors, they'd pay refunds owing to honest people. You need to be afraid of their non-good non-auditors who steal, make false allegations, conceal facts until court cases are under way, destroy records, submit perjured declarations, and prove how much damage they can do to honest people. I'll take audits any day.
  • Norman Diamond 2013-02-06 19:36
    Anon:
    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.
    Good point. This is why I change my password every 5 minutes.
    I WEP'ed when I read that.
  • Curtis P 2013-02-06 19:37
    Is this your own observation, or one you culled from elsewhere. It may well be the most cogent thought I have ever seen on the art of programming.
  • Curtis P 2013-02-06 19:43
    bambam:
    Peter:

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

    I prefer to use the color burnt umber in my passwords.


    I prefer umber hulks.
  • noname 2013-02-06 20:07
    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.
    Depends what you mean by "study"....

    I've seen a lot of literature online talking about the increased vulnerability (people select easier passwords, or write them down), increased cost (people keep locking their accounts) etc.

    One of the most interesting ones I;ve read even tried to assess the situation where a "bad guy" was in the process of brute forcing and a password was changed, whether it would increase, decrease or not affect the likelihood of an eventual breach.

    For accounts that lock after x failed attempts, brute forcing is pretty effectively stopped (I suppose it would be possible for someone to try once a day on the assumption that a user will have a successful log in in between or someething, but for brute force that makes for a LOOOOOONG time anyways).

    For situations where people are playing rainbow table games, the system must already be compromised to some degree to have leached the hashes....and (as someone else pointed out) the only benefit of expiration is in the case that your account is already breached....Incidentally, I don't think secure passwords are particularly resistant to rainbow table attacks - because hashes are not unique - of course a well salted hash makes these a lot more difficult....YUM

    But I increasingly learn that there are certain types who enjoy arbitrary rules. These are usually (not always) the people who you work with who really make you wonder whether qualifications were on sale at the flea market. They tend to obsess on the letter of the law rather than the spirit of the law, because they understand what the rule is, not why the rule exists. They also thrive on process - because you don't need to think - you just become a process automaton. For some reason (possibly because there's a certain necessity for rules) they seem to end up in management, security and audits.....

    Oh, they also love metrics - and you can often get them off your case by giving them some fun meaningless number puzzle to work on (like calculating number bugs vs number potential bugs - SixSigma...oh yeah).

    Our security dept is like that. We have an obsession with expiring passwords - on systems that are only connected to the outside world through other theoretically impenetrable systems. If someone is brute forcing my account on this account, then they must have already breached a network that (we'd like to think) is pretty secure.....

  • Jacker 2013-02-06 20:23
    someone:
    I have hacked a system two years ago and still have full access to everything (from webserver over NAS to switches), because no one of them has changed their password.
    If you were a competent hacker, changing passwords wouldn't do a thing to you. They'd have to erase everything and reinstall from trusted offline media.

    So changing passwords every 5 minutes wouldn't help, once you're in.
  • jum 2013-02-06 20:39
    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!
    Then:
    1) Why is his name bold?
    2) How on earth did you know what he was thinking?

    You're becoming one of THEM....
  • fe 2013-02-06 20:48
    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.

    http://www.howsecureismypassword.net/

    Alpha!23Bravo
    scores: 26 Million years...that's not bad

  • Meep 2013-02-06 20:50
    Remy Porter:
    And fun fact: there's never actually been a study done to see if frequent password changes actually improve security.


    Has there even been a study to figure out what counts as an improvement? I mean, how do you even measure this stuff? Presumably I'm running some firm and we have a mission that is, over a certain period, worth something. When we implement a security policy, we lose an amount of productivity worth S, but it either reduces the likelihood of an expected attack or the severity of the damage of that attack, such that our overall expected losses are less by T. If we can show that S < T, we win.

    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.


    It sort of makes sense if someone wants to lurk quietly and snarf up data. On a secured military network for instance, or maybe a corporate network.

    That said, if an attacker can get into such a network, they're far better off setting up a backdoor than reusing your password.

    For most of our important passwords, such as with financial institutions, it makes no sense at all. They're going to empty your accounts the instant they're in.
  • fe 2013-02-06 20:50
    snoofle:
    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.


    Zaq12wsx scores "instantly"
    Zse45rdx scores 15 hours
  • Chekov's Gun 2013-02-06 20:56
    I was going to write a longer response, but oops, gotta go...

  • Mitch 2013-02-06 21:07
    Meep:
    Remy Porter:
    And fun fact: there's never actually been a study done to see if frequent password changes actually improve security.


    Has there even been a study to figure out what counts as an improvement? I mean, how do you even measure this stuff? Presumably I'm running some firm and we have a mission that is, over a certain period, worth something. When we implement a security policy, we lose an amount of productivity worth S, but it either reduces the likelihood of an expected attack or the severity of the damage of that attack, such that our overall expected losses are less by T. If we can show that S < T, we win.

    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.


    It sort of makes sense if someone wants to lurk quietly and snarf up data. On a secured military network for instance, or maybe a corporate network.

    That said, if an attacker can get into such a network, they're far better off setting up a backdoor than reusing your password.

    For most of our important passwords, such as with financial institutions, it makes no sense at all. They're going to empty your accounts the instant they're in.

    I think customers of financial institutions are relatively small fry. A hacker who can get in far enough to start brute forcing a password file is probably not interested in the small fry.
    Of course, an insider is a threat, though, because they may have access to the password file (to brute force it). They also may understand banking better and have ideas about lots of small unnoticeable thefts vs larger ones (stealing from individuals is less risk than stealing from the organisation - because the organisation will typically not believe the individual, so they have a massive battle to even get the bank interested that $20 is missing from their account).

    CAPTCVHA: Appellatio....never mind
  • Norman Diamond 2013-02-06 23:03
    http://www.howsecureismypassword.net/:
    How Secure Is My Password?
    一二三四五六七八九十九八七六五四三二一
    It would take a desktop PC about 0 seconds to crack your password
    Length: Long
    Your password is over 16 characters long. It should be pretty safe.
    Character Variety: Non-Standard Character
    Your password contains a non-keyboard character. This should make it more secure.
    If safe and secure would take about 0 seconds to crack, how long would dumber passwords take?
  • Bill C. 2013-02-06 23:08
    the president's daughter
    would take
    37 sextillion years
    to crack.
    You sure that makes her safe?
  • Kef Schecter 2013-02-06 23:36
    darkmattar:
    He didn't post his own WTF. Snoofle (author) is the auditor.

    Then maybe whoever edited the article shouldn't have put Santosh's name in bold, considering how, in every other article, the name in bold corresponds to the submitter.
  • Scarlet Manuka 2013-02-07 01:21
    QJo:
    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.

    This reminds me of the bit in "Mostly Harmless" about the book where the protagonist suddenly dies of thirst about two thirds of the way through, due to a problem with the plumbing that was mentioned near the beginning.
  • Swedish tard 2013-02-07 02:46
    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.


    I just use a chronogically ascending list of women i've had sex with, appended with a quasiramdom sequence of characters (same every time).
    Never have any problems. Plus, I can keep a post it with the passwords on my monitor, sans the quasirandom sequence and it looks like a random list of female names.
    Even if someone got the list, it's just a bunch of names, with no clue as to what name is used as a password where and even if they managed to figure that out, the quasirandom sequence exists only in my head...
    Otoh, a half decen keylogger would work any password out in no time... And there are hardwareloggers that no software scanner can detect. I'm even fairly sure I've seen adverts for hardware keyloggers that are capable of phoning home.
  • Steve The Cynic 2013-02-07 03:31
    [quote user="fe"]The best part is all you have to remember is the starting character and which way to zig-zag.

    [/quote]
    Zaq12wsx scores "instantly"
    Zse45rdx scores 15 hours[/quote]
    Curiously, on my keyboard, the first has jumps and shifts in the middle, but is otherwise moderately zigzaggy, while the second is south, NE, NE, E, SW, SW, SW. I despise AZERTY keyboards, except when I can poke fun at people assuming the whole world uses US-QWERTY[*].

    [*] I note in passing that most of these people aren't aware that UK-QWERTY differs in a number of significant ways, and that they also aren't old enough to have used a Commodore-64, which had a modified UK-QWERTY layout even in the US.
  • Steve The Cynic 2013-02-07 04:12
    snoofle:
    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.

    It also helps to remember the keyboard layout you used. If I used your algorithm on my keyboard, I'd get different passwords.

    First: Zé"edcvf (assuming you zigzag again at the bottom and you don't use spaces)
    Second: Z"'eswxd

    Key point: on AZERTY keyboards, the top-row keys require shift to get the numbers. And the so-called Caps Lock key also affects the top-row keys. And square brackets, hashes, backslashes, carets, and braces all require AltGr. I despise this layout, but I use it so I don't have problems between my machines and those of colleagues, nor between work and home. QWERTY keyboards are hard to find in France.
  • beginner_ 2013-02-07 05:12
    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."


    Yeah, I wonder were those people get these stupid ideas. And then if they start to enforce numbers + different case letters + special chars people will just write it down and stick it to the display. What do they expect users to do?

    Luckily my companies "algorithm" is stupid enough not to notice my pattern which consist of month + year. if they change that I swear I put a sticky note on my display...just to make a point.

    It would make a lot of sense to just distribute fingerprint scanners and use them for login. More secure and much easier for the user.
  • Gibbon1 2013-02-07 05:48
    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". 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...


    You got to admit though Santosh has to be some very deep shade of green when he wrote that. Everything about him had to be a lie, no training, no experience, nothing but the ability to bullshit. And yet a very short time later (A month? Four Months?) he can list off all the things he did totally wrong.
  • Meep 2013-02-07 06:24
    Rob:
    imgx64:
    TRTWF is the SQL injection.

    Don't forget the closing of the ResultSet, PreparedStatement and Connection that will never happen if executing the statement throws an exception. Did Santosh never hear of finally blocks?


    Better than finally, try-with-resources guarantees the close() method is called:

    try(PreparedStatement ps = conn.createPreparedStatement("...")) {
    
    do stuff
    }


    Anything that's AutoCloseable works, and Closeable objects (like streams) work too.
  • Edmund 2013-02-07 07:00
    Remy Porter:
    Now that is some Enterprise-ready code.

    If you mean it can uploaded to cause the Klingon mothership's computing systems to self-destruct, then yes.
  • Sam 2013-02-07 07:14
    beginner_:
    It would make a lot of sense to just distribute fingerprint scanners and use them for login. More secure and much easier for the user.
    Easier is not usually more secure, sadly. Your fingerprint is your user-ID, not your password. It can be obtained by others. It cannot be changed every 90 days. So even with a fingerprint reader, you still need some secret that can be changed if anyone else gets it.
  • Steve The Cynic 2013-02-07 08:06
    Sam:
    beginner_:
    It would make a lot of sense to just distribute fingerprint scanners and use them for login. More secure and much easier for the user.
    Easier is not usually more secure, sadly. Your fingerprint is your user-ID, not your password. It can be obtained by others. It cannot be changed every 90 days. So even with a fingerprint reader, you still need some secret that can be changed if anyone else gets it.

    A cleaver is probably the quickest way to get hold of someone's fingerprint (and the rest of the finger, of course), but it isn't the only way. Some (cheap) scanners are even vulnerable to a breath-condensation attack -> activate the fingerprint check, then breathe on the scanner so as to cause a small layer of condensation. This interacts with the actual fingerprint of the previous user that remains on the surface of the scanner. The result is that the scanner thinks a real finger is on there, with the right print. The other advantage of such an attack is that you don't need to know which finger to steal from the unfortunate user.

    Other biometrics are no better. Iris scanners are subject to a variety of fake-image attacks, and some people cannot use them because their irises have no recognisable pattern. Retina scanners are better, but they are very intrusive, and still prone to failures as the pattern changes slowly over time. Voice print recognition fails miserably if there is a lot of ambient noise, and also is prone to false negatives if the unfortunate user has a bad cold.

    And so on.

    And the most effective ways to defeat any sort of on-location security? Co-opt an insider (bribes around 5 times annual salary are usually more than sufficient to achieve this with normal office workers) or have the target enterprise hire one of your own people who then acts as a spy. This utterly defeats all sorts of biometrics and token-based security, because the on-location attacker is also a trusted party.

    You can't secure it totally. The best you can do is make the cost of the attack higher than the benefit to the attacker.
  • Hmmmm 2013-02-07 09:24
    Curtis P:
    I prefer umber hulks.

    I prefer burnt umber hulks... Fireball FTW!
  • Anon 2013-02-07 09:33
    Swedish tard:

    I just use a chronogically ascending list of women i've had sex with, appended with a quasiramdom sequence of characters (same every time).


    So...you have one password, got it.
  • Nagesh 2013-02-07 11:37
    Swedish tard:
    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.


    I just use a chronogically ascending list of women i've had sex with, appended with a quasiramdom sequence of characters (same every time).
    Never have any problems. Plus, I can keep a post it with the passwords on my monitor, sans the quasirandom sequence and it looks like a random list of female names.
    Even if someone got the list, it's just a bunch of names, with no clue as to what name is used as a password where and even if they managed to figure that out, the quasirandom sequence exists only in my head...
    Otoh, a half decen keylogger would work any password out in no time... And there are hardwareloggers that no software scanner can detect. I'm even fairly sure I've seen adverts for hardware keyloggers that are capable of phoning home.


    Hardware dongle is useless as we know from Alex previous story.
  • Nagesh 2013-02-07 11:38
    Anon:
    Swedish tard:

    I just use a chronogically ascending list of women i've had sex with, appended with a quasiramdom sequence of characters (same every time).


    So...you have one password, got it.


    if I follow that logic, i will have NULL for password.
  • jay 2013-02-07 11:46
    Sam The Student:
    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?


    "Sending a message" is the modern, trendy new OOP term for "calling a function".

    In the IT field, every few years we have to make up new names for everything. Like this example. Or when databases came out and now "record" is renamed "row" and "field" is renamed "column". Etc.

    Making up new names for old ideas accomplishes two things.

    First, suppose you come up with a truly idea. You want to write a book and give lectures and become a consultant and make a lot of money. But most valuable new ideas in IT can be summed up in a paragraph. Maybe a few pages to really explain and give examples. That's not enough to make a book. So you have to rename a bunch of old ideas and describe all your new names to pad out the book.

    Second, suppose you don't have a truly new idea. But you still want to write a book, etc, and make a lot of money. Then you can skip the chapter with the new idea, and just rename a bunch of old ideas and restate what everybody already knows but with new words, and pretend it's something new.

    Also, making new names for old ideas lets all the people who have learned the new name laugh at the ignorant people who are still using the old name.
  • Paul Neumann 2013-02-07 13:17
    I tried it. It works on my machine.
  • fjf 2013-02-07 16:30
    snoofle:
    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.
    Brillant! Just wait until those damn hackers get keyboards too.
  • PiisAWheeL 2013-02-07 16:54
    snoofle:
    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.

    That seems a bit excessive. I just use pass phrases where available. If you don't know what a pass phase is here is an obligatory xkcd to explain it. http://xkcd.com/936/
    It doesn't really matter what your password is, as long as its hard to guess, and long enough to be inefficient to crack.

    If you get keylogged well the strength of your passwords doesn't mean shit.

    And to finish off, my favorite quote for passwords:
    Please Create a password. Your password needs to contain a capital letter, a number, an emoji, 8 elements from the periodic Table, and a plot containing a protagonist with some character development and a twisted ending.
  • Dom 2013-02-07 17:14
    As best I can work out it's a hang-over from the days when it [u]was[/] a valid security measure. In other words, a large number of untrusted users (otherwise known as "students") who [u]would[/] attempt a brute force attack on the root password if they thought it might work - and insufficient computing resources to log or block failed logins.
  • The Crunger 2013-02-07 21:54
    jay:
    Sam The Student:
    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?


    "Sending a message" is the modern, trendy new OOP term for "calling a function".

    In the IT field, every few years we have to make up new names for everything.


    Implementation-wise, it doesn't really matter. An asynchronous message-passing facility (when properly functioning) should be just as reliable at executing methods as a statically-bound function call.

    The point was for people to understand how object-oriented design was different from traditional procedural design.

    In procedural programming, your goal was to develop one general-purpose agent that has access to a wealth of diverse information, and is capable of performing many different types of tasks. So, if your agent were in a flying craft, and the goal was to blow something up, the general-purpose agent would call one function to select a reasonable mix of bombs, another raft of functions to arm them, open the bay doors, wait for the signal from the operator, and release the bombs when so directed.

    Object-oriented design asked you to look at your goals a different way, and I honestly remember the instructor referring to the movie _Dark Star_, (which I had not yet seen) when the character said:

    "Arm Yourself, Bomb"

    Instead of calling functions, and getting wrapped up in their structures, you were at arms length, dispatching general instructions to thinking objects within the system.

    The movie also serves a good illustration of what happens when the objects are a little too intelligent...
  • The Crunger 2013-02-07 22:20
    Steve The Cynic:

    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?


    I'm not sure I follow the crux of your question, Steve.

    The vtable is the dispatch process for C++. The only time virtual methods could be called directly (without dereferencing the slot in the vtable) is when they aren't really virtual.

    Something would have to be muddled in the object class's inheritance tree -- not all levels defined virtual, or perhaps not properly recompiled. Overloaded method names can also cause fun, either by strangely hiding the methods you thought would inherit, or some implicit type-casting causes a non-virtual imposter to get called.

    -- Captcha: ullamcorper -- your final message for someone you don't respect who has passed away
  • Steve The Cynic 2013-02-08 03:04
    The Crunger:
    Steve The Cynic:

    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?


    I'm not sure I follow the crux of your question, Steve.

    The vtable is the dispatch process for C++. The only time virtual methods could be called directly (without dereferencing the slot in the vtable) is when they aren't really virtual.

    Something would have to be muddled in the object class's inheritance tree -- not all levels defined virtual, or perhaps not properly recompiled. Overloaded method names can also cause fun, either by strangely hiding the methods you thought would inherit, or some implicit type-casting causes a non-virtual imposter to get called.

    -- Captcha: ullamcorper -- your final message for someone you don't respect who has passed away

    Take one fail point.

    ClassWithVirtuals object(constructorParameters); // note: a real object, not a reference or pointer
    

    object.virtualMethod(methodParameters); // Calls method directly not through virtual dispatcher

    The key point being that you know definitively what class the object is *at compile time*, so you can call the member function directly.

    Oh, and don't go around thinking that because everyone uses vtables, that's actually required by the standard. Early implementations of C++ didn't use vtables, and virtual function dispatch was horribly, horribly slow as a result.
  • Don 2013-02-08 03:53
    "Sending a message" is the modern, trendy new OOP term for "calling a function".


    By new do you mean new when Smalltalk popularized the concept over 30 years ago? Sending a message means much more than just calling a (static) function.
  • Hatshepsut 2013-02-08 09:52
    snoofle:
    Xaser:
    ...finding out it wasn't a confession post...
    It actually was a confession -

    No it wasn't.

    snoofle:
    the guy nearly broke down after being forced to explain his code to the entire team.

    That's a confession. Two, in fact.

    snoofle:
    It was just related by me from his perspective.

    Apart from his perspective on the, y'know, breakdown bit.
    And the public humiliation bit.
    But yeah, kind of from his perspective.

  • Barf 4Eva 2013-02-08 17:41
    Totally agree. I'm supposed to be the c# expert on my team. It makes me want to cry.
  • Gunslinger 2013-02-09 01:55
    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.


    Or just append "01" at the end of your first password. When you have to change it, make it "02". And so forth. If you want to get fancy, hold down shift first. But yes, forced password changing is a real WTF.
  • SQLDave 2013-02-10 17:54
    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."


    Perhaps the auditor used to be a proctologist.
  • Evan 2013-02-10 19:52
    The Crunger:
    Steve The Cynic:

    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?


    I'm not sure I follow the crux of your question, Steve.

    The vtable is the dispatch process for C++. The only time virtual methods could be called directly (without dereferencing the slot in the vtable) is when they aren't really virtual.

    Something would have to be muddled in the object class's inheritance tree -- not all levels defined virtual, or perhaps not properly recompiled. Overloaded method names can also cause fun, either by strangely hiding the methods you thought would inherit, or some implicit type-casting causes a non-virtual imposter to get called.

    My guess is that Steve was looking for the situation where you call a virtual function on an object whose dynamic type the compiler is able to determine for certain. In such a case, the compiler may optimize out the dispatch from the vtable and call the function directly. In fact, both GCC and Intel's compiler (the two I tried) both do this without any optimization flags.

    For example, consider this C++ code:
    struct Class {
    
    virtual void foo();
    };

    void virtual_call(Class * p) {
    p->foo();
    }

    void nonvirtual_call(Class c){
    c.foo();
    }


    When compiled with 'g++ -c -S -O2 no-vtable.cc', g++ 4.4 produces the following code (I include the -O2 to reduce the size of the code; it is not necessary to see the difference), edited to remove some extraneous things like extra labels and .cfi_* directives:
    _Z12virtual_callP5Class:
    
    movq (%rdi), %rax
    movq (%rax), %rax
    jmp *%rax

    _Z15nonvirtual_call5Class:
    jmp _ZN5Class3fooEv

    In the first function, it loads the vptr of the object p[i] points to into [i]rax (the instruction), then loads the first entry of the vtable into rax (the second instruction), then jumps to the corresponding function. (The stack frame is already set up with the appropriate information, as the first parameter to virtual_call is still the first parameter to foo.)

    In the second case, there's no such access to the vtable; the call is not made through a pointer or a reference, so the compiler knows for sure what function is going to be called. It can just jump to it.

    Of course there's no guarantee that this optimization will be performed, but as evidenced by the fact that two-out-of-two compilers I tried did it without even being told to do any optimization at all, I'd guess it's pretty reliable.
  • Herr Otto Flick 2013-02-13 06:59
    Meep:
    Rob:
    imgx64:
    TRTWF is the SQL injection.

    Don't forget the closing of the ResultSet, PreparedStatement and Connection that will never happen if executing the statement throws an exception. Did Santosh never hear of finally blocks?


    Better than finally, try-with-resources guarantees the close() method is called:

    try(PreparedStatement ps = conn.createPreparedStatement("...")) {
    
    do stuff
    }


    Anything that's AutoCloseable works, and Closeable objects (like streams) work too.


    RAII and scoping should guarantee that, all a try block does is to squash errors.
  • Evan 2013-02-13 15:11
    Herr Otto Flick:
    RAII and scoping should guarantee that, all a try block does is to squash errors.
    It's a good thing that Java has RAII. Oh wait, it doesn't.

    Also, you should look up what try-with-resources does. It doesn't swallow anything that finally doesn't -- which is nothing.

    Heck, I don't know of a language where try on its own will swallow anything! It's [i]catch[i/] clauses which swallow things. No catch clause, no swallow. (Many languages won't let you have a try with no catch/finally, but conceptually there's no reason why you couldn't.)
  • Jason 2013-03-31 10:20
    For anyone still reading, it looks like Santosh has taken the whole "message passing" thing to heart, and reinvented the Actor framework from whole cloth. Yes, badly, and incorrectly, but maybe the guy's just a budding genius that needs to be shown Akka in Scala.