Comment by noncoml
8 years ago
> This is also security by obscurity.
I see this being claimed a lot, but isn’t all security by obscurity at the end of the day?
A simplistic example, compare (A) with (B).
A) I run telnet with no password on a random port. The changes for an attacker to guess my password are 1/65k.
B) I run telnet in port 25 with password being a random number from 1 to 65k.
How do A and B differ in security?
> I see this being claimed a lot, but isn’t all security by obscurity at the end of the day?
I Do Not Think It Means What You Think It Means [1].
To elaborate, the concept is not formal/mathematical, it's a design concept. You can distinguish between a security implementation that explicitly depends on a secret key or password, and an implementation that implicitly relies upon secret implementation details for its security. The latter is not intentionally designed as a carefully-controlled secret, and therefore much easier to accidentally leak.
[1] https://en.wikipedia.org/wiki/Security_through_obscurity
You are right, I did, but I think so does the parent of my original reply.
The GP of the original reply said "Randomise your bucket names" and the parent said this is "Security by obscurity".
The point I was trying to make, was that using a random name, as the GP suggested, is as good as using some kind of security with a password of the same strength.
Assuming there is no way for somebody to get a list of all the buckets, and therefore not having to "guess" the name.
But yeah, it has nothing to do with security through obscurity. Sorry.
Whilst they don't in your example, choosing a password between 1 and 65K is a very bad decision to begin with (assuming the attack knows this ... if they don't the password search space is far larger than the port search space)
In general A does not improve your security 65K times since a single attempt will tell if there is telnet on the port or not, whereas with B all you know if you got the wrong password.
Now if you ran a dummy telnet that always can slow 'wrong password' responses on the other (65K-1) ports that would potentially increase the security 65K times, but still isn't really a meaningful thing to do.
You are completely missing the point of the example.
I hope the example was not implying that the “security” was just lack of knowledge of the random telnet port. Running a port scan to find out is incredibly easy (or just use Shodan).
This comment is a great example of one of worst aspects of HN.
A is a realistic case of security by obscurity - there's a sizable amount of people who believe that to be secure.
B is in my opinion much less realistic: very few people believe a password two bytes long (or better, with two bytes of entropy) to be secure. Even a trivial password like "TelnetSucks" scores 31 bits of entropy with https://apps.cygnius.net/passtest/.
That app doesn't seem to be great. It complains when a password contains spaces or is longer than 16 words.
A) brute force takes 65K max attempts
B) unless you know the password MUST be a number and MUST be between 1 and 65K (which is a terrible password requirement, e.g. a password of max length 65000 using only digits 0-9 is as good as no password), you need to brute force the entire known character space up to some finite number. The sun will die first.
> unless you know the password MUST be a number and MUST be between 1 and 65K
But with A you don't get in unless you know the password MUST be empty and there MUST be a telnet server on a random port. What's the difference?
> What's the difference?
The problem is one of probabilities - even the most basic script-kiddie scanners is set up to find your telnet server. Right now there are hundreds, if not thousands, of machines scanning the entire IPv4 space over and over for exactly this kind of silly configuration. If you do something like this it will eventually be found and used.
You are missing the point of the example.
If you've had to say this to both of the commentators who've replied, perhaps you should try to come up with a different example that better conveys the point you are trying to make...
2 replies →
I actually somewhat agree with your point, your example is simply not realistic. Your point is correct because people are using the term security by obscurity wrong. Security by obscurity means that you rely on the secret implementation of your algorithm. Our best encryption algorithms are public so they can be poked and peer reviewed. You are right in the fact that through enough obscurity of the key, you attain security as it's non feasible statistically to brute force.
If you have a public & unlisted endpoint that looks like
https://example.com/VERYLONGANDRANDOMKEY
You might argue it's as good as a request to
https://example.com
with an Authorization header containing this key for example.
(Well, not exactly the same, as most access logs will include the first and not the second, but for the sake of the argument)
p.s. I don't agree for example that
VERYLONGANDRANDOMKEY.example.com is the same, as if I'm not mistaken, if you just scan the entire IP range, then try to do a reverse DNS lookup, you'll end up finding it anyway.
1 reply →
At the most abstract level, security is RISK management which is related to SECRETS management. So, on some level it is true that security is equivalent to obscurity. But, that's like saying that cars are molecules. It is true, but it is not a useful statement.
There are two operative principles of security that you should research. 1) Defense in depth, where there is more than one layer of security that must be pierced. 2) Assume that the attacker knows absolutely everything about your system, design, ports, and so on - except for the key material.