Even if Gaia’s database containing passwords was compromised, none of the passwords would have been revealed. That’s because Gaia doesn’t store your password. Gaia only stores hashes.
When you create an account with a password, the password never enters the database as-is. Your password is hashed according to an algorithm, and only then stored in a database. When you log in, this so called hash of your input gets compared to the saved hash within Gaia’s database. If these hashes match, you log in to Gaia successfully.
So, let’s see an example of a hash. The old (1992) MD5 hash function is one of many, it takes any input data and creates a 32 character hexadecimal output out of it. So my input of hello world becomes:
5eb63bbbe01eeed093cb22bb8f5acdc3.
So even if you manage to get to see 5eb63bbbe01eeed093cb22bb8f5acdc3 you’re not going to know that my input was hello world.
Hashing is a one-way street in the way that even when you know a hash, you won’t know the input. In this way, hashes are a nice asset because they can be used to verify a password without revealing it. Hash functions are designed to be very difficult to reverse.
Then there is also what we call 'the avalanche effect' of hash functions. In cryptography, the avalanche effect stands for the desirable property of cryptographic algorithms (such as hash functions) wherein if an input is changed only slightly, the output still changes significantly. Mathematically, it benefits from the chaos theory’s butterfly effect.
For example, using the old MD5 hash:
hunter1 = 726ad07bc398372b56a52e3de8693679
hunter2 = 2ab96390c7dbe3439de74d0c9b0b1767
Even though the input is such a close match, the output is vastly different. The output doesn’t provide any grip to figure out the original input.
“But”, the clever one might think, “if the same input always generates the same output, there have to be ways to look it up—just like you showed us ‘hello world’ and ‘hunter1’.” This could be true. There is something called a Rainbow Table Attack. A rainbow table is a pre-generated list of hash inputs to outputs. So you would be able to look up a password input from its hash output, if the passwords did not get a property that was unique to itself.
So, in order to prevent Rainbow Table Attacks passwords are salted. That is, some random data that’s unique for each user/password is added to the password, and thus the hash output. In other words, your hash is composed of your password + a salt.
This completely changes the output of hash functions and eliminates the possibilities of a Rainbow Table Attack. And as the popularity of less secure hashing algorithms has fallen, and as password salting has became a common practice, rainbow tables have already fallen out of common use.
“But”, an even more clever one might think, “because hash functions have an infinite input length but a predefined output length, there is going to be the possibility of two different inputs that produce the same output hash!” That is definitely true. A second type of possible attack is called a Hash Collision Attack. A Hash Collision Attack attempts to find inputs that produce the same hash result. If two separate inputs can produce the same hash output, it is called a collision. This collision can then be exploited when two hashes are compared together–such as where you use your password.
The odds of a collision are, of course, very low. This is especially true for hash functions with very large output sizes. However, as our available computational power increases, the ability to brute-force (go through every possibility) for hash collisions becomes more feasible.
For example, the target hash could be 89232323. The original input that generated this hash was hello. If we brute-force our way to the same output (89232323), our input might be 8571935798325698. So 8571935798325698 generates the same hash as hello. This can be exploited, where if the input hash is checked against the saved output hash in the database, it will be a successful match even though your password hasn’t been guessed.
But this is where the computational power of a hacker meets the increasing strength of hash functions. Yes, hash functions like MD5 and SHA-1 have been shown to not be collision resistant. However, stronger functions such as SHA-256 seem to be safe for the foreseeable future. The amount of time it would take to brute-force a single SHA-256 hash is (currently) much too long even with the most advanced technology available today! We’re looking at the life expectancy of the universe here—so a strong hash function currently eliminates the possibilities of a Hash Collision Attack in our humble lifetimes.
Wait, but if passwords are hashed, then why would Lanzer encourage passwords that are “not based on any dictionary words”?
Not every type of attack looks at the output hash. Asides from Rainbow Table Attacks (eliminated by adding unique data) and Hash Collision Attacks (eliminated by using strong hash functions), there are still successful attacks out there that manage to simply guess your password. This could be as simple as your friend knowing you always use the name of your favorite Pokémon, or as elaborate as a Dictionary Attack. A Dictionary Attack is a common brute-force technique in which a dictionary list of possibilities is checked against your password. These lists often contain things such as words found in an official dictionary. Although I’d like to add to this that they may also contain attempts such as JustinBieber or 123456789!. So in the case of a Dictionary Attack, random passwords like M88%$#@H stand a better chance of protecting your account from intruders.
And why does Lanzer tell us to “create a lengthy password” and “update every year”?
Unfortunately there are also Brute Force Attacks that don’t look at output hashes, plus cycle through every possible character. Even ‘!’ and ‘@’ and such, so that a password such as M88%$#@H isn’t entirely bulletproof. In this case the hash isn’t taken into account, so a lengthier password simply takes longer to crack. Make it long enough, and it might take over a year to crack. Change your password every year in addition, and knock those hackers down completely.
Other Good Practices
- Go to your Gaia account settings and enable IP Verification in the Security list. With IP Verification set up, you will receive a verification link per e-mail whenever Gaia detects that your account is being logged into from a new location. If someone can’t get on your computer and/or into your e-mail, they won’t be able to hijack your account. A small step for you, a huge leap for your security!
- An Omni Mod once said that hacking reports filed by Gaians revealed it to be ‘painfully obvious’ that most Gaia hacks stem from ignorance. This is where the basics apply. Always keep your password to yourself and don’t share your account!
Happy Gaia'ing!
When you create an account with a password, the password never enters the database as-is. Your password is hashed according to an algorithm, and only then stored in a database. When you log in, this so called hash of your input gets compared to the saved hash within Gaia’s database. If these hashes match, you log in to Gaia successfully.
So, let’s see an example of a hash. The old (1992) MD5 hash function is one of many, it takes any input data and creates a 32 character hexadecimal output out of it. So my input of hello world becomes:
5eb63bbbe01eeed093cb22bb8f5acdc3.
So even if you manage to get to see 5eb63bbbe01eeed093cb22bb8f5acdc3 you’re not going to know that my input was hello world.
Hashing is a one-way street in the way that even when you know a hash, you won’t know the input. In this way, hashes are a nice asset because they can be used to verify a password without revealing it. Hash functions are designed to be very difficult to reverse.
Then there is also what we call 'the avalanche effect' of hash functions. In cryptography, the avalanche effect stands for the desirable property of cryptographic algorithms (such as hash functions) wherein if an input is changed only slightly, the output still changes significantly. Mathematically, it benefits from the chaos theory’s butterfly effect.
For example, using the old MD5 hash:
hunter1 = 726ad07bc398372b56a52e3de8693679
hunter2 = 2ab96390c7dbe3439de74d0c9b0b1767
Even though the input is such a close match, the output is vastly different. The output doesn’t provide any grip to figure out the original input.
“But”, the clever one might think, “if the same input always generates the same output, there have to be ways to look it up—just like you showed us ‘hello world’ and ‘hunter1’.” This could be true. There is something called a Rainbow Table Attack. A rainbow table is a pre-generated list of hash inputs to outputs. So you would be able to look up a password input from its hash output, if the passwords did not get a property that was unique to itself.
So, in order to prevent Rainbow Table Attacks passwords are salted. That is, some random data that’s unique for each user/password is added to the password, and thus the hash output. In other words, your hash is composed of your password + a salt.
This completely changes the output of hash functions and eliminates the possibilities of a Rainbow Table Attack. And as the popularity of less secure hashing algorithms has fallen, and as password salting has became a common practice, rainbow tables have already fallen out of common use.
“But”, an even more clever one might think, “because hash functions have an infinite input length but a predefined output length, there is going to be the possibility of two different inputs that produce the same output hash!” That is definitely true. A second type of possible attack is called a Hash Collision Attack. A Hash Collision Attack attempts to find inputs that produce the same hash result. If two separate inputs can produce the same hash output, it is called a collision. This collision can then be exploited when two hashes are compared together–such as where you use your password.
The odds of a collision are, of course, very low. This is especially true for hash functions with very large output sizes. However, as our available computational power increases, the ability to brute-force (go through every possibility) for hash collisions becomes more feasible.
For example, the target hash could be 89232323. The original input that generated this hash was hello. If we brute-force our way to the same output (89232323), our input might be 8571935798325698. So 8571935798325698 generates the same hash as hello. This can be exploited, where if the input hash is checked against the saved output hash in the database, it will be a successful match even though your password hasn’t been guessed.
But this is where the computational power of a hacker meets the increasing strength of hash functions. Yes, hash functions like MD5 and SHA-1 have been shown to not be collision resistant. However, stronger functions such as SHA-256 seem to be safe for the foreseeable future. The amount of time it would take to brute-force a single SHA-256 hash is (currently) much too long even with the most advanced technology available today! We’re looking at the life expectancy of the universe here—so a strong hash function currently eliminates the possibilities of a Hash Collision Attack in our humble lifetimes.
Wait, but if passwords are hashed, then why would Lanzer encourage passwords that are “not based on any dictionary words”?
Not every type of attack looks at the output hash. Asides from Rainbow Table Attacks (eliminated by adding unique data) and Hash Collision Attacks (eliminated by using strong hash functions), there are still successful attacks out there that manage to simply guess your password. This could be as simple as your friend knowing you always use the name of your favorite Pokémon, or as elaborate as a Dictionary Attack. A Dictionary Attack is a common brute-force technique in which a dictionary list of possibilities is checked against your password. These lists often contain things such as words found in an official dictionary. Although I’d like to add to this that they may also contain attempts such as JustinBieber or 123456789!. So in the case of a Dictionary Attack, random passwords like M88%$#@H stand a better chance of protecting your account from intruders.
And why does Lanzer tell us to “create a lengthy password” and “update every year”?
Unfortunately there are also Brute Force Attacks that don’t look at output hashes, plus cycle through every possible character. Even ‘!’ and ‘@’ and such, so that a password such as M88%$#@H isn’t entirely bulletproof. In this case the hash isn’t taken into account, so a lengthier password simply takes longer to crack. Make it long enough, and it might take over a year to crack. Change your password every year in addition, and knock those hackers down completely.
Other Good Practices
- Go to your Gaia account settings and enable IP Verification in the Security list. With IP Verification set up, you will receive a verification link per e-mail whenever Gaia detects that your account is being logged into from a new location. If someone can’t get on your computer and/or into your e-mail, they won’t be able to hijack your account. A small step for you, a huge leap for your security!
- An Omni Mod once said that hacking reports filed by Gaians revealed it to be ‘painfully obvious’ that most Gaia hacks stem from ignorance. This is where the basics apply. Always keep your password to yourself and don’t share your account!
Happy Gaia'ing!