If I'm authenticating an action, is it a bad practice to authorize the connection using a decryptable hash that does have a specific algorithm, but only the remote machine knows?
Is sending decryptable data using HTTP bad practice in general?
An algorithm that "only the remote machine knows" does not exist. Algorithms are not secret. They exist as source code, binary code and mind concepts in various places, including the brains of developers. Cryptographers have decided long ago (half a century) to split "cryptosystems" into keys, which are secret, and algorithms, which are not. They did so because it is nigh impossible to keep an algorithm secret, and even when it is not widely known, you cannot tell "how much" it is secret.
Doing anything related to security with plain HTTP is usually a bad idea. Plain HTTP does not offer any protection against eavesdropping, but it does not protect against active hijacking either. And you need both protections. SSL provides both. Use SSL. Once you use SSL, many things are simpler, and, in particular, you can send passwords "as is" in the SSL tunnel.
"Decryptable hash" is a nonsensical expression: by definition, a cryptographic hash function is one-way, which means the exact opposite of "decryptable". You want to say "encrypted password". And encrypting passwords means that you envision decrypting them somewhere, which is a bad idea, unless this is for transport only, not storage; and, for transport, you use SSL.
Yep. Because if can be broken, it more than likely will be broken. It obviously depends on the implementation and what its going to be used for. For example, if you are using something like this to transmit financial data across the internet, i'd say its a bad idea. If there's one thing I've learnt in IT security, its that crypt-analysists are very clever. On the other hand, if you're just using it as a way of obscuring chat inside a small trusted network, there's probably not much of an issue with using something comparatively weak.
Why not just use SSL?