6 ms·

On the same theme, I think that people have fixated on "security by obscurity" == bad instead of the original message which was "security by only obscurity" ==

On the same theme, I think that people have fixated on "security by obscurity" == bad instead of the original message which was "security by only obscurity" == bad. There are simple things you can do to keep away from scripted attacks or increase their cost. Stuff like using non-standard ports, or disabling default login IDs like root. Those are all pretty effective at keeping away the bulk of non-skilled attackers.

sascha_sl 6y ago
DRM is one example in which security by obscurity is almost universally bad, and even game publishers seem to agree, considering in how many games Denuvo and/or VMProtect has been deliberately patched out of just to see massive performance improvements as soon as initial sales die down. All it does is get you the extreme fans that want something right at release, and you'll capture that audience - most of the time at least - with or without DRM. All you're doing is making their experience worse.
UncleMeat 6y ago
> instead of the original message which was "security by only obscurity" == bad That isn't even the original message. The original message was Kerchoff's Principle, which states that in cryptosystems all information about the system is known except the secrets. This is very literally "security by obscurity is bad" except that it applies very narrowly to the construction of cryptosystems. The error was applying it to systems security more broadly, where it doesn't fully make sense.
zeepzeep 6y ago
Using non-standard ports can actually be quite a severe security risk. Browsers block many ports, if you move your internal service to an unblocked port, you expose it to every browser in the network! (e.g. a mail server or IRC, something that can be talked to over http.)
- tgflynn 6y ago
  Do you have a reference for "Browsers block many ports" ? I thought there are even ssh clients that run in javascript in the browser. That wouldn't work if browsers were blocking access to port 22 for outgoing packets/connections.
  - zeepzeep 6y ago
    Go to https://google.com:22 https://google.com:22 "This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."
    - tgflynn 6y ago
      Hmm. There's some more information here: https://www-archive.mozilla.org/projects/netlib/portbanning https://www-archive.mozilla.org/projects/netlib/portbanning. I'm up-voting your original comment because it does seem like a potentially valid concern, at least worthy of discussion, and shouldn't be down-voted in my opinion.
    - pwinnski 6y ago
      So moving my SSHD port opens me up to the wide array of SSHD exploits that run inside of Firefox? I'm not sure that web browsers are a popular vector for network exploits. Counting on anything client-side is not a wise approach to network security.
      - tgflynn 6y ago
        Any piece of javascript code on any website you visit is going to be running inside of Firefox on your local network. I don't know how widespread these kinds of attacks are but they are reasonably well known which is why these port blacklists were implemented in the first place: https://www-archive.mozilla.org/projects/netlib/portbanning https://www-archive.mozilla.org/projects/netlib/portbanning.
- liability 6y ago
  Uh, that doesn't make much sense. If you point a browser at an IRCd it will simply not work. Where's the security issue?
  - zeepzeep 6y ago
    https://en.wikipedia.org/wiki/Inter-protocol_exploitation#Example https://en.wikipedia.org/wiki/Inter-protocol_exploitation#Ex... You could join and spam an IRC server via javascript in the past. Now if you try it you get something like NS_ERROR_PORT_ACCESS_NOT_ALLOWED. If you move to a non-standard port javascript can talk to your internal IRC again.
    - liability 6y ago
      If your IRCd allows an unauthenticated connection to start spamming like that, changing the port so a browser can't do it is just wallpapering over the real problem. Anybody that cared to could just use any other software to spam your IRCd.
      - zeepzeep 6y ago
        Yes, a public & open IRC would be another problem... but that's not what I'm saying. I'm talking about an internal server. > Anybody that cared to could just use any other software to spam your IRCd. No they couldn't use other software. They couldn't access the server, cuz they are not inside of the network. Their javascript is inside the network tho, that's why browsers implement this port blacklist. Moving an internal app to a non-standard port might expose it to malicious javascript, that's all I'm saying.
        liability 6y ago
        The issue remains that your ircd is still wide open, waiting for somebody more creative to find another way of opening connections inside your LAN on arbitrary ports. Counting on browsers to keep your network secure is foolish.
