Darth Hater

And a little more context: http://en.wikipedia.org/wiki/Password_cracking Since none of these articles make it particularly clear, here's the tl;dr summary (sort of).

When you implement an authentication system, the easiest (read: naive) way to go is to store the username and password paired together in some data sink (usually a database). Under this scheme, it's very easy to implement a login system. The procedure is basically to get the username and password from a user somehow (e.g. from an HTML form), look in the database for the entry which corresponds to the given username and compare the stored password to the user-supplied one. If they match, then it's an auth success. Otherwise, authentication failed.

There's a really serious problem with this though: all your passwords are just sitting in the database for anyone to find. Of course, your database server is probably protected, but no security is perfect. Hackers aren't the only concern either, a single disgruntled employee could wreak havoc under this scheme. The root of the problem is that anyone with access to the database can just read off the complete authentication information for *any* user and then enter that information into the login system, masquerading as said user. You could of course encrypt the passwords (e.g. using AES or similar), but such reversible encryption is really only a paper door in this case. All a would-be attacker needs to do is discover the encryption key and they're home free (this is particularly problematic in the disgruntled employee case).

The solution is to store the passwords in such a way that obtaining the stored data doesn't enable login. In other words, if an attacker obtains the username/password of a particular user from the databse, they shouldn't be able to simply enter that data into the login system and masquerade as that user. Additionally, they shouldn't be able to run any sort of analysis (e.g. decryption) on the password data to obtain a login-able password. This is what hashing gives you.

Hash algorithms are actually quite simple (in principle). All they do is convert one number (in this case, a string of characters representing a password) into another number. What makes this a useful technique is there are more numbers that the hash function maps *from* than there are numbers that the hash function maps *to*. (translation: there are more possible passwords than there are possible hash values) Thus, if an attacker obtains hash value 42, they don't know if that maps to password "chunkylover" or password "cafebabe". Even the authentication system can't "decrypt" the password since the hash value doesn't contain enough information to figure out what the original plain-text password was. The beauty is that the authentication system doesn't *need* to decrypt the password. When a user attempts to login, the auth system simply takes the plain-text password supplied by the user and compares *that* value to the password stored in the database.

The magic of SHA-1 (and all serious hash algorithms) is that they run very, *very* slowly and they are mathematically very difficult to reverse. So, if I gave you hash value "3641c55376f9cfd57961457765acd9ffe2a850ed" (which is actually a SHA-1 hash), it is mathematically impossible for you to figure out even *one* of the infinite string values which could correspond to that hash. Or rather, it's impossible for you to discover that string value in anything less than a geological time scale. The reason for this stems from the fact that some mathematics are just fundamentally very, very hard and requires a long time to compute, even if you somehow merged all of the computers on the planet.

