Short answer: collisions don't matter for password verification. The length of the input is irrelevant.
I understand that md5 and sha512, etc... are insecure because they can have collisions.
No, this is wrong. MD5 and SHA-1 are insecure because it is possible in practice to find collisions.
SHA-512 and the other SHA2 variants (SHA-256, SHA-384, etc.) have collisions. We know this by applying a very simple mathematical theorem, the pigeonhole principle. A SHA-512 hash is a 64-byte string. There are strictly more strings of 0 through 64 bytes than strings of exactly 64 bytes. Therefore there exist two distinct strings of at most 64 bytes that have the same SHA-512 hash. This is a non-constructive proof. We have absolutely no clue how to actually find two such strings. SHA-512 is secure because cryptographers have tried to find two such strings for years and haven't gotten any closer. This is the standard for a cryptographic algorithm being “secure”.
This is not for passwords.
Indeed. For passwords, collisions are irrelevant. If there are multiple valid passwords, it doesn't matter. What matters is that an attacker cannot find any of the valid passwords. SHA2 is as insecure as MD5 and SHA-1 for password hashing: password hashing must be slow and salted. It's an unfortunate historical accident that the word “password hashing” includes “hash”: the two have very different properties.
However, is it still possible to have a collision if the string length is less that the hash size. Ie. md5 is a 32 character hash. So if the string is less than 32 characters, is it possible to still have collisions?
Maybe. We don't know. We know that there are collisions among strings that are at most the size of the hash, by the pigeonhole principle, as I wrote above. We don't know whether there are collisions among strings that are exactly the size of the hash: it's possible that all of them map to a different image. Mathematically, that would mean that the hash, with an n-bit output, is a permutation on strings of length n bits. This is extremely unlikely since the proportion of functions on n-bit strings that are permutation is extremely small, but we don't know for sure.
I don't know, without doing more math than I care to at this time, whether it's likely that there are collisions amongst strings that are strictly less than the size of the hash. I won't do the math because it doesn't matter.
By the way, MD5 is actually a 16-byte hash. It's 32 characters long if you write those bytes in hexadecimal, but most 32-character strings are not the hexadecimal representation of anything, so counting 32-character strings is irrelevant.
However, this only works if no other string that is 10 characters long equals the md5 hash of: 1f129c42de5e4f043cbd88ff6360486f
Wrong. This only works if it is impossible to find another string that is 10 characters long and has the same hash. If another string exists but nobody can find it, that's good enough.
MD5, SHA-1 and SHA2 all use the Merkle-Damgård construction. They work by processing the input one block at a time. For each input block, they apply a compression function (a different one for each MD or SHA variant) to the current internal state and the input block to produce the next internal state. At the end, they append some padding to the last partial block and apply the compression function one more time (or more depending on the exact length of the input). The techniques for finding collisions for MD5 and SHA-1 attack the compression function: they are based on finding block content B1 and B2 such that two distinct internal states S1 and S2 map to the same resulting internal state S'. The techniques allow very little control over the content of B1 and B2, so they don't allow creating collisions where the input is less than one block long, perhaps minus a few bits at the end which can be brute-forced to look like the valid start of padding. (In fact, as far as I know, it takes two blocks of input to reach a collision.) So we don't know how to find collisions on strings that are shorter than the block size. Both MD5 and SHA-1 have a 64-byte block, so there is no way to find a collision where one of the strings is shorter than about 60 bytes.
Of course, even if the current attack techniques don't allow finding a collision on short input, it would be stupid to use a known broken hash function. Attacks only ever get better.