deleted 6y ago
[deleted]
devwastaken 6y ago
There are very few people who can create proper security first, and then a sane level of obscurity to mitigate attack. It's the same as saying don't roll your own encryption. There's people out there that could, but for the other 99.9% its false security. Generally what happens is people will use their non programmer "common sense" and think "nobody will be able to figure it out so it's good". Obscurity is something you do because you know how to properly break rules.
ldiracdelta 6y ago
Defense in depth. I don't care if the first level of defense is a speedbump. I don't absolutely depend on it, but why should I _not_ put the speedbump there when it is so cheap and easy.
- teddyh 6y ago
  Because speedbumps are annoying to everybody, and wastes everybody’s time with unnecessary complications.
  - zymhan 6y ago
    It is trivial to specify the SSH port number
    - thinkharderdev 6y ago
      It is trivial if you actually know what the port number is and you are only talking to one server and the non-22 port is static. Now imagine you have code that is connecting to thousands of different servers on different ports and they can change at any time if someone who owns one of those servers decides to rebuild their machine and changes the SSH port. Nothing is trivial at scale. That's not say that is always a valid consideration but standards and conventions exist for a reason.
- staticassertion 6y ago
  The reason is because obscure things tend to be less well understood. SSH port being on another port isn't a case of that, but it isn't security by obscurity. Security by obscurity might be "I use a non standard PDF viewer, therefor I am safer". But a non-standard PDF viewer may also be subject to less auditing, may not have pressure to improve its security, etc. It's an unknown both to the attacker but also to you. This is where security through obscurity is actually a problem. It also makes it harder to threat model. Do you consider your obscurity as a mitigation when you consider threats to your system? It leads to the temptation of "well, but the attacker would have to know that I'm using this PDF viewer", and then you start to treat that as a mitigating factor. It can be a dangerous thing. Secrets are not obscurity. Randomness is not obscurity. People seem to make that mistake the most.
wnevets 6y ago
>On the same theme, I think that people have fixated on "security by obscurity" == bad instead of the original message which was "security by only obscurity" == bad. This seems to be the case for a lot of things in the technology. Someone shares an idea, it gets popular and through the years of "the telephone game" the original indent is lost but everyone is running around treating it as gospel. Everything from alige to security by obscurity.

sascha_sl 6y ago

DRM is one example in which security by obscurity is almost universally bad, and even game publishers seem to agree, considering in how many games Denuvo and/or VMProtect has been deliberately patched out of just to see massive performance improvements as soon as initial sales die down. All it does is get you the extreme fans that want something right at release, and you'll capture that audience - most of the time at least - with or without DRM. All you're doing is making their experience worse.

UncleMeat 6y ago

> instead of the original message which was "security by only obscurity" == bad That isn't even the original message. The original message was Kerchoff's Principle, which states that in cryptosystems all information about the system is known except the secrets. This is very literally "security by obscurity is bad" except that it applies very narrowly to the construction of cryptosystems. The error was applying it to systems security more broadly, where it doesn't fully make sense.

zeepzeep 6y ago

Using non-standard ports can actually be quite a severe security risk. Browsers block many ports, if you move your internal service to an unblocked port, you expose it to every browser in the network! (e.g. a mail server or IRC, something that can be talked to over http.)

tgflynn 6y ago
Do you have a reference for "Browsers block many ports" ? I thought there are even ssh clients that run in javascript in the browser. That wouldn't work if browsers were blocking access to port 22 for outgoing packets/connections.
- zeepzeep 6y ago
  Go to https://google.com:22 https://google.com:22 "This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."
  - tgflynn 6y ago
    Hmm. There's some more information here: https://www-archive.mozilla.org/projects/netlib/portbanning https://www-archive.mozilla.org/projects/netlib/portbanning. I'm up-voting your original comment because it does seem like a potentially valid concern, at least worthy of discussion, and shouldn't be down-voted in my opinion.
  - pwinnski 6y ago
    So moving my SSHD port opens me up to the wide array of SSHD exploits that run inside of Firefox? I'm not sure that web browsers are a popular vector for network exploits. Counting on anything client-side is not a wise approach to network security.
    - tgflynn 6y ago
      Any piece of javascript code on any website you visit is going to be running inside of Firefox on your local network. I don't know how widespread these kinds of attacks are but they are reasonably well known which is why these port blacklists were implemented in the first place: https://www-archive.mozilla.org/projects/netlib/portbanning https://www-archive.mozilla.org/projects/netlib/portbanning.
