Support area updated to improve security

[Jeremy Collake]

After the string of site breaches at LinkedIn and eHarmony, I decided to increase the security of secure hashes/digests. These are mathemtically irreversible representations of your plaintext password. In other words, password 'test' is stored as 'ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff', in the case of unsalted SHA2-512. There is no way for even us to know what your original password was, although attack methods such as brute force and rainbow tables are always a threat against any secure hash. Of course, the attacker would first have to compromise the site and obtain the database.

When you login and enter 'test', the computation is made again and compared to see if it matches. If it does, then it is the correct password. If not, then the login fails.

For more information on digests, check Bitsum's nifty computational tool at Calculate MD5, SHA1, SHA2, RIPEMD, and other secure hashes.

This is a REALLY simplistic explanation of things, and I don't want to go into collision probabilities, rainbow tables, salting, or brute force attacks against hashes. That's another discussion. I just wanted you to know that we take storage of your password hash seriously.

General rules are:

1. Do NOT use a short password.
2. Do NOT use a word in the dictionary, or a variation of a word in the dictionary.
3. The more complex and long the password, the better.

[nikkil]

Hi. Quick question, this applies to all versions being used, correct?

[BenYeeHua]

3. The more complex and long the password, the better.

Ya, like !@# and ABC will better, but not too long, like hotmail/outlook, they don't remember it after 16 words if I remember right.

[Jeremy Collake]

This isn't really applicable to anything users need to care about. It was me bragging about my clever solution to strengthen existing secure digests without resetting passwords.

[BenYeeHua]

This isn't really applicable to anything users need to care about. It was me bragging about my clever solution to strengthen existing secure digests without resetting passwords.

Yup, I wanna to know.
If there are 100+ people are log-in in the same time, did the calculation will make the CPU fully used?

[Jeremy Collake]

I doubt it . There are never 100 people logging in *simultaneously* anyway. They are normally spread out by a few seconds at least. The server is a cloud server on a quad core system  that allows CPU bursting, and I never see a high CPU load (not oversold), so it should be fine. The database is isolated on a separate box designed for high speed databases, offloading those resources. I'm sure it could be swamped, but I'd guess my QoS rules will kick in before that time, and I'd probably run out of RAM before I hit CPU issues caused by something else.

Of course, the server can be taken down, it has finite resources, so I don't need anyone to prove that!

[BenYeeHua]

I doubt it . There are never 100 people logging in *simultaneously* anyway. They are normally spread out by a few seconds at least. The server is a cloud server on a quad core system  that allows CPU bursting, and I never see a high CPU load (not oversold), so it should be fine. The database is isolated on a separate box designed for high speed databases, offloading those resources. I'm sure it could be swamped, but I'd guess my QoS rules will kick in before that time, and I'd probably run out of RAM before I hit CPU issues caused by something else.

Of course, the server can be taken down, it has finite resources, so I don't need anyone to prove that!

Yup, it will be 0.00000000000000000000...1%
Except DDOS.
But I hope it will happen in the future, that means at that time, you has many customer.
And enemy too.