• AJF (unregistered)

    949fbbff46e9c2e59b40ea5e3702634f

  • SMQ (unregistered)

    And since the magic hash check is done AFTER the AlreadyEncrypted check, you don't even need to know the magic PASSWORD, just the magic HASH. At least this check is server-side and not in a .js where any attacker could read it...

  • bvs23bkv33 (unregistered)

    $comment = str_pad( "1", 1, "1");

  • Little Bobby Tables (unregistered)

    But who IS the man?

    Hint: this company is shafted.

  • Björn Tantau (unregistered)

    And even more worse (worsier?) is the huge potential for SQL injection. Even if the username is sanitized somewhere as soon as you set alreadyEncrypted=Y you can let little Bobby Tables go to town with the password "hash".

  • (nodebb)

    Your daily reminder to almost never buy business software from outside vendors. I'm yet to see a decent line of business software in any industry, from any vendor.

  • Andrew (unregistered) in reply to Björn Tantau

    Indeed, a magic hash doesn't matter when you have a straight shot to SQL injection town. I bet the other code was just as bad (more injection possibilities), and the company didn't keep backups, thus their shutdown.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    The superuser hash given is only 31 hex characters long instead of 32. I'm guessing that was just a submission or editing error?

  • LCrawford (unregistered) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    The superuser hash given is only 31 hex characters long

    It was done that way for security purposes, to prevent the application of Rainbow Tables.

  • Brian (unregistered) in reply to Mr. TA
    Mr. TA:
    Your daily reminder to almost never buy business software from outside vendors. I'm yet to see a decent line of business software in any industry, from any vendor.

    Indeed. I was on a project once that involved porting a graphics driver from a well-known GPU vendor to a specialized platform. After seeing that code, it was a long time before I ever bought another GPU from that company.

    And on an unrelated note... TRWTF is old, hackneyed Monty Python references, amirite?

  • (nodebb) in reply to Brian

    Obviously the world isn't black and white. Standard productivity software should be bought, just as things like OS, drivers and other utilities. If you're a small business like a store or a restaurant where the business model is straightforward, yes go ahead and buy/ license the point of sale/ inventory management software/ hardware. However anything beyond that should always be written internally. Internal engineers are just as good/bad as vendor's, but 1) you don't pay for vendor owner's yachts; 2) they do what you tell them to, which is much better than feature request/ custom consultancy model with software vendors.

  • Decius (unregistered)

    I am root"';

  • (nodebb)

    TRWTF here is a cloud-based SaaS "solution" using 1970s ideology. Back in the day, we used to run McCormack and Dodge software. It was "very secure" -- you need a username and password, you need a role and the password for that role, and you get a blank screen with some lines at the top and the bottom for "actions" to take when you hit the ENTER key. The "action" could be to load up a form for enquiry or data entry. You only had access to forms based on your role, and anything you did was tied to your username.

    If you were an on-site support consultant who needed to access everything on the system, you could enter an OP_CODE to log in with God access, because it was hardwired into every installation - with no ties to any username or role in place on the system. And, if you knew somebody who was an on-site support consultant and that person told you the codes, you instantly had God access on any company's software. I knew someone.

    Haven't used McD in 30 years. I still remember the codes, because they were iconic movie characters. And that's scary.

  • Edwin (unregistered) in reply to AJF

    Sweet: frist as md5 hash.

  • James (unregistered) in reply to Little Bobby Tables

    Thanks for the "hint".

  • Olivier (unregistered)

    I don't understand what you mean Remy: They were storing hashes which were what was actually used as the password.

    As MD5 is a hash, as it has no way to return to the original password, if all you store is the hash, all you can check for authentication is the hash.

    And to reply to Björn Tantau, if you agree that the username has been sanitized somewhere earlier, why password would not be? Or at least password when it s provided as a hash?

  • (nodebb) in reply to Olivier

    The point is that if you know the hash of a user's password, you can log in as that user without ever knowing what the original password was (by setting alreadyEncrypted). So the hash is being used as the password, in the sense that the hash is all you need to know to gain access.

  • Little Bobby Tables (unregistered) in reply to Brian

    Old hackneyed Monty Python references are nowhere near as tedious as all those wannabe-comedians who think its the height of intellectual wit and sophistication to scatter their communications with invocations of the number 42.

  • Little Bobby Tables (unregistered) in reply to Little Bobby Tables

    *it's

  • (nodebb) in reply to Decius
    I am groot"';

    FTFY

  • Grey no beard (unregistered) in reply to Mr. TA

    I resent that remark.

    The best piece of code I ever wrote was 1400 lines of IBM Assembler. I designed it based on a CACM article, wrote it out long hand (tells you when this was) and typed it in. Fixed one typo on the compile. Tested and moved it to production.

    Performance of the allocation job moved from ending after the heat death of the universe to merely running a couple hours (the estimated workload was 4 Billion IOs at a time when 100 IOPS was good performance). (Did I mention the other vendor's database was a piece of - um - ofal?)

    Six weeks later I realized I had reversed one test which, while not causing an error, led to less than optimal performance. I made the correction and it sped the process up 10%.

    It ran AT LEAST seven years in production without a failure, which is when I lost contact with the client.

  • dubsdj (unregistered)

    That's why I stick with Microsoft or Amazon as I doubt they will go out of business.

  • Martin (unregistered) in reply to Mr. TA

    You implicate here that your company has developers who actually could do a better job. Implication is probably wrong for 95% of companies. So it still makes sense to buy software.

  • medievalist (unregistered) in reply to Mr. TA

    Standard productivity software is available as open source software, though. It's a much safer route than trusting a vendor never to shut down your service.

    The value proposition was quite a bit different before ubiquitous connectivity; you could buy closed source software that was more polished than open source, and the vendor couldn't nuke it from orbit whenever they felt like it.

  • Rich (unregistered)

    I'm curious as to how the people saying that this is so terrible would go about breaking the security. As someone who doesn't already have access to the data which is being protected, you'd presumably have to try to brute force the hash itself - that's going to be harder than finding the password! Clearly there are issues with hard-coding the magic-hash if the source code itself isn't secured. So as far as I can tell, and I'm sure someone will tell me if I'm wrong, the only WTF here is using unsalted MD5. Not good, but more of an "oh, that needs fixing" than a WTF worthy of shaming on here.

  • Zippity Doo Da (unregistered) in reply to Rich

    The SQL injection is the obvious vulnerability to me, and not even mentioned in the article. But perhaps the username was sanitised earlier in the code.

    Other than that, yeah, safe enough if the source and the database are never leaked (for all we know, the exact same code runs against the Log In code here, and there's no way to probe it). But it's still obviously bad practice in several ways (hard-coded hash, still using md5). Even just having a login impersonation that isn't logged and auditable is poor practice.

    If the database was leaked, the hashed passwords are unsalted and only md5, so they could be rainbow-tabled to find out the plain-text passwords, which is useful for finding password reuse.

Leave a comment on “When the Man's Hash Comes Around”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article