Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
it is not a hash if it is "decryptable" a hash is defined mathematically as a one way function, by being "decryptable" it is now a 2 way functions. And one, don't on invent your own cryptography you are likely to make numerous mistakes and the cryptanalyst's will have a field day, two don't implement your own cryptography you are likely to make a mistake there too. Use tools already provided by those in the field like SSL encrypt with whatever the server provides. – ewanm89 Mar 6 '13 at 11:22
You're talking about HTTP connections between real applications rather than a browser and a server, right? – thejh Mar 6 '13 at 16:05
Besides the cryptographic confusion others have already pointed out, it seems like you are also confusing between "authentication" (prove who you are) and "authorization" (what you can do). I'm not sure what you actually mean here, unless you just mean "authenticating a user that requested to perform an action"... – AviD Apr 5 '15 at 8:17
up vote 5 down vote accepted

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.

share|improve this answer
"Use SSL." Yes, do that, but make sure that only your server's cert will be accepted, not anything that your browser would accept as valid (well, unless you're running in the browser). – thejh Mar 6 '13 at 16:05

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?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.