5 ms·

Security Through Obscurity

43 points by thirsteh 15y ago

stcredzero 15y ago
There is no evidence that the SHA-512 cryptographic hash algorithm is breakable by any modern machinery, so why are we keeping password hashes secret? Yes, but we're still working out the theoretical underpinnings of hash algorithms. http://domino.research.ibm.com/comm/research_projects.nsf/pages/cryptographic_hash.hashfunction-theory.html http://domino.research.ibm.com/comm/research_projects.nsf/pa... Also, if one looks at past performance, it seems like it's only a matter of time before a hash algorithm is broken in some way. http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cry... There is nothing wrong with obscurity, provided that 1) you don't use it as a replacement for standard security and 2) it doesn't interfere with the operation and auditing of your standard security.
- JoachimSchipper 15y ago
  Reversing hashes, even thoroughly broken ones, is still quite impractical - it's collision attacks that you have to watch out for. Of course, you don't break password hashes by reversing the hash, you break password hashes by just trying (variations on) dictionary words until one matches the hash. For that purpose, SHA-256 is not a good choice, since it's too fast - use PBKDF2/bcrypt.
  - SoftwareMaven 15y ago
    Reversing a hash is impossible, so a collision is "reversing" it. All that really matters is that you've got something that the auth system will think is the right password.
    - JoachimSchipper 15y ago
      You're confusing a collision (find any x, y such that f(x) = f(y)) and a second preimage attack (find any x such that f(x) = y for some particular y). The latter is much more difficult, but the former can still be used - see "rogue CA".
epistasis 15y ago
This is a pet peeve of mine as well. Obscurity in your crypto scheme or your SSH server's source code is obviously bad, but applying that phrase to changing an SSH port fundamentally misunderstands what the slogan means.
- tptacek 15y ago
  I agree. Changing your SSH port number isn't even obscurity. It's obvious which port you've bound it to. Nonstandard SSH port numbers are just security through idiosyncrasy.
  - jodrellblank 15y ago
    It's obvious which port you've bound it to. Can you can do it in less time than testing all ports until you find it? (an average of 2^15 connections?). Also if you run it on port 22 and someone tries 22 then that will not trigger any port-scan-detectors. If you run it on port N and they are scanning all ports, you can block them before they find SSH. It is obscurity, it's making finding/confirming SSH 1/65535 instead of 1/1. All your comments here are of the nature "Everyone's an idiot. Ignore the explanations and arguments raised in the article they're just wrong. Trust me."
    - tptacek 15y ago
      There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for. What I'd like to know is, what is that person reasonably going to do when his portscan detector goes off? Why didn't he do it a month ago instead of waiting? I hope my comments here are of the nature of "My mind is boggling as to why smart people think these measures are anything but laetrile." Also: do you think I'm just making it up? Don't be passive-aggressive. If you think I'm full of it on this topic, just say so.
      - philh 15y ago
        > There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for. The point is that if a vulnerability gets discovered in future, he doesn't want to be on a list of "servers that are now vulnerable". When he hears about the exploit, he'll fix it. But if the bad guys hear about it first, not being on that list is useful obscurity. > If you think I'm full of it on this topic, just say so. You're probably not full of it, but it's hard to extract much value from your comments.
bdhe 15y ago
The author kind of mentions this but not explicitly. When you want to use obscurity always make sure it is layered on top of security. In other words, if you are hiding some piece of information that you think helps in security, always make sure that it is still secure even if you do not hide it. So go ahead and obscure your SSH ports, but make sure you are using the latest version. The problem with being complacent about obscurity is that sooner than later people think that obscurity implies security and fail to ensure that their systems are secure underneath the layer of obscurity. Then the system is only secure so long as what you've obscured is obscure. That is dangerous and must be avoided.
tehwalrus 15y ago
I agree with @stcredzero , the password hash thing is nonsense. If you expose the hashes to allow other people to authenticate your users, which I think the author suggests, 3rd party sites can simply cache the password the user provides for crunching and have BAM stolen their password.
- pmylund 15y ago
  It was a kind of tongue-in-cheek comment to demonstrate the irony of "exposing it doesn't matter". I should probably have been more clear that I wasn't actually serious.
tptacek 15y ago
You can't use SHA-512 by itself as a secure password hash. SHA-512 is plutonium. You need the reactor to do anything but kill yourself with it. None of those "obscurity" measures do anything meaningful to improve your security. People just do them to make themselves feel less powerless.
- SoftwareMaven 15y ago
  So how do you quantify "less likely to be h@xxored by some script kiddy's scripts" versus "actually able to resist a focused penetration test"? Are you saying the zero-day exploit "todo list" isn't a valid concern? Mathematically, perhaps there is no difference because the focused penetration attempt overwhelms the equation, but if I'm just "some IP" on the Internet, isn't the less knowledge about me better? It is very similar to the "secret military facility". The security of the facility is determined by what would stop somebody who knows about you, but you reduce the number of times that is tested through the "secret" (obscure) part of the base.
  - tptacek 15y ago
    I have no idea what you're talking about. Nobody with OpenSSH zero-day is feeding it through an Internet-wide scanner.
    - SoftwareMaven 15y ago
      The point is the scanner keeps track of versions: 148.65.45.123 is using SSH x.y. When a zero-day hits for a particular version, they are able to look at the list previously generated to see immediately where they can put a back door. If you don't advertise your ssh (eg change ports) or your version, you aren't on that zero day list. Your system isn't more secure, but your are less likely to be hacked. So, that's the scenario. The above has reduced your chances of being hacked without actually increasing how secure your systems actually are. And then the question: how do you account for that in assessing the cost/value benefits associated with security? I really am curious about this, because there is a cost to the above, so any value should be included in the calculation of whether it is worth it. How do you calculate the value of not being on that list?
ianferrel 15y ago
His analogy to exposing password hashes doesn't really work. The primary reason you don't expose password hashes isn't that someone will break the hashing algorithm. It's that users come up with crappy passwords, and exposing the hashes would let an attacker do a brute-force search on the likely password space. His other points are pretty good, though.
- pmylund 15y ago
  Good point. Let's say, for the sake of argument, that each of them have their own salt :)
  - JoachimSchipper 15y ago
    Any reasonable password algorithm will have a unique salt for each password (well, a random long salt; you're highly unlikely to have collisions). Dictionary attacks still work.
    - pmylund 15y ago
      Right. The analogy isn't bulletproof, but in conclusion it's pretty dumb to share information that could conceivably be used to extract some information or otherwise get an advantage when there's no reason to.
Luyt 15y ago
"Having critical services (e.g. SSH) on non-standard ports" I routinely do this. Not because I think it will enhance security, but because it will reduce the tsunami of braindead bruteforce attacks on my machines, and the associated resource consumption. One night I woke up because my bedside MacMini (which I use for watching movies and listening to podcasts) spooled up its fan and was making a vacuum cleaner sound, something that I didn't experience before with this machine. With sleepy squinted eyes, I inspected the output of 'top' and saw SSH consuming 100% CPU or something. I switched off SSH in the System Preferences and the MacMini returned back to normal; and I went back to sleep. Next morning I moved the SSH service to another port (in the router) and haven't experienced this again. My FreeBSD home server was bashed by a multitude of foreign clients, all trying to break in on port 22. The /var/log/auth.log showed hundreds of thousands of breakin attempts. When I reconfigured sshd to listen on another port, this dramatically dropped to almost zero.
zdw 15y ago
The point of a lot of the techniques he mentions is not obscurity, but avoiding being "low hanging fruit" for non-targeted attacks For example, running ssh on an alt port = less likely to be picked up in a scan = less likely to appear in one of those lists of attack targets. It's the old two guys being chased by a bear joke where one stops to put on shoes, so that he can outrun the other. In non-targeted attack situations little "obscurity" enhancements may mean the difference between being attacked and being skipped over.
pagekalisedown 15y ago
Lots of people seem to forget to configure their firewalls. Nobody should be allowed to connect on your ssh port, except from your office. On the road a lot? VPN into the office THEN connect to ssh.
trotsky 15y ago
While I mostly agree that the cries of "zomg security through obscurity" that one mostly sees on the internet these days come from people who are really just parroting a catch phrase, one shouldn't forget that the industry came upon that aversion honestly. Mostly, it seems, the bad old days of raw security through obscurity are behind us. Examples like custom protocols substituting for authentication, proprietary encoding substituting for encryption, etc. So it seems quite possible that those who might mock running ssh on a nonstandard port or omitting a service version might never have seen actual pure examples of the practice. Perhaps in some years "defense in depth" will have become such a saying that people relying solely on not having bugs in their application will get bullied in a similar way.
- tptacek 15y ago
  Exploits don't care about version banners. You know what cares about version banners? Nessus. If blinding your own security scanners makes you feel better, go ahead, I guess.
  - trotsky 15y ago
    Browser exploit packs absolutely care about version numbers. It's how they determine what if any exploits to push to a client. Nessus, on the other hand, will never look at a user-agent string. So while you're probably correct for one class of threats and targets (targeted and enterprise servers) I wouldn't agree at all that the world is as black and white as you're claiming.
    - tptacek 15y ago
      Are we talking about modifying your browser binary to defeat memory disclosure exploits? I didn't think we were talking about that.
      - trotsky 15y ago
        It certainly seems in scope to me if we're talking about version identifiers, and it (along with several other examples) are clear situations where changing an identifier string could definitely lead to an automated attack that would succeed never being tried. And you don't need to modify any binaries: The easiest way to change something like that is in a transparent proxy, but ie also supports changing via the registry, opera and firefox via about:config, etc.
skrebbel 15y ago
all security i've seen depends on the obscurity of passwords. There is no difference, except in how easily things are spread and cached and logged (i.e. the only reason to not put passwords in URL query strings)
zaidf 15y ago
Isn't a good password just a really obscure combination of characters?
CoffeeDregs 15y ago
OT, but: all security has obscurity and you can't have one without the other: Do you salt your password hashes and hide [obscure] the salt? Do you not share [obscure] your private key? Good security severely restricts the amount of info that need to be obscured; it doesn't mean you can leave behind obscurity. At the same time, being secure doesn't mean you should be wantonly non-obscure. Even if you are using SHA-512, there's just no good reason to expose crucial hashes.
- tptacek 15y ago
  The salt is a public value. It isn't a key; it's a randomizing nonce. Its sole purpose is to transform one hash (SHA-256 or whatever) into thousands or millions of hashes. Of course, if you're using an algorithm that demands that you decide what to do with a salt, you're rearranging deck chairs on the titanic anyways.
  - CoffeeDregs 15y ago
    Hmm... I didn't say the salt was a key (since hashes are one-way that would be silly, right?). I was referring to using a salt to enhance security on stored passwords and, in that case, I don't think that a salt is a nonce since it's used repeatedly (in either per-account or per-application usage) to produce the hash value to match the stored password hash. In this case, it's certainly not a public value. Of course, if you're using an algorithm that demands that you decide what to do with a salt, you're rearranging deck chairs on the titanic anyways. I'll bite: how do you store passwords securely?
    - tptacek 15y ago
      You do not use a salt "repeatedly". The salt needs to be unique per hash. Maybe you should stop offering advice on this topic.
      - CoffeeDregs 15y ago
        http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography) In a typical usage for password authentication, the salt is stored along with the output of the one-way function, sometimes along with the number of iterations to be used in generating the output (for key stretching). Salt is closely related to the concept of nonce. Two important bits there: salt != nonce (closely related); salt is typically stored for future usage (e.g. repetition) (I quoted the iteration bit, but am not referring to that in my usage of "repetition"). Edit: replying here since the thread is too deep. You've got a couple of issues there: you haven't answered my question about storing passwords; you've committed the "appeal to ridicule" fallacy. Further: I don't doubt you know more about this than do I, but I'd love for you to educate me rather than ridicule me. I assume your consulting clients receive better treatment?
vanni 15y ago
@pmylund: Great post! I'm sure that you have been inspired by this comment http://news.ycombinator.com/item?id=2564263 http://news.ycombinator.com/item?id=2564263 No Disqus on your blog. Why not?

43 points by thirsteh 15y ago

There is no evidence that the SHA-512 cryptographic hash algorithm is breakable by any modern machinery, so why are we keeping password hashes secret? Yes, but we're still working out the theoretical underpinnings of hash algorithms. http://domino.research.ibm.com/comm/research_projects.nsf/pages/cryptographic_hash.hashfunction-theory.html http://domino.research.ibm.com/comm/research_projects.nsf/pa... Also, if one looks at past performance, it seems like it's only a matter of time before a hash algorithm is broken in some way. http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cry... There is nothing wrong with obscurity, provided that 1) you don't use it as a replacement for standard security and 2) it doesn't interfere with the operation and auditing of your standard security.

JoachimSchipper 15y ago
Reversing hashes, even thoroughly broken ones, is still quite impractical - it's collision attacks that you have to watch out for. Of course, you don't break password hashes by reversing the hash, you break password hashes by just trying (variations on) dictionary words until one matches the hash. For that purpose, SHA-256 is not a good choice, since it's too fast - use PBKDF2/bcrypt.
- SoftwareMaven 15y ago
  Reversing a hash is impossible, so a collision is "reversing" it. All that really matters is that you've got something that the auth system will think is the right password.
  - JoachimSchipper 15y ago
    You're confusing a collision (find any x, y such that f(x) = f(y)) and a second preimage attack (find any x such that f(x) = y for some particular y). The latter is much more difficult, but the former can still be used - see "rogue CA".

epistasis 15y ago

This is a pet peeve of mine as well. Obscurity in your crypto scheme or your SSH server's source code is obviously bad, but applying that phrase to changing an SSH port fundamentally misunderstands what the slogan means.

tptacek 15y ago
I agree. Changing your SSH port number isn't even obscurity. It's obvious which port you've bound it to. Nonstandard SSH port numbers are just security through idiosyncrasy.
- jodrellblank 15y ago
  It's obvious which port you've bound it to. Can you can do it in less time than testing all ports until you find it? (an average of 2^15 connections?). Also if you run it on port 22 and someone tries 22 then that will not trigger any port-scan-detectors. If you run it on port N and they are scanning all ports, you can block them before they find SSH. It is obscurity, it's making finding/confirming SSH 1/65535 instead of 1/1. All your comments here are of the nature "Everyone's an idiot. Ignore the explanations and arguments raised in the article they're just wrong. Trust me."
  - tptacek 15y ago
    There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for. What I'd like to know is, what is that person reasonably going to do when his portscan detector goes off? Why didn't he do it a month ago instead of waiting? I hope my comments here are of the nature of "My mind is boggling as to why smart people think these measures are anything but laetrile." Also: do you think I'm just making it up? Don't be passive-aggressive. If you think I'm full of it on this topic, just say so.
    - philh 15y ago
      > There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for. The point is that if a vulnerability gets discovered in future, he doesn't want to be on a list of "servers that are now vulnerable". When he hears about the exploit, he'll fix it. But if the bad guys hear about it first, not being on that list is useful obscurity. > If you think I'm full of it on this topic, just say so. You're probably not full of it, but it's hard to extract much value from your comments.

bdhe 15y ago

The author kind of mentions this but not explicitly. When you want to use obscurity always make sure it is layered on top of security. In other words, if you are hiding some piece of information that you think helps in security, always make sure that it is still secure even if you do not hide it. So go ahead and obscure your SSH ports, but make sure you are using the latest version. The problem with being complacent about obscurity is that sooner than later people think that obscurity implies security and fail to ensure that their systems are secure underneath the layer of obscurity. Then the system is only secure so long as what you've obscured is obscure. That is dangerous and must be avoided.

tehwalrus 15y ago

I agree with @stcredzero , the password hash thing is nonsense. If you expose the hashes to allow other people to authenticate your users, which I think the author suggests, 3rd party sites can simply cache the password the user provides for crunching and have BAM stolen their password.

pmylund 15y ago
It was a kind of tongue-in-cheek comment to demonstrate the irony of "exposing it doesn't matter". I should probably have been more clear that I wasn't actually serious.

tptacek 15y ago

You can't use SHA-512 by itself as a secure password hash. SHA-512 is plutonium. You need the reactor to do anything but kill yourself with it. None of those "obscurity" measures do anything meaningful to improve your security. People just do them to make themselves feel less powerless.

SoftwareMaven 15y ago
So how do you quantify "less likely to be h@xxored by some script kiddy's scripts" versus "actually able to resist a focused penetration test"? Are you saying the zero-day exploit "todo list" isn't a valid concern? Mathematically, perhaps there is no difference because the focused penetration attempt overwhelms the equation, but if I'm just "some IP" on the Internet, isn't the less knowledge about me better? It is very similar to the "secret military facility". The security of the facility is determined by what would stop somebody who knows about you, but you reduce the number of times that is tested through the "secret" (obscure) part of the base.
- tptacek 15y ago
  I have no idea what you're talking about. Nobody with OpenSSH zero-day is feeding it through an Internet-wide scanner.
  - SoftwareMaven 15y ago
    The point is the scanner keeps track of versions: 148.65.45.123 is using SSH x.y. When a zero-day hits for a particular version, they are able to look at the list previously generated to see immediately where they can put a back door. If you don't advertise your ssh (eg change ports) or your version, you aren't on that zero day list. Your system isn't more secure, but your are less likely to be hacked. So, that's the scenario. The above has reduced your chances of being hacked without actually increasing how secure your systems actually are. And then the question: how do you account for that in assessing the cost/value benefits associated with security? I really am curious about this, because there is a cost to the above, so any value should be included in the calculation of whether it is worth it. How do you calculate the value of not being on that list?

ianferrel 15y ago

His analogy to exposing password hashes doesn't really work. The primary reason you don't expose password hashes isn't that someone will break the hashing algorithm. It's that users come up with crappy passwords, and exposing the hashes would let an attacker do a brute-force search on the likely password space. His other points are pretty good, though.

