Bitsum Community Forum

General Category => General => Topic started by: Jeremy Collake on June 08, 2012, 05:22:27 AM

Title: Support area updated to improve security
Post by: Jeremy Collake on June 08, 2012, 05:22:27 AM
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 (http://bitsum.com/md5.php).

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.
Title: Re: Support area updated to improve security
Post by: nikkil on January 20, 2013, 11:01:23 AM
Hi. Quick question, this applies to all versions being used, correct?
Title: Re: Support area updated to improve security
Post by: BenYeeHua on January 20, 2013, 11:20:57 AM
Quote3. 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. :)
Title: Re: Support area updated to improve security
Post by: Jeremy Collake on February 05, 2013, 12:42:49 AM
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.
Title: Re: Support area updated to improve security
Post by: BenYeeHua on February 05, 2013, 01:04:17 PM
Quote from: Jeremy Collake on February 05, 2013, 12:42:49 AM
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? :)
Title: Re: Support area updated to improve security
Post by: Jeremy Collake on February 05, 2013, 05:50:47 PM
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!
Title: Re: Support area updated to improve security
Post by: BenYeeHua on February 06, 2013, 11:37:18 AM
Quote from: Jeremy Collake on February 05, 2013, 05:50:47 PM
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. ;D
But I hope it will happen in the future, that means at that time, you has many customer. :D
And enemy too.