We have a process that encrypts a URL, it uses DES encryption. I suspect someone may have figured out the key and is decrypting it to crawl information. This was set up many years ago, I just want to make sure whoever set it up is did not use a common, generic, out of the box key. Is there a list of known keys not to use somewhere. Google has not been nice to me in finding something so far.
5
-
1You should not use DES in 2022. It was proven broken in 1999. It's trivial to break DES with your desktop computer today.– ThoriumBRCommented Aug 9, 2022 at 20:27
-
2So, to answer your question, you should not use any DES key.– ThoriumBRCommented Aug 9, 2022 at 20:30
-
Keys not to use? Are you reusing known keys? I don't understand the question.– schroeder ♦Commented Aug 14, 2022 at 10:56
-
@schroeder I don't know what the known keys are, and I am trying to find a list of them in case whomever originally coded this process used one. It's obvious I will need to change the encryption.– SanpopoCommented Aug 15, 2022 at 21:13
-
Then this is a quintessential XY question. Especially since you are not even sure if there is such a process, let alone a source for the process. The far better question would be to ask if it is possible before asking for a source. And do that before trying to Google it ... There are no "out-of-the-box keys" therefore there is no source to find them. What you really want to know is how someone is able to crawl your site. Which is a very different question.– schroeder ♦Commented Aug 16, 2022 at 7:53
Add a comment
|
1 Answer
Your question is not possible to answer. Regular DES uses one 56 bit key, which means that there are 72,057,594,037,927,936 different possible keys. 3DES-EDE, commonly called "Triple-DES", has 112 bits of strength, which is 5,192,296,858,534,827,628,530,496,329,220,096. That is 5 decilion keys.
But even that aside, no service would ever list a number of "compromised keys", unless those keys would be of some very specific use. Besides, there are many, many ways in which a key could have been derived from a password or other insecure data, such as a truncated hash, just truncated raw ASCII bits, etc. etc.
Even if you knew that the key is based on stackexchange, you won't know what sort of process was used to derive a key from that.
To address the underlying issue: No one "encrypts URLs", because that makes testing and usability horrible. No one recommends encrypting URLs either. Crawling is just a normal part of the web. How would you differentiate a user just looking what your site offers, compared to a crawler, working systematically? Besides, crawlers can be useful, such as Google indexing your site.
And if the name of the URL endpoints is what stands between you and getting hacked, then I strongly urge you to get in touch with a security consultant and get that application fixed.
-
1It is possible to answer the question without making value judgments. "That's garbage" and "that's stupid" is completely unnecessary when providing a technical answer. You have no idea why they encrypted the URLs, what value it provides, or what problem they were trying to solve.– schroeder ♦Commented Aug 14, 2022 at 10:58
-
@schroeder: The answer poorly explains it, but the conclusion is correct. The missing explanation is that even if the server treats the URL as sensitive and doesn't log it inappropriately, browsers leak URLs everywhere (history, referer, address bar autocomplete suggestion services, trust checking services, identifiers for cookies and local storage, various plugins), so any secret placed in a URL should be assumed revealed. Commented Dec 19, 2023 at 16:06
-
Now, encrypting the information before placing it in a URL would help (the sensitive information isn't disclosed even when the URL is), but only if the encryption is strong. And the designer is still better off passing the crypted data in a different field than the URL. Commented Dec 19, 2023 at 16:15
-
@BenVoigt I have no idea why you're pinging me on this one...– schroeder ♦Commented Dec 19, 2023 at 16:57