So, this big, reknown company (you all heard off) is sending md5 encrypted strings (with GET key: password) over HTTP.

I accidentally came over it since I wanted to use jnlp on a non-windows machine. And I am curious. Is it by definition insecure to work like this, or can it be safe when one uses SALT and other stuff alike?

The URL looks like this: url/folder/page/?login=[USERNAME]&password=[MD5-String] This URL is also stored in the corresponding .jnlp file.

I hashed my password to MD5 and it is not the same as the password in the URL.

First and foremost, I am curious. I do not have the skills to exploit this (if it where possible), and don't even want to exploit it. If you guys think I should notify the company in question: I will do so.


  • what happens if you log out and use the same URL? Or use it from a different machine? It may be salted with a session ID, or something like that.
    – Red Alert
    Commented Nov 26, 2013 at 21:26
  • How do you know that the “MD5-String” is actually an MD5? Just because it encodes 16 bytes doesn't mean it is an MD5. This might have been reasonable (not great, but reasonable) if it was over HTTPS — it depends what that string is and what is done with it on the server side. Does the string change if you change your password? If you use the same password on a different account? Commented Nov 26, 2013 at 21:28
  • Yes this works fine.
    – TheUnpragmaticProgrammer
    Commented Nov 26, 2013 at 21:29
  • @gilles You are right again. It is not a password. Changing my password didn't result in a different string :P Sorry for the noob question, but can I mark you comment as the answer?
    – TheUnpragmaticProgrammer
    Commented Nov 26, 2013 at 21:34
  • Sending a password over http, even when hashed with MD5, is a bad idea. It's important to use https. Commented Nov 27, 2013 at 8:41

1 Answer 1


I am curious. Is it by definition insecure to work like this.

No. Submitting passwords via GET is not fundamentally less secure than submitting them via POST (which is what every other site does). It does mean that the "password" is stored unencrypted, but if done right, that password that they're storing not your actual login password but rather a password used specifically for this purpose. In fact, the string you see that you assume is MD5 may actually be the password itself, generated at random.

A authentication token passed in a URL is problematic because it (a) is easy to copy, even accidentally, (b) is cached, (c) shows up in referrer strings, (d) shows up in logs, (e) offers little in the way of actual authentication. Instead, of doing true authentication, the URL itself is the key.

On the other hand, this may be exactly what the company wants. If you want a protected resource to be accessible to anyone who knows the correct URL, then this is how you do it.

If they simply called it "access token" instead of "password", would you suddenly feel better about it?

If you guys think I should notify the company in question: I will do so.

If that will make you feel better, then go ahead and tell them. They already know, of course, since they built it. It'd be like notifying someone that their car is blue.

  • Well, since it said 'password' I immediately assumed it was a password. As turned out: I was wrong: Changing passwords does not influence the string. And, of course, the last few sentences were only my way of saying I'm not a creepy hacker guy (or probably script kiddy in my case) who wants to exploit and hack into these systems. Thanks for your answer! Commented Nov 27, 2013 at 8:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .