How secure would this method be considered for password storage

Question

Ok I am currently storing the passwords in most secure way I could think of. With use of Encryption and Hash. The passwords are first generated by user as plain-text with minimum length of 6 alpha-numeric characters up-to 24 char alpha-numeric.

After the passwords plain-text value are ran against MCRYPT. Primarily the TWO_FISH cipher with random IV in ECB mode. Ones that is done the Encrypted plain-text is binded to Hash function which also add's SALT via $saltVar = dechex(mt_rand(0, 2147483647)) . dechex(mt_rand(0, 2147483647));

One's everything is in place the SALT + Encrypted password are hashed via SHA-256 and then re-hashed next 15536 rounds. Creating a relatively secure password.

In my personal opinion this is sufficient way of securing the data, since in part there are no key's being used there is no way of decrypting this, other then running it again with user inputed plain-text password and creating a temporary calculated hash of the password string, after which the string can be matched to the string in the database.

I would never use this for any other data, but for password I belive this is sufficient. However I would still like some profesional critisism, as to whatever my way of protecting the password plain-text is secure or not, and or maybe how I can improve what I already have if its just fine. And while I am at it, would you recomand using TWO_FISH or swapping it for SEARPENT?

Thanks in advance.

Answer 1

It's generally a bad idea to invent your own security algorithms. As you've already said, you don't know if this is secure. You may believe so, and maybe you even find somebody who agrees with you. But that doesn't really mean much.

There are established solutions like bcrypt which have proven themselves both theoretically and practically over a course of many years. We can be pretty confident that those are in fact secure. So why not take advantage of this and use bcrypt?

Regarding your own algorithm:

First of all, I don't see why you would limit the user to only 6 to 24 alphanumeric characters. This makes it impossible to strengthen the password with special characters or use a long passphrase.

The mt_rand() function produces weak random numbers from low-entropy sources like the server time and the process ID. The PHP manual explicitly points that out. A total of 8 bytes also isn't too much.

I cannot comment on whether your hashing scheme is sound, but given that stock PCs can calculate billions of SHA-256 hashes per second, 16,000 rounds again aren't much.

Answer 2

I see two obvious problems with your system:

1) 24 characters isn't very much. A good passphrase is more memorable than a password, and makes up for the low per-character entropy of readable text by having a lot of characters -- 30 to 60 characters, or more. Is there a reason for the limit?

2) Encrypting doesn't provide any security over hashing. If the attacker can steal the password list, it's likely they can steal the encryption key and IV as well (as a side note, ECB mode doesn't use an IV). You've basically got a fixed 15,537-round hash, which may slow down attackers today, but as computers get faster, it gets weaker.

Is there a reason why you can't use an industry-standard solution, such as the inherently-slow, adjustable-strength bcrypt?

Answer 3

No. I feel there was no need to read past where you mention allowing 6-character passwords. That's too short. Even if you require they contain both alpha and numeric chars, that's not enough. It won't take long to run a dictionary of all 6-char alpha-numeric passwords through your algorithm using each salt value in the database. The other answers provide other good reasons not to use your system, but this is a relatively simple and obvious one.