• (cs) in reply to Andy
    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 (unregistered) in reply to Steve The Cynic
    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 (unregistered) in reply to Rob
    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 (unregistered) in reply to Remy Porter
    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 (unregistered) in reply to beginner_
    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.
  • (cs) in reply to Sam
    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.

  • (cs) in reply to Curtis P
    Curtis P:
    I prefer umber hulks.
    I prefer burnt umber hulks... Fireball FTW!
  • Anon (unregistered) in reply to Swedish tard
    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.

  • (cs) in reply to Swedish tard
    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.

  • (cs) in reply to Anon
    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 (unregistered) in reply to Sam The Student
    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 (unregistered)

    I tried it. It works on my machine.

  • fjf (unregistered) in reply to snoofle
    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.

  • (cs) in reply to snoofle
    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 (unregistered) in reply to Remy Porter

    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 (unregistered) in reply to jay
    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 (unregistered) in reply to Steve The Cynic
    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

  • (cs) in reply to The Crunger
    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 (unregistered) in reply to jay
    "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.

  • (cs) in reply to snoofle
    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 (unregistered) in reply to HowItWorks

    Totally agree. I'm supposed to be the c# expert on my team. It makes me want to cry.

  • Gunslinger (unregistered) in reply to Peter
    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.

  • (cs) in reply to Andy
    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 (unregistered) in reply to The Crunger
    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 (unregistered) in reply to Meep
    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 (unregistered) in reply to Herr Otto Flick
    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 (unregistered) in reply to Gibbon1

    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.

Leave a comment on “Encapsulation in the Hot Seat”

Log In or post as a guest

Replying to comment #:

« Return to Article