6 ms·
That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?
by thecodemonkey 5y ago
That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?
- yonixw 5y agoI think the time aspect makes it OK, otherwise TOTP itself should be abandoned due to the same principle. (SSH still has password)
- benjohnson 5y agoIt's another layer of security. There have been exploits of OpenSSH in past so this may be prudent.
- zbuf 5y agoTrouble with extra layers, there's a point where it results in complexity. Which, in my experience, is more likely to be the root cause of a security problem. I'm not saying this little demo is a disaster or anything. But for example, perhaps it requires an awareness of this scheme in an external firewall's rules, and maybe another machine pops up in the rather large IPv6 range that's now available. At its extreme, these sorts of approaches can bring a lack of clarity which layer is providing the actual security.
- lucb1e 5y agoI actually looked into this a few months ago and if memory serves, the last default setup authentication bypass was in something like 2003. Since then, I think the worst thing has been user enumeration. And 2003 was a very different world in terms of how much we cared about hardening, so ssh being reliable throughout all that time is really quite something.
- dec0dedab0de 5y agoYes, but that's only bad if it's your only security.
- anjbe 5y agoLayering has additional costs, like requiring additional client configuration and software and (in this case) only working over IPv6. The number one step any public‐facing SSH server should take is to switch from password auth to keys only. Anyone who’s still concerned can put it behind a WireGuard VPN. Layers typically added beyond that (like changing port, etc.) don’t even register on the security scale, so to speak. The tweet that inspired the post mentioned port knocking which has always been rather ridiculous given those alternatives.
- Bancakes 5y agoThe simple fact that ssh is over IPv6 already leaves out 99% of potential hackers aka bots.
- alias_neo 5y agoI have some "cloud" VMs which have been around several years, they're attacked constantly, I haven't seen a single incoming IPv6 source to date. I wonder if there's a "missed opportunity" for hackers there given presumably how many forget to configure their IPv6 firewall.
- tialaramex 5y agoThe search space is too enormous. Which is why you (somebody with a SSH server) should do IPv6 and then forget this other weirdness. [You should do publickey and so on, but I mean the Tosh stuff is "weirdness"] Suppose you can write code that can try to connect to the SSH server on one million IP addresses per hour, if they respond you attempt an attack. You can try all of the servers in the entire IPv4 Internet in a few months even with a pretty naive algorithm. But if you do this with IPv6 you won't ever finish trying addresses and indeed almost certainly won't find even one server (let alone successfully attack one) in your lifetime. So immediately you need a more expensive attack method. Maybe you buy a supply of "passive DNS" (name -> address answers stripped of information about who asked, many big DNS providers sell this) which is not cheap and not well suited to this problem but it gets you somewhere. You pull out IPv6 addresses and try to SSH connect to them from your supplied list. This could work, but now you need to hope that your potential victims revealed themselves to you, all the juicy SSH servers in the world are invisible otherwise.
- ad404b8a372f2b9 5y agoI don't know why people knock on "security by obscurity" in general, it's a great defense for many threat models that an average individual would fall under. A lot of credential stealing viruses just look for specific folders or file names for examples, some vulnerability scanners look for specific ports, etc ...
- taneq 5y agoIt’s because they had some security experts say it (about things like moving your open mail relay to port 7384 to ‘secures’ it) and it’s the only thing they know about security.
- not_kurt_godel 5y agoI view it as a cost-benefit analysis between implementing security by obscurity versus actual security. If you have real security, then you don't need security by obscurity. If you have security by obscurity, you still need real security. So it's obvious which is a better ROI. That's not to say security by obscurity layered on top can't be useful, such as filtering out noise, but I think the point most people are trying to make is "this thing is not a solution to your security problem, it is a potentially dangerous distraction".
- mindcrime 5y agoIf you have real security, then you don't need security by obscurity. If you have security by obscurity, you still need real security. If "real security" was a real thing and anybody knew how to actually do that, things like the Colonial Pipeline ransom-ware attack, etc. wouldn't happen all the time. As people have been saying since David Lightman in 1983 "Hey, I don't believe that any system is totally secure." That's not to say security by obscurity layered on top can't be useful I think that most people who would implement this (or similar schemes) realize exactly that, and are practicing "defense in depth". Could it be a "dangerous distraction?" Sure, in principle. But I don't see any particular reason that this would be more so than other elements of a "defense in depth" strategy.
- 5y ago
- Godel_unicode 5y agoIn the same way that passwords, private keys, and safe combinations are security by obscurity, sure.
- lucb1e 5y agoExcept that passwords, private keys, and safe combinations cannot be guessed in 0.1 seconds the way that a port can (65k possible values and a SYN packet really isn't large). There is a line to be drawn between high-entropy secrets and using an unpredictable port number.
- Godel_unicode 5y agoWhere are people getting the idea that "listening address" means port number? The title of the page literally says IP address...
- lucb1e 5y agoAh, misunderstanding on my part. For what it's worth, it doesn't say IP address, just listening address which I just took as whatever place (IP,port tuple) it listens on, and unless one has a huge IP range (uncommon with typical setups) I can see how "people" take that to mean port changing by default if they, like me, don't read carefully enough.
- Godel_unicode 5y agoHuge ranges of IPv6 addresses are extremely common, virtually no ISP can be bothered to allocate smaller blocks than a /64. The minimum allocation of addresses recommended is a /32, which is 65k addresses. You also know they don't mean port numbers because there's no such thing as a 6-digit port number. From tfa: """Imagine your SSH server only listens on an IPv6 address, and where the last 6 digits are changing every 30 seconds"""
- n42 5y agoThe "security by obscurity" one-liner is one of my favorite examples of the sort of black-and-white thinking that is harmful to software engineering. The truth is that playing defense is as much an exercise of technical design as it is economics. Yes - if someone finds the SSH port, they have a window of opportunity, and you will be owned if you are not properly securing your server through the normal channels. However, now they only have a small window of opportunity (say, 30 seconds). This does a few things: - it takes time (money) to attack a target. without access to the OTP secret, randomly assigning ports dramatically increases the cost (time) of attacking you. throw in a tar pit and it's even worse. if you're not a high value target, the attacker moves on. - now, any failed authentication attempt to your SSH server is a highly credible threat. repeat attempts are even more suspect - you are being targeted, and they probably have the OTP secret. effectively, you are able to resource your team more efficiently, because you can filter out noise. security is not black and white. if you are a valuable enough target, someone will find a way in. defense in depth helps you manage your defense with limited resources.
- jopsen 5y ago> defense in depth helps you manage your defense with limited resources. Indeed, but might there not better/cheaper ways to secure SSH? Something that doesn't involve custom configuration that needs to be maintained.. like VPN to a jump-host... Or..? Configuring and maintaining custom hacks is not cheap.
- n42 5y agoagreed - I would not deploy this as is, but the idea is interesting and I could imagine the concept being given some UX love in a different application
- SrslyJosh 5y agoI like this analysis, but I'm having a hard time seeing the advantage over port-knocking, which could also be randomized using OTP and would never reveal the SSH server to a port scan. Zero window seems better than a 30 second window. Excellent points otherwise.
- 5y ago
- a1369209993 5y agoNo, the TOTP is[0] a shared-secret bitstream (like a stream cypher), which provides new randomness per use (obscurity means it relies on the attacker not knowing how it works in the first place). This is very weak security, similar to a combination lock or PIN, and should not be used in place of proper SSH crypto, but it is actual security. (The point, IIUC, is to quickly exclude drive-by attackers, so that serious/targeted attacks are higher above the noise floor.) 0: assuming I'm not being overly charitable
- MrStonedOne 5y agosecurity by obscurity and defense in depth are synonyms.
- angry_octet 5y agoNo they are not. It doesn't help to have obscurity in depth.
- staticassertion 5y agoSecurity by obscurity is when you hide implementation details to improve security. Secrets are not obscurity, randomness is not obscurity.
- angry_octet 5y agoExcept that if they know you are using this technique (e.g. from snooping traffic) then it is straightforward to bypass, either by tailgating onto a recent connection attempt (if they can snoop) or just brute forcing it (they can test the whole key space in seconds). There must be better ways to leverage long term shared secrets, recent authentication success, etc. I'd like to see something like Signal's ratchet mechanism.