Does prepending a salt to the password instead of inserting it in the middle decrease security?

It depends on the hash function.

With a random oracle (which is the "ideal hash function"), there is no difference on how you put together salt and password at all, as long as both go in.

With real live hash functions there might be differences on the position of the input (like, there are extension attacks).

But then, you usually want to use some special password hashing scheme like PBKDF-2, bcrypt or scrypt, and these are already made with three inputs, one being the password and the other one the salt (the third one the work factor). Simply use them as they were meant to be used.

What this article could have meant is that putting the salt somewhere in the middle of the password supposedly increases the chance of being cracked by a dictionary attack or by brute force, because the rules to actually compose the same hash could not be implemented in your password cracker of choice. In reality, this is probably complete nonsense.

How does this work?

If you take a program like John the Ripper, you feed it with your password file like so (not the exact syntax):

username:password:salt

Then you pass the format as a parameter that you think the hash is generated with. This can be:

md5(pass + salt)
md5(salt + pass)
md5(md5(pass) + md5(salt))
md5(pass + md5(salt))
md5(md5(...(salt + pass + salt)...))
...
and whatnot.

John the Ripper comes with a premade set of about 16 subformats you get to choose from.

Putting the salt somewhere in the password would probably look like that:

md5(password.substring(0,4) + salt + password.substring(4,end))

So, using a technique like this requires you to write a small plugin for John at first, before you can start cracking (which shouldn't be a problem at all).

In addition, you, as an attacker, might have a list of hashes + salts of unknown origin and have no knowledge about the way how a hash is composed. This is rarely the case. If you, as an attacker, manage to extract hashes and salts from a database, you probably either find a way to extract the password hashing algorithm of the website or you just create a new account with a known password, extract the hash and salt for it and brute force the algorithm that was used to compose the final hash (which can be more or less challenging).

All in all, it is almost completely arbitrary where you put the salt and whether or not you iterate the hashing algorithm ten thousand times or not. This does NOT provide a significant amount of security.

If you want security, you can do way better by using a better hashing algorithm or bcrypt or something else that is computationally expensive.

It is better to have randomness at the beginning of the input string, than at the end.

If the salt is a constant value for all passwords then it is easier to bruteforce multiple passwords if the salt is applied as:

hash(salt . password)

rather than

hash(password . salt)

The reason is simply because some (and I think both md5 and sha-1 fit this description) hashing algorithms are iterative - and if the string you are hashing starts with a known constant value it is possible to seed any cracking attempt with the result of hashing the salt, thus removing the benefits of salting your passwords.

If salt values are password specific (which they should be), the above does not apply, and the salt is likely to be more random than the password itself. For this reason, it's better to prepend the salt - though the difference/benefit is negligible.

The suggestion to insert the salt in the middle of the input string is likely another permutation of not starting the input string with a constant value - so long as you avoid that, the password is as secure as the hashing algorithm and the application using it.