liability 6y ago
Uh, that doesn't make much sense. If you point a browser at an IRCd it will simply not work. Where's the security issue?
- zeepzeep 6y ago
  https://en.wikipedia.org/wiki/Inter-protocol_exploitation#Example https://en.wikipedia.org/wiki/Inter-protocol_exploitation#Ex... You could join and spam an IRC server via javascript in the past. Now if you try it you get something like NS_ERROR_PORT_ACCESS_NOT_ALLOWED. If you move to a non-standard port javascript can talk to your internal IRC again.
  - liability 6y ago
    If your IRCd allows an unauthenticated connection to start spamming like that, changing the port so a browser can't do it is just wallpapering over the real problem. Anybody that cared to could just use any other software to spam your IRCd.
    - zeepzeep 6y ago
      Yes, a public & open IRC would be another problem... but that's not what I'm saying. I'm talking about an internal server. > Anybody that cared to could just use any other software to spam your IRCd. No they couldn't use other software. They couldn't access the server, cuz they are not inside of the network. Their javascript is inside the network tho, that's why browsers implement this port blacklist. Moving an internal app to a non-standard port might expose it to malicious javascript, that's all I'm saying.
      - liability 6y ago
        The issue remains that your ircd is still wide open, waiting for somebody more creative to find another way of opening connections inside your LAN on arbitrary ports. Counting on browsers to keep your network secure is foolish.

deleted 6y ago

[deleted]

devwastaken 6y ago

There are very few people who can create proper security first, and then a sane level of obscurity to mitigate attack. It's the same as saying don't roll your own encryption. There's people out there that could, but for the other 99.9% its false security. Generally what happens is people will use their non programmer "common sense" and think "nobody will be able to figure it out so it's good". Obscurity is something you do because you know how to properly break rules.

ldiracdelta 6y ago

Defense in depth. I don't care if the first level of defense is a speedbump. I don't absolutely depend on it, but why should I _not_ put the speedbump there when it is so cheap and easy.

teddyh 6y ago
Because speedbumps are annoying to everybody, and wastes everybody’s time with unnecessary complications.
- zymhan 6y ago
  It is trivial to specify the SSH port number
  - thinkharderdev 6y ago
    It is trivial if you actually know what the port number is and you are only talking to one server and the non-22 port is static. Now imagine you have code that is connecting to thousands of different servers on different ports and they can change at any time if someone who owns one of those servers decides to rebuild their machine and changes the SSH port. Nothing is trivial at scale. That's not say that is always a valid consideration but standards and conventions exist for a reason.
staticassertion 6y ago
The reason is because obscure things tend to be less well understood. SSH port being on another port isn't a case of that, but it isn't security by obscurity. Security by obscurity might be "I use a non standard PDF viewer, therefor I am safer". But a non-standard PDF viewer may also be subject to less auditing, may not have pressure to improve its security, etc. It's an unknown both to the attacker but also to you. This is where security through obscurity is actually a problem. It also makes it harder to threat model. Do you consider your obscurity as a mitigation when you consider threats to your system? It leads to the temptation of "well, but the attacker would have to know that I'm using this PDF viewer", and then you start to treat that as a mitigating factor. It can be a dangerous thing. Secrets are not obscurity. Randomness is not obscurity. People seem to make that mistake the most.

wnevets 6y ago

>On the same theme, I think that people have fixated on "security by obscurity" == bad instead of the original message which was "security by only obscurity" == bad. This seems to be the case for a lot of things in the technology. Someone shares an idea, it gets popular and through the years of "the telephone game" the original indent is lost but everyone is running around treating it as gospel. Everything from alige to security by obscurity.