• Hank Miller (unregistered)

    I can't even refactor this to use API, because I can just see the save configuration looking something like:


    Public Sub GetConfiguration()

    output #1, [cOnFiG]
    output #1, "diRsssys" + sSysDir
    ...
    output #1, "userNam=" + UserName
    output #1, "Obsecured" + Password
    close #1

    Which would work just fine for that parser, but fail completely on anything more intelligent.   Though storing password in a field Obsecured at least means it isn't obviouse that the random string there is a password - assuming good passwords are used, and you don't know what the password is anyway.

    I don't know VB6, but I think you get the idea.   No need to open the file first because it was already open (I'm assuming #1 becomes a global somehow).  The function must be called GetConfiguration.


  • (cs) in reply to nummhead

    Anonymous:
    other interesting goofups:

    UserName = Mid(sLineData, 8)

    if this line starts like "UserName=", then he's getting the equal sign too

    Actually it's even worse than that. The Mid() function takes as the second parameter the starting point of what to grab. This means to start at character #8, reading in that one and the rest of the string. So an INI entry of:

    UserName=myname

    will actually get you:

    "e=myname"

    But since this code is in production, he probably does something like calling that INI field "UsrNam", because that's easily readable and searchable. Dumbass.

  • (cs) in reply to ammoQ
    ammoQ:
    Well, at least it's fast. If the ini file is, for some reason yet to explain, 1.3 GB large, you will definitely notice that this solution is much faster than the API calls. For a ini file containing n entries, the complexity of this solution is o(n), while API calls are probably o(n^2).


    If you had a solution written that needed a 1.3GB INI file, I think you would be a candidate for WTF right there on that basis alone.
  • (cs) in reply to ammoQ

    ammoQ:
    Well, at least it's fast. If the ini file is, for some reason yet to explain, 1.3 GB large, you will definitely notice that this solution is much faster than the API calls. For a ini file containing n entries, the complexity of this solution is o(n), while API calls are probably o(n^2).

    So, if the file contains 100,000 lines, and the first 3 are the ones needed by this routine, guess what: it reads them ALL.  I don't think I'd call that particularly fast!  On top of that, you can add in the fact that is never releases resources for the file.

    Comparing the efficiency of this "solution" to an unknown API call is ridiculous; you need to compare it to well-written code.  

    Not using API calls is not in any way a WTF -- it's writing crappy code.  We've all "reinvented the wheel" now and again; no one knows the contents of every library available.  I'd take a programmer who can write a small, efficient routine to parse an INI file over of a guy who has memorized the entire windows API but writes crappy spaghetti code any day of the week.

  • (cs) in reply to Jeff S
    Jeff S:
    Not using API calls is not in any way a WTF -- it's writing crappy code.  We've all "reinvented the wheel" now and again; no one knows the contents of every library available.  I'd take a programmer who can write a small, efficient routine to parse an INI file over of a guy who has memorized the entire windows API but writes crappy spaghetti code any day of the week.

    I agree: the main WTF is that his wheel came out square after he reinvented it.

    That said, I do think it's a developer's responsibility to know what facilities are afforded by available libs and APIs. Those have been debugged and (probably) optimized. Rewriting that functionality means more code to debug & maintain. No, a developer doesn't need to know every API function, but at some point, a good programmer thinks "hmm...there's gotta be a better way to do this...Windows does it itself, so..."
  • fgilcher (unregistered) in reply to John Smallberries
    John Smallberries:
    Anonymous:
    christoofar:
    Anonymous:
    I like the fact that the password is stored in plain text in an ini file.  Security is for chumps anyway.


    ...who knows, maybe it is stored encrypted?  But; given the code block I just saw here, chances are likely that no such precautions like this would have been used unless the application folder is living inside the user's profile, which at least would preclude other non-admins from reading the INI thanks to NTFS permissions.



    Sometimes storing the password in plain text is the better option. You need the plaintext password if you want to implement some sort of challenge-handshake authentication.

    regards
    fg

    Are you serious?
    Wouldn't you just use a hash of the password instead of the cleartext?


    No you can't. CHAP works this way:
    The client and the server both know the password and must exchange it over a potentially insecure line (e.g.: internet). So the server sends a random token to the client, the client encrypts the token with the password and sends it back to the server. The server encrypts the same token with the users password and compares the values. If they match, everything is fine and the user is authenticated. 
    The key part here is: the server (as well as the client) needs the plaintext password (or a reversable encryption[1])  to encrypt the token. So you're trading the enhanced security in trasmitting the password against a reduced security on the server itself.

    [1] a reversable encryption does in this case only obfuscate the password as the key to encrypt the password must be either hardcoded in the server application or stored in plaintext somewhere. Never versions of windows support some sort of encryption based on the user login or something similar.
     
    regards
    fg


  • fgilcher (unregistered) in reply to fgilcher

    just a minor correction before anyone jumps on it: the challenge is not encrypted with the passwort, but the password and the token together a encrypted with a one way hash.  But the effect stays the same: you need the plaintext password.

    regards
    fg

  • (cs) in reply to ammoQ

    ammoQ:
    Well, at least it's fast. If the ini file is, for some reason yet to explain, 1.3 GB large, you will definitely notice that this solution is much faster than the API calls. For a ini file containing n entries, the complexity of this solution is o(n), while API calls are probably o(n^2).

    Ok, I've been holding off on admitting this, but since you mentioned it, I now have to expose myself to potential ridicule...

    About 4 years ago, I wrote a class library to read/write files in the .INI file format, simply because the API calls were too slow. I'm not sure what mechanism the API uses, but I'm guessing it scans the file from the beginning until the required item is located, and then stops. If the file is not cached in some way (which is unlikely, given the poor performance I noticed), then each subsequent call to GetPrivateProfileString will rescan the file from the beginning. Futhermore, the API cannot read INI files larger than 64k (at least, NT 4 can't), so I needed a different mechanism anyway.

    The data I was storing could potentially have more than 8000 numbered elements in one section, which (conveniently) could be read in sequentially. It was basically a memory map for a user-configurable hardware device, with each entry representing a memory location, and the properties of that location. (eg, analog/digital, input/output etc)

    Anyway, the class I wrote had some overloaded methods to either read a section into an array or a property bag, in one pass. The caller could then process the data however it wanted. The actual file format details were abstracted away behind the class interface.

    There are good things and bad things about using the INI format, but the best was the human-readable data format that could be debugged/edited with notepad. With hindsight, it should probably have been XML, but INI was good enough at the time.

    Of course, none of this in any way excuses the rest of the WTF-ery from the submitted code - I just thought I'd share a nice story about re-implementing parts of the API, instead of using the proper tools (ie:XML or a small database) :)

  • (cs) in reply to fgilcher
    Anonymous:
    No you can't. CHAP works this way:
    The client and the server both know the password and must exchange it over a potentially insecure line (e.g.: internet). So the server sends a random token to the client, the client encrypts the token with the password and sends it back to the server. The server encrypts the same token with the users password and compares the values. If they match, everything is fine and the user is authenticated. 
    The key part here is: the server (as well as the client) needs the plaintext password (or a reversable encryption[1])  to encrypt the token. So you're trading the enhanced security in trasmitting the password against a reduced security on the server itself.

    I have to disagree.
    The same key must be used to encrypt the token, but it needn't be the cleartext password. If the server stores the hashed password, and the client also hashes the password, those hashes can be used as the key. No cleartext is stored anywhere (it's only typed in by the user), and no passwords or hashes are transmitted.
  • Raxxerax (unregistered) in reply to John Smallberries
    John Smallberries:

    If the server stores the hashed password, and the client also hashes the password, those hashes can be used as the key.


    And this makes a difference how?  Anyone with access to the INI can still pull the hash out and make use of it.  I fail to see how storing only the hash provides any increased security if the INI is compromised.
  • (cs) in reply to Jeff S
    Jeff S:

    ammoQ:
    Well, at least it's fast. If the ini file is, for some reason yet to explain, 1.3 GB large, you will definitely notice that this solution is much faster than the API calls. For a ini file containing n entries, the complexity of this solution is o(n), while API calls are probably o(n^2).

    So, if the file contains 100,000 lines, and the first 3 are the ones needed by this routine, guess what: it reads them ALL.  I don't think I'd call that particularly fast!  On top of that, you can add in the fact that is never releases resources for the file.

    Comparing the efficiency of this "solution" to an unknown API call is ridiculous; you need to compare it to well-written code.  

    Not using API calls is not in any way a WTF -- it's writing crappy code.  We've all "reinvented the wheel" now and again; no one knows the contents of every library available.  I'd take a programmer who can write a small, efficient routine to parse an INI file over of a guy who has memorized the entire windows API but writes crappy spaghetti code any day of the week.



    You are right, reading through the whole file even when after it reads what it needs is bad for the performance. My comparison (not entirely serious, of course) was based on (IMO reasonable) assumption that the API call does no caching.
    Not releasing the resources for the file doesn't make the program slower; one might even argue that closing the file costs another 0.0003 ms ;-)

    But my posting was based on a serious experience: Several years ago, I had to clean up a WTF left by other subcontractors. Their task was to make a program that prints documents; the program got its task in a database table that told it what to print. For no obvious reason (probably because of their team structure), this program was split into two rather loosely coupled parts: one part read the necessary data from the the database and wrote it into a .ini-style file; the other part read this file and did the actual printing. Reading the ini file was done by a straight-forward-style function: open the file and read till the requested entry is found. (This was done on Unix, so don't complain about not using the Windows API). For most documents, it worked reasonably well. This was because the documents were rather small, say 30 fields to print. Creating the print output took less than 1 second. But every now and then, there was a big document with est. 1500 fields to print. Because of the o(n^2) complexity of the program as it was written, it took up to 10 minutes to create the print output for this large documents! After replacing this idiotic ini-file by a far more appropriate hash table, the time to process a large document was about 5 secs.
  • (cs) in reply to Raxxerax
    Anonymous:
    John Smallberries:

    If the server stores the hashed password, and the client also hashes the password, those hashes can be used as the key.


    And this makes a difference how?  Anyone with access to the INI can still pull the hash out and make use of it.  I fail to see how storing only the hash provides any increased security if the INI is compromised.


    The only obvious advantage is that the attacker doesn't get the plaintext password. This is especially important if the same password is used for several servers (a bit of a WTF, but nonetheless common practice)
  • fgilcher (unregistered) in reply to ammoQ
    ammoQ:
    Anonymous:
    John Smallberries:

    If the server stores the hashed password, and the client also hashes the password, those hashes can be used as the key.


    And this makes a difference how?  Anyone with access to the INI can still pull the hash out and make use of it.  I fail to see how storing only the hash provides any increased security if the INI is compromised.


    The only obvious advantage is that the attacker doesn't get the plaintext password. This is especially important if the same password is used for several servers (a bit of a WTF, but nonetheless common practice)


    Where's the point? We'd soon be in the situation that all servers take the hash of the password as a secret an so I don't need the password any more - the hash itself will be sufficient. It won't be possible that one server doing chap authentication accepts the md5 hash as secret, another server accepts the password as secret and the third one accepts sha1. There might be some old legacy app that requires a client to send an md4 hash... No good way to go IMHO.

    regards
    fg

  • Paul (unregistered) in reply to John Smallberries
    John Smallberries:
    Anonymous:
    Consultants do not code in VB - they use real programming languages. So stop insulting us consultants ....    Oh yes and consultants forced with a gun to the head to use VB, can still read help files.  This person is not a consultant .....

    Yeah, right.
    Consultants are whores who will code in any language the client wants.
    I used to be a consultant and got out 'cuz I was sick and tired of writing shitty systems just to maximize billings.


    And I take exception to this. I'm a consultant, and write professional systems, and still maximize billings. And I don't use VB because everything else is better.

    I refuse to sacrifice my morals, simply because of the MS Marketing dollar.

    That being said, the hoops that I get my systems to jump through are pretty intense, but they're exactly what the customer wants, and so they pay for my code to jump. In that sense I'll agree that I'm a whore.
  • (cs) in reply to Paul
    Anonymous:
    John Smallberries:
    Anonymous:
    Consultants do not code in VB - they use real programming languages. So stop insulting us consultants ....    Oh yes and consultants forced with a gun to the head to use VB, can still read help files.  This person is not a consultant .....

    Yeah, right.
    Consultants are whores who will code in any language the client wants.
    I used to be a consultant and got out 'cuz I was sick and tired of writing shitty systems just to maximize billings.


    And I take exception to this. I'm a consultant, and write professional systems, and still maximize billings. And I don't use VB because everything else is better.

    I refuse to sacrifice my morals, simply because of the MS Marketing dollar.

    That being said, the hoops that I get my systems to jump through are pretty intense, but they're exactly what the customer wants, and so they pay for my code to jump. In that sense I'll agree that I'm a whore.


    Well, here's a question then.  What do you do when the customer comes to you and says that they want a system built, and if it's not built in VB then they don't want it?
  • (cs) in reply to JThelen
    JThelen:
    Anonymous:
    John Smallberries:
    Anonymous:
    Consultants do not code in VB - they use real programming languages. So stop insulting us consultants ....    Oh yes and consultants forced with a gun to the head to use VB, can still read help files.  This person is not a consultant .....

    Yeah, right.
    Consultants are whores who will code in any language the client wants.
    I used to be a consultant and got out 'cuz I was sick and tired of writing shitty systems just to maximize billings.


    And I take exception to this. I'm a consultant, and write professional systems, and still maximize billings. And I don't use VB because everything else is better.

    I refuse to sacrifice my morals, simply because of the MS Marketing dollar.

    That being said, the hoops that I get my systems to jump through are pretty intense, but they're exactly what the customer wants, and so they pay for my code to jump. In that sense I'll agree that I'm a whore.


    Well, here's a question then.  What do you do when the customer comes to you and says that they want a system built, and if it's not built in VB then they don't want it?


    I would ask them why the f*ck it matters to them, as the langauge their system is built in shouldn't make one sh!t's worth of difference to them as long as the system meets their requirements.  If one of their actual requirements is that it be built in VB for some reason that I can't comprehend at the moment, I'd take a look at their other requirements; if I felt that VB combined with my knowledge of it could be used to meet those requirements adequately, I'd say, "Sign me up."

    I fail to see how using the language that a client would like you to use is sufficient to be classified as a "whore."  I must have missed when choosing a language became some sort of pseudo-moral/ethical descision.
  • (cs) in reply to UncleMidriff
    UncleMidriff:
    JThelen:



    Well, here's a question then.  What do you do when the customer comes to you and says that they want a system built, and if it's not built in VB then they don't want it?


    I would ask them why the f*ck it matters to them, as the langauge their system is built in shouldn't make one sh!t's worth of difference to them as long as the system meets their requirements.  If one of their actual requirements is that it be built in VB for some reason that I can't comprehend at the moment, I'd take a look at their other requirements; if I felt that VB combined with my knowledge of it could be used to meet those requirements adequately, I'd say, "Sign me up."

    I fail to see how using the language that a client would like you to use is sufficient to be classified as a "whore."  I must have missed when choosing a language became some sort of pseudo-moral/ethical descision.


    In regards to what it matters, we'll say that the project has already been baselined, designed, etc and it's being done in VB.  There are usually other issues, but since this seems to be the matter at hand, that should be sufficient.

    As to attempting to rewrite in another language because you don't comprehend their requirements, I personally don't understand that.  As a contractor, you're brought in to add expertise to a development team, not understand the workings of upper management and their decisions for architecture and design;  at least that's how it works where I'm at.

    Now, with all that said and done, I don't like VB.  I personally hate it with every fibre of my being.  as for language choice, it's not a pseudo moral/ethical thing, not to my knowledge anyway.
  • WWWWolf (unregistered)

    The first time I saw that code, I thought this was just some horror from my verrrrry early Spectravideo SVI-318 programs that had come back to haunt me or something... g

    Microsoft BASIC! Rotting brains since the golden eighties! Everlasting, unchanging, now and evermore! Bow before it and despair!

  • (cs) in reply to JThelen
    JThelen:

    UncleMidriff:


    I would ask them why the f*ck it matters to them, as the langauge their system is built in shouldn't make one sh!t's worth of difference to them as long as the system meets their requirements.  If one of their actual requirements is that it be built in VB for some reason that I can't comprehend at the moment, I'd take a look at their other requirements; if I felt that VB combined with my knowledge of it could be used to meet those requirements adequately, I'd say, "Sign me up."

    I fail to see how using the language that a client would like you to use is sufficient to be classified as a "whore."  I must have missed when choosing a language became some sort of pseudo-moral/ethical descision.


    In regards to what it matters, we'll say that the project has already been baselined, designed, etc and it's being done in VB.  There are usually other issues, but since this seems to be the matter at hand, that should be sufficient.



    That makes sense.  The reason why it seems so difficult for me to imagine that a client would care what language in which their system is built is because most of the clients I've dealt with wouldn't know a computer programming langauge from a fruitfly and thus should have no preference.


    JThelen:

    As to attempting to rewrite in another language because you don't comprehend their requirements, I personally don't understand that.  As a contractor, you're brought in to add expertise to a development team, not understand the workings of upper management and their decisions for architecture and design;  at least that's how it works where I'm at.


    Hmmm...perhaps I should word my thoughts better.  What I meant was I could not comprehend why a client would have a preference as to what langauge was used to build their system, so long as the final product meets their requirements*.  Regardless, if they do indeed have a requirement that their system be built using VB, I would take a long, hard look at all of their requirements for the system, then I would take a long, hard look at my proficiency in using VB.  Then, if I felt that VB was a suitable langauge for their system and that I was skilled enough in using VB to build their system, I would agree to do the work.  Otherwise, I would politely tell them why I thought VB might be a bad choice, and if they weren't willing to strike that requirement, I would politely tell them that I was not the man for their job.

    *Of course, I can comprehend such a situation now, thanks to your post.  :)

    JThelen:

    Now, with all that said and done, I don't like VB.  I personally hate it with every fibre of my being.  as for language choice, it's not a pseudo moral/ethical thing, not to my knowledge anyway.


    Yeah, sorry, I should have made it more clear that that wasn't directed at you.  As for myself, I'm fairly language neutral, though the applications I've been maintaining lately are VB applications.
  • (cs)

    Alex Papadimoulis:

      Open App.Path + "\appconfig.ini" For Input As #1

    This is always one of my favourites as install this sucker to c:\ and you'll have all sorts of fun trying to find that file!

    FileSystemObject.BuildPath anyone?

  • (cs) in reply to UncleMidriff
    UncleMidriff:


    That makes sense.  The reason why it seems so difficult for me to imagine that a client would care what language in which their system is built is because most of the clients I've dealt with wouldn't know a computer programming langauge from a fruitfly and thus should have no preference.



    I can see how that would run with most places, but I'm stationed at one of the so-called 'Sun Java Centers of Excellence' so unless it's a legacy app, everything is Java, regardless of actual suitability.  I'm not saying it's a good thing or a bad thing;  it's simply the way it is and customers expect it to be that way.  There are other places which are similarly infused with VB, C, C++ and so on. 

Leave a comment on “Configuration According to Consultants”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article