• cm (unregistered)

    MUHAHAHAHAHAHAHAHAHA Unique passwords and Usernames? - And Tell them that they got a correct password but username wrong? HAHAHAHAHAHA

  • Phil Scott (unregistered)

    my coworker just sent me a hopefully defunct sproc that he found that not only accidently uses a cross join, but also creates a temporary table only to do a SELECT * FROM #temp.

    Not quite wtf worthy, but it did provoke a "what in the hell?" Must have come from the "moving the data into a temp table and then scanning the temp table was ultimately faster than directly selecting the row" school of thought.

  • Hassan Voyeau (unregistered)

    Imagine, trying to set your password and being told for the umpteen time that your password has already been taken.

  • Ilya Haykinson (unregistered)

    I can imagine! "Sorry, you cannot set your password to 'password'. It has already been taken by 243 users. Their usernames are: ..."
    :)

  • Ilya Haykinson (unregistered)

    On second thought that would actually imply phasing in password uniqueness via code after some users already got their accounts set up. [smacks self]

  • Hassan Voyeau (unregistered)

    Ilya : 243 users? You can't get 243 if the passwords are unique. But I feel what yuh saying.

  • Hassan Voyeau (unregistered)

    And you have beaten me to the draw...lucky pooch

  • [email protected] (Keith Rome) (unregistered)

    Actually... Mikey's DBA is right. There is (was) an issue with Sybase and writing values to floating-point fields. Coincidentally, this problem also affected SQL Server up until version 6.5. Certain values could be written to the database, and upon retrieval these values would be different. The problem was not actually in the database server however - it was in the CT-LIB/DBlib driver interaction with various development libraries, most notably the Borland BDE. It would erroneously round (sometimes!). We ended up having to use currency datatype (and other hacks) for these fields. So Mikey's issue, while seemingly crazy to most people, is not really a WTF because there is truly a sound basis for it.

    Now on the other hand, the "unique password" bit really does fall into WTF territory...

  • Original Submitter (unregistered)

    As an addendum to the Developer/DBA "Unique Password" WTF: I submitted that particular WTF, and was the Developer. You'll all be happy to know that the DBA was promoted to manager of our team.

  • Derek (unregistered)

    Do I read it right that that last procedure return the same error whether the user name is not found or if the password for that user is incorrect? It seems to me that these should be two separate error messages.

  • Oliver Townshend (unregistered)

    Sybase is still a terrible DB to put floating point numbers into. I went mad a month or two ago trying to get bcp to work on Sybase 12. I'm with the DBA on this one.

  • The Mike (unregistered)

    Well, the procedure could return two distinct error states, that's fine. But the end user should only get a single error - username/password incorrect. Otherwise, this just serves as a mechanism for checking for possible "correct" passwords by feeing in any username I want to make up and a password I'm trying to verify exists for some user.

    This is a very bad idea in systems where hashed passwords could then possibly be retrieved via another mechanism, and then I have a dictionary of known passwords I can just check against the hashed values.

    I'm oversimplifying, but you get the idea - don't reveal any more than you need to.

  • Concerned Citizen (unregistered)

    If the DB returns distinct error messages based on whether a username OR password is incorrect, you've just given Joe Hacker a way to find out what your valid usernames are... Like the original post states, it's a security issue.

  • BradC (unregistered)

    Derek:
    Making distinct error messages makes it easy for people to guess their way into the system.

    bsmith password - "Invalid Username"
    bobs password - "Invalid Username"
    smithb password - "Invalid Password"

    Ok, at least I got the username right. Now to start on the password....

    If you give a generic error for "Invalid Username or Password" then a hacker doesn't gain the above advantage.

  • John Miles (unregistered)

    In fact, I've heard at least one account of an exploited vulnerability in a system that did return the same error for incorrect IDs and passwords. The vulnerability was based on the fact that it took a little longer to reject an invalid password on a valid user ID than it did to reject an invalid ID.


    The attacker in this case was able to compile a list of valid user IDs by recording the attempts that took more than a certain number of milliseconds to return the error.


    Once you have a set of valid user IDs, it's all over, because then you can focus your efforts on trying each against a few variations of the most common password (which, amusingly enough, is "JESUS").

  • Jeremy Morton (unregistered)

    Jesus...

  • Scott Mitchell (unregistered)

    Here's your WTF:

    "I wrote him up a little code that would cycle through every possible 64 bit pattern, cast is as double, write it to the database, read it back, convert to a bit pattern and compare the original and new patterns for discrepancies. Aside from shouting if the patterns mismatched, it also reported progress every million patterns.

    Based on the log, it looked like we'd have to wait a few years for the final result."

    Perhaps he doesn't grasp just how large 2^64 is. If you were running this test for a full year on computers that could perform 3 billion tests per second, you'd need nearly 200 such computers to finish this test within the year. To put it in other terms, having a single computer attempt this computation would take it nearly 200 years to complete. A case where brute force just ain't gonna cut it...

  • RichB (unregistered)

    Unique passwords? Probably yes but it's more a function of the hashing and salting you do to your password prior to entering it in the DB.

  • Nikolay Simeonov (unregistered)

    > You'll all be happy to know that the DBA was promoted to manager of our team. <

    At least this guy knows someething about databases. I had managers who didn't have a clue about database design at all, and definitely nothing about programming. Some were close to the joke, that 2+2*3 should be equal to 12 and this could be proven by any calculator and naturally MS excel is wrong, that's why everyone is bitching about MS products.

    I HAD... phew... ahh what a relief... and I will never ever again work for such a company!

    Cheers :)

  • Andy L. (unregistered)

    If the floating-point test patern wouldn't have completed for some vast period of time, then wouldn't it have made more sense to simply test random floating point numbers? If there was a problem with floating points testing it with a relativly short series of nearly identical numbers would not be a resonable test.

    What if the problem involves storage of bits your program won't twiddle in half a century? 50% of all floats could be corrupt and you wouldn't know until after you retired!

  • fluffy (unregistered)

    Once upon a time I used a mainframe system which was configured to not allow two users to have the same password. But when a bunch of accounts were set up they were all given a default password, and we were told to change the password on our first login.

    Just for the hell of it I tried changing my password back to the default password, and it actually did say "Your password is the same as the following other users:" and gave me a list of all the other accounts which still had that password.

    But that's still not as bad as Microsoft Bob, the only system I've ever seen which says, "Oh, it looks like you've forgotten your password. Would you like to change it?"

  • Original Submitter (unregistered)

    >more a function of the hashing and salting >

    Trust me, to this DBA he would confuse the terms hashing and salting with breakfast.

    I could start a whole new site on this guy alone called ManagementWTF.com

  • Michael (unregistered)

    > Unique passwords? Probably yes

    Salting might given unique passwords given that you'd be using a random salt but there is no reason at all to enforce passwords to be unique.

    Of course the issue of people using the same password for multiple accounts (i.e. network admin uses admin password for his hotmail email password) is another issue...

  • Lothar (unregistered)

    @Original Submitter: dilbert.com already exists

  • smartypants (unregistered)

    I am not one for salting...I prefer peppering.

  • John (unregistered)

    I'm hungry! I could go for an Egg McMuffin!

  • anonymouse (unregistered)

    Hey Michael: Could you please pass the...heh heh heh...just kidding.

  • anonymous developer (unregistered)

    On the floating point bug: sounds to me like the real wtf for the DBA is not fighting more to prove to the developer that there was, in fact, a problem-documentation would have helped. Just because some huge corporation released something doesn't mean there is a potentially major bug in it. I see that all the time...

  • No body (unregistered)

    I once had the joy of maintaining a system in which allowed new users to register, and ensured that the username/password combination was unique. That's right - you could re-use the same username as long as the password was different. The real fun started when you tried to log in, and found that the login procedure assumed that usernames were unique, and it was up to chance whether the account it verified your password against was yours or some other poor sap's.

  • zobbo (unregistered)

    > At least this guy knows someething about databases. I had
    > managers who didn't have a clue about database design at all, and > definitely nothing about programming. Some were close to the
    > joke, that 2+2*3 should be equal to 12 and this could be proven
    > by any calculator and naturally MS excel is wrong, that's why
    > everyone is bitching about MS products.

    Well, they might be smalltalk programmers ;)

  • Chris (unregistered)

    heh... Try =sum((2+2)*3) :P

  • anonymouse (unregistered)

    Word up.

  • (cs) in reply to anonymous developer

    Anonymous:
    On the floating point bug: sounds to me like the real wtf for the DBA is not fighting more to prove to the developer that there was, in fact, a problem-documentation would have helped. Just because some huge corporation released something doesn't mean there is a potentially major bug in it. I see that all the time...

    Well, the real WTF here is that the bug had (presuably) been fixed for some time but this guy continued to assume that it existed.  I've known developers with the same syndrome.  For example:  "Avoid CString at all costs, because it thrashes memory".  Yes, it did...  in MFC 1.0.  So instead they write some horribly convoluted code that thrashes memory just as bad as CString used to, but also has some hidden bug in it that they then copy-and-paste throughout their code because they don't grasp the fundamentals of OOP.

  • HHH (unregistered) in reply to smartypants

    I prefer currying :)

Leave a comment on “Nov-05: Official DBA Appreciation Day”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article