pmylund 15y ago
Good point. Let's say, for the sake of argument, that each of them have their own salt :)
- JoachimSchipper 15y ago
  Any reasonable password algorithm will have a unique salt for each password (well, a random long salt; you're highly unlikely to have collisions). Dictionary attacks still work.
  - pmylund 15y ago
    Right. The analogy isn't bulletproof, but in conclusion it's pretty dumb to share information that could conceivably be used to extract some information or otherwise get an advantage when there's no reason to.

Luyt 15y ago

"Having critical services (e.g. SSH) on non-standard ports" I routinely do this. Not because I think it will enhance security, but because it will reduce the tsunami of braindead bruteforce attacks on my machines, and the associated resource consumption. One night I woke up because my bedside MacMini (which I use for watching movies and listening to podcasts) spooled up its fan and was making a vacuum cleaner sound, something that I didn't experience before with this machine. With sleepy squinted eyes, I inspected the output of 'top' and saw SSH consuming 100% CPU or something. I switched off SSH in the System Preferences and the MacMini returned back to normal; and I went back to sleep. Next morning I moved the SSH service to another port (in the router) and haven't experienced this again. My FreeBSD home server was bashed by a multitude of foreign clients, all trying to break in on port 22. The /var/log/auth.log showed hundreds of thousands of breakin attempts. When I reconfigured sshd to listen on another port, this dramatically dropped to almost zero.

zdw 15y ago

The point of a lot of the techniques he mentions is not obscurity, but avoiding being "low hanging fruit" for non-targeted attacks For example, running ssh on an alt port = less likely to be picked up in a scan = less likely to appear in one of those lists of attack targets. It's the old two guys being chased by a bear joke where one stops to put on shoes, so that he can outrun the other. In non-targeted attack situations little "obscurity" enhancements may mean the difference between being attacked and being skipped over.

pagekalisedown 15y ago

Lots of people seem to forget to configure their firewalls. Nobody should be allowed to connect on your ssh port, except from your office. On the road a lot? VPN into the office THEN connect to ssh.

trotsky 15y ago

While I mostly agree that the cries of "zomg security through obscurity" that one mostly sees on the internet these days come from people who are really just parroting a catch phrase, one shouldn't forget that the industry came upon that aversion honestly. Mostly, it seems, the bad old days of raw security through obscurity are behind us. Examples like custom protocols substituting for authentication, proprietary encoding substituting for encryption, etc. So it seems quite possible that those who might mock running ssh on a nonstandard port or omitting a service version might never have seen actual pure examples of the practice. Perhaps in some years "defense in depth" will have become such a saying that people relying solely on not having bugs in their application will get bullied in a similar way.

tptacek 15y ago
Exploits don't care about version banners. You know what cares about version banners? Nessus. If blinding your own security scanners makes you feel better, go ahead, I guess.
- trotsky 15y ago
  Browser exploit packs absolutely care about version numbers. It's how they determine what if any exploits to push to a client. Nessus, on the other hand, will never look at a user-agent string. So while you're probably correct for one class of threats and targets (targeted and enterprise servers) I wouldn't agree at all that the world is as black and white as you're claiming.
  - tptacek 15y ago
    Are we talking about modifying your browser binary to defeat memory disclosure exploits? I didn't think we were talking about that.
    - trotsky 15y ago
      It certainly seems in scope to me if we're talking about version identifiers, and it (along with several other examples) are clear situations where changing an identifier string could definitely lead to an automated attack that would succeed never being tried. And you don't need to modify any binaries: The easiest way to change something like that is in a transparent proxy, but ie also supports changing via the registry, opera and firefox via about:config, etc.

skrebbel 15y ago

all security i've seen depends on the obscurity of passwords. There is no difference, except in how easily things are spread and cached and logged (i.e. the only reason to not put passwords in URL query strings)

zaidf 15y ago

Isn't a good password just a really obscure combination of characters?

CoffeeDregs 15y ago

OT, but: all security has obscurity and you can't have one without the other: Do you salt your password hashes and hide [obscure] the salt? Do you not share [obscure] your private key? Good security severely restricts the amount of info that need to be obscured; it doesn't mean you can leave behind obscurity. At the same time, being secure doesn't mean you should be wantonly non-obscure. Even if you are using SHA-512, there's just no good reason to expose crucial hashes.

tptacek 15y ago
The salt is a public value. It isn't a key; it's a randomizing nonce. Its sole purpose is to transform one hash (SHA-256 or whatever) into thousands or millions of hashes. Of course, if you're using an algorithm that demands that you decide what to do with a salt, you're rearranging deck chairs on the titanic anyways.
- CoffeeDregs 15y ago
  Hmm... I didn't say the salt was a key (since hashes are one-way that would be silly, right?). I was referring to using a salt to enhance security on stored passwords and, in that case, I don't think that a salt is a nonce since it's used repeatedly (in either per-account or per-application usage) to produce the hash value to match the stored password hash. In this case, it's certainly not a public value. Of course, if you're using an algorithm that demands that you decide what to do with a salt, you're rearranging deck chairs on the titanic anyways. I'll bite: how do you store passwords securely?
  - tptacek 15y ago
    You do not use a salt "repeatedly". The salt needs to be unique per hash. Maybe you should stop offering advice on this topic.
    - CoffeeDregs 15y ago
      http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography) In a typical usage for password authentication, the salt is stored along with the output of the one-way function, sometimes along with the number of iterations to be used in generating the output (for key stretching). Salt is closely related to the concept of nonce. Two important bits there: salt != nonce (closely related); salt is typically stored for future usage (e.g. repetition) (I quoted the iteration bit, but am not referring to that in my usage of "repetition"). Edit: replying here since the thread is too deep. You've got a couple of issues there: you haven't answered my question about storing passwords; you've committed the "appeal to ridicule" fallacy. Further: I don't doubt you know more about this than do I, but I'd love for you to educate me rather than ridicule me. I assume your consulting clients receive better treatment?

vanni 15y ago

@pmylund: Great post! I'm sure that you have been inspired by this comment http://news.ycombinator.com/item?id=2564263 http://news.ycombinator.com/item?id=2564263 No Disqus on your blog. Why not?