Live data from Hacker News

Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

github.com

101–110 of 200 posts

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#101
post #98

Earlier quoted context omitted.

Cryptographers usually recommend switching to function X for usecase Y. Despite SHA1 today and MD5 for even longer being “insecure” for some use cases there are plenty of usecases for which they are still secure and will remain so. The reason for a wide deprecation is that most people can’t evaluate a hash function or an encryption algorithm in context well so it’s easier to say simply don’t use X. RSA is also crap f…

Okay but that doesn't explain why it makes sense to still pick an algorithm that more and more holes are being found in when every library already ships more modern alternatives. It would be better to remove the old MD5 code so we can't accidentally have someone use it for use-cases for which it isn't secure, but if people are pedantic about "but for this case I can still use it! Let me just do that!" that will just…

I’m not going to evaluate if MD5 is safe for “tcpauth” even if I was competent enough to do so.

If confidentiality isn’t a factor (since any hush function that is fast m enough to brute force isn’t going to be particularly secure) and if integrity cannot be compromised through collisions then the hash function is safe for this usecase.

Why use MD5? It’s relatively easy to implement securely m, there are a lot of safe implementations and it’s fast.

This is why CRC32 is still used today also.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#102
post #93

There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first. Before doing something like this I would worry a lot more…

You're against this because it gives a false sense of security and might make people relax other measures, but then you suggest going with an intranet, which is widely known to create a culture of "if it's in the intranet it's safe" which is very detrimental to security as well - thought it was curious.

I am 100% in agreement with you on that point. The most common and risky thing about building an intranet type environment is that it can lead to a false sense of complacency. What is needed is both a belt and suspenders type approach to hardening the daemons and security on individual servers and things that are within the intranet, and also security measures designed to only allow authorized endpoint clients to get into the intranet. Essentially one needs to treat the individual servers and things that are in the private IP space as if they were still facing the public internet, even if they are not.

What you absolutely never want to do is create an environment that is metaphorically like a uncooked egg, after getting through the outer shell layer, things are soft and squishy inside.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#103
post #98

Earlier quoted context omitted.

Okay but that doesn't explain why it makes sense to still pick an algorithm that more and more holes are being found in when every library already ships more modern alternatives. It would be better to remove the old MD5 code so we can't accidentally have someone use it for use-cases for which it isn't secure, but if people are pedantic about "but for this case I can still use it! Let me just do that!" that will just…

I’m not going to evaluate if MD5 is safe for “tcpauth” even if I was competent enough to do so. If confidentiality isn’t a factor (since any hush function that is fast m enough to brute force isn’t going to be particularly secure) and if integrity cannot be compromised through collisions then the hash function is safe for this usecase. Why use MD5? It’s relatively easy to implement securely m, there are a lot of safe…

CRC32 is used for its error detection properties which exceed those of a cryptographic hash of the same length (and, to boot, it's cheaper, too).

There's no reason to choose MD5 over SHA-1. It's less secure and slower and there's plenty of free implementations of SHA-1.

Ideally you'd use SHA-256, because of (smaller) security concerns with SHA-1, but it is a small touch slower than MD5.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#104

There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first. Before doing something like this I would worry a lot more…

> There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login.

Maybe, but I find that simply moving off of default port 22 drops the number of people attacking me by at least two orders of magnitude. That's not nothing.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#105
post #93

There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first. Before doing something like this I would worry a lot more…

You're against this because it gives a false sense of security and might make people relax other measures, but then you suggest going with an intranet, which is widely known to create a culture of "if it's in the intranet it's safe" which is very detrimental to security as well - thought it was curious.

There's a principle in security called "defense in depth". Your servers shouldn't be SSHable from the public Internet, but even if that's bypassed somehow, there should still be other layers of security. Each layer of protection adds security.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#107
post #93

There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first. Before doing something like this I would worry a lot more…

You're against this because it gives a false sense of security and might make people relax other measures, but then you suggest going with an intranet, which is widely known to create a culture of "if it's in the intranet it's safe" which is very detrimental to security as well - thought it was curious.

It is, to say the least, not conventional wisdom among security engineers that simply having network segmentation is detrimental to security. The concepts you're alluding to --- "Beyond Corp" and "Zero Trust" --- are subtle, and heavily cargo culted.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#108

There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first. Before doing something like this I would worry a lot more…

Yeah I suspect that up to date openssh with a config that passes ssh-audit's checks, with a fail2ban config, along with an ed25519 key unlocked by a yubikey will be entirely adequate security for SSH. Then time would be better spent securing VPNs and reducing internal trust. Bit like having a front door that would withstand a C4 blast, but now all your windows are shattered.

Fail2ban is also theater on properly configured SSH servers and has been since it was written.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#109
post #89

Earlier quoted context omitted.

In the same way that passwords, private keys, and safe combinations are security by obscurity, sure.

Except 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.

Where are people getting the idea that "listening address" means port number? The title of the page literally says IP address...

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#110
post #46

Earlier quoted context omitted.

The point is that if the attacker somehold got hold of the primary login credentials (username + key/password), then they can easily bypass this scheme with a port/address scan. This can be done very quick[1] and is hard to rate limit. Furthermore, an attacker that can eavesdrop on the user's connections can infer the OTP since it's being transmitted in the open., but if it was done through a PAM module they wouldn't…

there is no "easily bypassing this scheme with a port/address scan" when it comes to ipv6 /64 ranges. If you could scan 1 million IP addresses a second on a /64 (which is absurd), it would take 600K years to scan a full /64.

1 million IPs per second is doable with gigE if we're just sending a syn to port 22. I'm going to go out on a limb and assume your server has at least gigE.
Post reply on HN