You're not generating random passwords at all. As a matter of fact, these passwords have far less entropy even than human-selected passwords over the same character space. Why? You're using consecutive seeds. Especially if an attacker knew the general time in which the password was generated, they'd only have to try a few thousand passwords each of a few thousand lengths.
If you want entropy, don't use md5() as an entropy GENERATOR. Use the pseudo-random number generator for that. Now, if you were to take the md5 of a random number (and the PRNG was seeded with the time), you'd be a bit more secure. If you took the md5 of data read from /dev/random, more secure yet. However, you're still not escaping the fact that hexadecimal is a far cry from sexaduple (?), the base-62 system that is a-zA-Z0-9, which is already considered insecure by just about everyone.
Basically, md5 doesn't GENERATE entropy, which is what you're using it for: it simply obfuscates. And as well, the md5 function doesn't produce STRINGS which constitute secure passwords, no matter what the entropy source happens to be.
I've got good news, and I've got bad news: The universe is merely a figment of my imagination. Now are you ready for the bad news?
While this is a nice method, it limits your range a lot. An MD5 hash can only be comprised of 0-F (15 characters). Compared to the full (lowercase) alphanumeric set which contains 36 characters. If someone was to bruteforce a 4 character password made with your method it would comprise a keyspace of 1073741824 versus a keyspace of 4722366482869645213696. In other words, a password generated with your method is 4398046511104 times less strong than a standard alphanumeric password.
Don't get me wrong. I love your idea but it just isn't as good as what we already have.
All your comments are true, I've only used this method for generating passwords that are intended to be changed (e.g. e-mailing temporary passwords for user registration/forgotten passwords)
Each character in the password will be one of 0-9, a-f, only 16 choices each or 4,294,967,296 (4E+09) choices for the 8 character example. Trivial to brite force on any PC.
Much better to choose a random password from a-z, A-Z, 0-9 & special characters. Assuming 10 useable special characters you have 72 choices per character giving 1.05312E+65 possibilities for an 8 character password. 2E+55 more possibilities. A huge difference.
If you want entropy, don't use md5() as an entropy GENERATOR. Use the pseudo-random number generator for that. Now, if you were to take the md5 of a random number (and the PRNG was seeded with the time), you'd be a bit more secure. If you took the md5 of data read from /dev/random, more secure yet. However, you're still not escaping the fact that hexadecimal is a far cry from sexaduple (?), the base-62 system that is a-zA-Z0-9, which is already considered insecure by just about everyone.
Basically, md5 doesn't GENERATE entropy, which is what you're using it for: it simply obfuscates. And as well, the md5 function doesn't produce STRINGS which constitute secure passwords, no matter what the entropy source happens to be.
I've got good news, and I've got bad news:
The universe is merely a figment of my imagination.
Now are you ready for the bad news?
Don't get me wrong. I love your idea but it just isn't as good as what we already have.
Much better to choose a random password from a-z, A-Z, 0-9 & special characters. Assuming 10 useable special characters you have 72 choices per character giving 1.05312E+65
possibilities for an 8 character password. 2E+55 more possibilities. A huge difference.