Sign in / up

back to article Zombie apocalypse survivors frozen in terror by hacker raid

Controversial online zombie-blasting video game The War Z is on pause after hackers raided its forum and its database of players. Publisher OP Productions has advised survivors - what it calls its 600,000 or so gamers - to change their passwords: the as-yet unidentified infiltrators of its computer systems accessed players' …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Combustable Lemon
    FAIL

    sigh

    I had a beta account for this game, good job it used a unique password etc.

    I've not even touched it since it was "released". This whole game is just a failure that keeps on giving.

    0 0
  2. Anonymous Coward
    Anonymous Coward

    The line on their website that says "the passwords are encrypted but simple ones may be brute forced (sic)" kind of implies they are using only simple hashing and no salting.

    0 1
    1. DrXym
      Reply Icon

      Not necessarily. Even salted passwords can be be bruteforced. Give me a large database and I could probably extract dozens or hundreds of passwords just by running the 1000 most common passwords over every salted hash.

      What the salt does is stop me from doing a reverse lookup, or knowing easily that two accounts share the same password. Therefore a salt acts as a timesink rather than an impenetrable shield against attackers. This is also why many databases also use deliberately slow hashing algorithms such as bcrypt to further slow down the attacker.

      That said, I would not be surprised if War Z did have shoddy security. Everything else about it is shoddy.

      6 0
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        If you combine your salt and hash, with a little obfuscation you can get a password which is unable to be brute forced, unless you know the method to retrieve the salt. Which is why you shouldn't make your salt easy to get hold of. It's not perfect but when you consider a password breach really is a matter of time, once your user table has gone walkies, it gives you some more.

        0 0
        1. DrXym
          Reply Icon

          The salt has to be stored somewhere and common practice is to put it in the same database as the hash. The reason for this is that anywhere that needs the hash probably needs the salt too. e.g. if I type a plaintext password then in order to verify the plaintext is correct, the code must munge the salt into it, hash it up and do a comparison to the hash in the db. If they're the same, the password matches the one on record.

          If the attacker has the db, then basically they can crack anything in it with time but the increased complexity probably means they'll just go for the low hanging fruit and discard the rest.

          But just because the salt and hash are in the db doesn't mean the user's other credentials need be. For example perhaps the email address is in another database. Perhaps the password validation is a service running on a separate machine behind a firewall where all it ever knows of who the password belongs to is a token. If so there is no easy way to associate hash, salt and user id without owning both databases and knowing how the token was generated. In addition, perhaps the manner of applying the salt is non trivial (e.g. xor'ing half the salt to the password and appending the rest) so that the attacker would need the code for the service in addition to the database.

          But we're talking about War Z where even the salting is in doubt and crackers walked off with their database. These are not security competent people.

          0 0
          1. Anonymous Coward
            Reply Icon
            Anonymous Coward

            I'd not really considered running the password system as a service before actually. At the moment I store my salt within my resultant hash, with a method to retrieve it. It also has a slightly over convoluted system which allows you to expire methods of hashing the password, and converting the old hash to a new one.

            As I say, the reason I store it in this way is not every hack is going to get access to the code and maybe just a single database. Whilst WarZ might have more complex multi database systems in a single database environment, I feel that adding that layer that does make brute forcing even basic passwords extremely difficult without the code, even for the low hanging fruit passwords.

            Don't worry, I'm under no illusion that storing the salt within the hash, even obfuscated is 'secure'. It's not, but it just adds some time delay in, and maybe make it more trouble than it's worth to bother with.

            0 0
  3. ecofeco Silver badge
    Trollface

    Another one bites the dust

    What was that about that cloud thingy?

    0 0
This topic is closed for new posts.