An easy (and actually representative) example of this is factoring. Let's say that I picked two prime numbers, say 7 and 23, and then multiplied them together. The result is of course 161. Now let's say that I gave you *that* number (161) and asked you to figure out which two primes I started with. How long do you suppose it would take you? (this is, incidentally, how SSL (https://) works) It turns out that even a computer isn't able to solve this problem quickly. While it is *very* easy to just pick two primes and multiply them together, it's not so easy to go the other direction and pick out the prime factors. The best algorithm we have currently to solve this problem literally tries multiplying primes almost at random. This wouldn't require too many attempts to find 161, but you can imagine that a much larger number - one with say, a *thousand* digits - would probably require a bit more effort.

So, if we combine all of this together, we start seeing the beginnings of real security. Even if an attacker gains all of the username/password-hash combinations in our database, they still would need to try a massive number of strings at random in order to figure out what plain-text values correspond to the password hashes. As mentioned, this could take a very, *very* long time. Rainbow tables (basically, pre-computed hash values) can make this process faster, but they're pretty easy to defeat with techniques like salting.

Sony's problem was that they were using MD5 and *not* salting. This is an issue for two reasons. First, MD5 is a very fast hash algorithm (that's bad), so it's actually possible for someone with enough computing power to try a few billion plain-text passwords to figure out what corresponds to a particular hash. There are also a lot of rainbow tables available for MD5. The fact that Sony wasn't salting simply made this process a lot easier. It's not quite as bad as storing plain-text passwords, but it's still very much a rookie security mistake.

In reference to Sith classes sharing the same ships, one thread on the DH forums has some speculation from last year's E3 reveals. I started the reply concerning this topic and got a few replies concerning it as well. From the start, I thought it was apparent that Bioware was going to have the same ship for the Sith classes and likewise for the Jedi classes.

http://darthhater.com/forum/topic/6/page/9

What's with the beeps over curse words? Lame

I appreciate that they do that. Especially since my family listens with me. Foul language is unprofessional and innapropriate. Some have said that it is a sign of a lack of intelligence since they couldn't think of a more appropriate word.

@8:25.
I personally believe they were holding off on the video reveals because they hadn't found a good place for the two classes yet. It was only just a short time ago that they made the final tweaks to JC's and SI's that gave them the true feel that they have now with the two advanced classes (namely their capacity to exist in any zone of the trinity). Clearly the class must have felt incomplete for a while, and so they simply couldn't have been releasing class videos about such complex classes like they could with classes like the smuggler, who's concept has remained consistent since very early in design. The smuggler video was great, but it was mostly filled with things we already knew about the smuggler class. Rolling into cover, shooting off some shots, a little stealth here, maybe? Pretty expected stuff. The newer videos are really showing more about the classes and I think as they're getting to this stage in development it was important that their class videos are showing information about the classes as Bioware wants them to be at release. With an ever changing concept that they are FINALLY happy with, they probably now felt comfortable releasing videos, even if they are last.

Worth noting that there was an interview right after they first announced player ships (can't find the link right now) where they confirmed straight-up that the two Jedi classes (as well as the two Sith classes) would share a ship. So, we've known that one for a while.

So as far as Khem Val...(vessel for the master)...could it be possible that Somehow Tulak Hord is the emperor and that Khem Val is working for him? Or if Khem Val has orders left over to carry out for him still? He can be a vessel for him by doing his bidding. Unwilling servant could be that he is bound to Khem Val and so he is not always willing to do your bidding. (story-wise)

Thanks so much guys for catching up the Q&A Qs, and for answering mine.

AC respecs with some kind of "huge cost" is something I like. I see the point that because each class now has so many roles that with some easy "click here to respec" dual spec kind of thing will just make everyone a hybrid. The problem with some large cooldown on it kinda defeats the purpose of the idea. Sure if I respec to Shadow from Sage(Wizard) for some pvp fun, seems great on the surface. But oh shit, I need to respec again to heal for my raid tomorrow.. but the cooldown is kinda big, or the cost is super huge, or I need the stone of 1000 truths to respec each time and they cost 8 billion credits.... and so on, so I either miss the raid, or miss out on my stealthing fun.

My fear is I guess that.. I'd hate to be stuck with an advanced class that gets nerfed or.. that I don't really enjoy. Then I'd feel like.. "oh well, if only at level 10 I made the other choice".

I'm pretty sure the smoke/walk thing is the meditation/recharge for SI remember in The Phantom Menace when Qui-Gon fights Darth Mual and they get separated by the shields?
Qui-Gon meditates and Maul walks back and forth preying upon Qui-Gon.
The animation is EXACTLY the same.

Addons in wow comments:

Yeah so.. I played at release and by the time I was in Westfall I had the "Cosmos" addon pack, simply because it unlocked so many options. Stupid stuff like being able to move frames? Not an option in the wow UI. Molten Core/Onyxia etc, CT Raid was required for healers. Stuff was just impossible on the default Raid Frames (I played holy priest). Healing, dispelling and stupid stuff like a range tracker etc.. Impossible on the default Raid Frames (Which have only just been completely redone, very recently, 6 years down the line) CT Raid actually had the "auto dispel" keybind which just dispelled a debuff on any raid member who had one when you spammed the key. That was removed because it automated play. That trend has continued throughout wow. There must be dozens of addons made which have caused blizzard to remove functionality from the addon framework because they felt the addons went too far. Is that a good situation to be in? Is the Bioware plan perhaps to rationalise and plan for what niche they see addons filling before they let the community loose making stuff?

In TBC I played a shadow priest, and it was impossible to dps as a dot class even then without an addon to track your dots for you and tell you when you needed to refresh them.

Even in Wrath, and to this day, I play a DK. Rune mod and disease tracker is still pretty required to play the class properly. Is it a good situation when the an addon is *required* to play the game properly? I'd have to say that the difference between a default UI DK and a DK who uses a rune/disease mod is probably something like 10-20% effectiveness. I think that is the point at which you have to say; your game's UI is not good enough. An addon isn't an addon unless its optional. A required addon is a bugfix. A community bugfix for a developers crappy UI.