Hot answers tagged

234

Obscurity isn't a bad security measure to have in place. Relying upon obscurity, as your sole or most substantial security measure, is more or less a cardinal sin. Kerckhoff's Principle is perhaps the most oft-cited argument against implementing security through obscurity. However, if the system is already properly secure according to that principle, this ...


104

Keeping the design secret does not make the door insecure per se; however, believing that it adds to security is a dangerous delusion. If revealing the details of the authentication system would allow breaking it, then that system is pure junk and should be discarded. Therefore, if you did your job properly, then revealing the details should be harmless. If ...


79

The misconception that you're having is that security through obscurity is bad. It's actually not, security only through obscurity is terrible. Put it this way. You want your system to be complete secure if someone knew the full workings of it, apart from the key secret component that you control. Cryptography is a perfect example of this. If you are ...


66

A harder to guess username adds to the security if it's kept secret. The problems are Usernames are often not kept especially secret. On most systems allowing multiple users to log in, any user can view the list of valid users. On systems that run mailservers, the mailserver can effectively be used to check if a username might be valid as most mailservers ...


63

I'll extend on one point at a slightly more abstract level about why public authenticated spaces are preferable to hidden unprotected spaces. The other answers are all perfectly good and list multiple attacks one should know better to avoid. Everyone with formal training should've heard at some point of the Open Design security principle. It states that ...


62

If Bob is trying to type products and mistypes product, he already knows there's a URL in the website for products and so you're not telling him anything he doesn't know. If you don't suggest URLs that shouldn't be public, you won't have any issues. Why use a 404 message though, and not do an immediate redirect?


51

Much of the work on passwords and keys is related to controlling where they are stored and copied. A password is stored in the mind of a human user. It is entered on a keyboard (or equivalent) and goes through the registers of a CPU and the RAM of the computer, while it is processed. Unless some awful blunder is done, the password never reaches a permanent ...


51

Since we're talking theoretically, here are several reasons why a random URL alone is not sufficient enough to protect confidential data: URLs can be bookmarked. URLs are recorded in the browser history (public kiosk). URLs are displayed in the address bar (shoulder surfers). URLs are logged (think 3rd party proxy). URLs can be leaked via Referrer headers ...


50

An unknown "encryption" algorithm has been historically achieved at least once. I am speaking of Minoan Linear B script, a writing method which was used in Crete around 1300 BC. The method was lost a few centuries later, with the death of all practitioners and the overall collapse of civilization during the so-called Greek Dark Ages. When archaeologists ...


50

Your public facing IP address is for most intents and purposes public information. No security should be dependent on it being private, however it's not something you want to wave around willy nilly necessarily (just like you wouldn't wave your home address around) but it also isn't something that is hard for someone to find with generally minimal effort if ...


50

Think about it this way On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. ...


48

In approximate order of increasing complexity (not security, and methods may be combined), here are some ideas that would be easy for anyone used to puzzles/writing code/maths. A more complete idea is below. NB: when I say "secret" I mean not written in the book. These are all easy, and most useful to deter the casual thief. Have a memorised secret ...


47

The risk here is in believing that a "hidden SSID" changes anything to the security. A non-hidden SSID means that the router will shout at regular intervals "hello everybody, I am Joe the Router, you may talk to me !". A hidden SSID means that the client machine (not the attacker's machine) will shout at regular intervals "Hey, Joe, where are you ? Please ...


45

My opinion (and I am a cryptographer -- I have a shiny diploma which says so) is that: We cannot speculate on unknown algorithms, because they are, well, unknown. NSA is like all secret services in the World, they really love secrecy and will practice it for the sake of it. So the fact that their algorithms are not published is in no way indicative of some ...


44

I personally think you're doing alright. As long as your underlying login method is secure, add as many obscurity layers as you want. I have worked with some clients that wanted the exact thing you're trying to achieve. I've always used one of these two methods: Cross-Site login form: A local .html file that has a login form submitting to the example.com/...


39

See this answer. The main point is that we make a sharp distinction between obscurity and secrecy; if we must narrow the difference down to a single property, then that must be measurability. Is secret that which is not known to outsiders, and we know how much it is unknown to these outsiders. For instance, a 128-bit symmetric key is a sequence of 128 bits, ...


38

Secrets are hard to keep secret. The larger a secret is and the more people that know it, the sooner it is likely to leak. Good secrets are: Small. Known only by one person. Easy to change. When we accuse someone of security through obscurity what we are really saying as that we think their secret could be smaller, known by fewer people and/or easier ...


37

Your network guy might have a good reason for not wanting to share the information you enquired about. You see, what you describe you asked him of is not the IP range (CIDR) your company has been assigned to, but actual list of individual live IPs within that ASN. Now, getting the CIDR range that your organisation was assigned to its ASN is relatively easy, ...


32

Interesting question. My thoughts on this are that obscuring information is helpful to security in many cases as it can force an attacker to generate more "noise" which can be detected. Where obscurity is a "bad thing" can be where the defender is relying on that obscurity as a critical control, and without that obscurity, the control fails. So in ...


32

Yes, it is bad security practice indeed. When using the Forgotten Password feature, the site should respond with a message: "An email has just been sent to the specified email address, if it exists and is registered within our system. Please read the email and follow the instructions." Or simply: "Please check your email inbox for instructions on how to ...


31

To attack a cryptographic protocol, you have the following attack methods Known plaintext: Trying to find correlations between the plaintext you have and the corresponding ciphertext. Chosen plaintext: Encrypting specific plaintext and studying the changes to the ciphertext as the plaintext changes. Choosen ciphertext: Decrypting specific ciphertext and ...


31

No. A username is not supposed to be kept secret and thusly won't be. A username is a public ID. Relying on it for security is not smart.


30

No. You should always assume that the attacker knows everything. Security by obscurity is considered bad practice by most non-govt developers and architects. The obstacle it provides is minimal, and if something is kept secret, it may be so to hide a flaw. Kerckhoffs's principle is important to look at. Edit: This answer discusses security by obscurity in ...


30

We don't just want secrecy. We want quantifiable secrecy. The point is not only to ensure confidentiality of data, but also to be able to know that we indeed ensured confidentiality of data. When we have a public algorithm and a secret key, secrecy can be quantified. For instance, if we use AES with a 128-bit key, then we know that an attacker will have to ...


29

You have already received several excellent answers, though @TomLeek's and @Iszi's answer (both excellent btw) seem to be in direct contradiction. They both make excellent points: on the one hand, keeping the design secret will not make the system secure, whereas reviewing it publicly will enable you to (possibly) find certain vulnerabilities you had not ...


22

The problem with secret URLs is that they can be leaked in a variety of ways. Images, Javascript, Stylesheets, and fonts can leak the URL of the webpage you are visiting. For example, if your secret page includes something like <img src="http://example.com" /> then when your browser grabs the image it may include the URL to the secret page in the ...


21

Security by obscurity is where you rely upon some fact which you hope is not known to an attacker. A major problem with this is that once the fact is disclosed, the security scheme is rendered useless. However, all SSH is doing is obscuring information. It relies on the hope that an attacker won't think to guess the correct cryptographic key. When the ...


21

The reason that relying on security through obscurity is frowned upon, is that once the algorithm is leaked or broken, you've totally lost all the security gained by obscurity. So if any actor with access to the algorithm ever leaves your organization, or you are hacked, or source code (or an executable) of a encryption/decryption program is somehow leaked/...



Only top voted, non community-wiki answers of a minimum length are eligible