If you're really looking for a second factor for SSH, why not just use a standard 2FA approach, like a yubikey? Or even just TOTP with PAM? It seems way more effective and way less complex.
Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
91–100 of 200 posts
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#92Reminds me of frequency hopping. https://en.wikipedia.org/wiki/Frequency-hopping_spread_spect... Interesting side-note, one of the people who re-invented this technique was actress Hedy Lamarr who was quite an accomplished inventor
One difference is that, as Bluetooth demonstrates, frequency hopping can be extremely fast at basically no cost. If you have a broad enough spectrum that the attacker needs to cover, that actually makes it harder to eavesdrop by adding a real cost (either a better listener or more listening devices). TOTP, on the other hand, typically allows for many seconds of leeway between the two systems, since there is no direct radio communication between the two systems that they can use to synchronize clocks (in the sense of a clock signal rather than actual timekeeping devices).
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#93There 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.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#94Earlier quoted context omitted.
Your server has NTP. Your client likely, too, if it has enough network to connect to the server. If it does not use NTP, it's easy to set the time within the minute or so required manually.
Hardware clocks are famously unreliable and inaccurate. NTP has failure modes that can result in servers being wildly out of sync with reality. Letting either one of those hose your ability to log in and diagnose/recover the system is a mistake.
It really depends on what you need. Yes, hardware clocks and NTP have failure modes[1], but how common are they? Hosing your bootloader or its ability to find the kernel is also a thing that happens where you definitely need some lower level access, which would also help with a mismatched server clock and TOTP. It depends on a lot of factors whether that is more or less common than NTP failure modes.
Would I employ this for a critical commercial server? No. Would I do so for my private server? Absolutely, without hesitation. If it really loses track of time so badly (hasn't happened yet to my knowledge), I can just log in through virtual console.
[1] I'm excluding drift and inaccuracy, since from my anecdotal experience they are usually not that bad.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#95Make sure your time servers are configured correctly. My department had several Silicon Graphics workstations. Running IRIX, they machines determine amongst themselves which has the most accurate time and they vote that one as the Timemaster. Any new machines added would take their time from the Timemaster. The oldest machine was Timemaster and 8.5 minutes off. Took me week to figure out why my brand workstation had…
TOTP issues related to bogus clocks are soooooo common that I've got my own public TOTP "secret" (so not really a secret) which I use to verify that my various devices running TOTP authenticators have the correct time (my phone, wife's phone, an airline/airgapped device running TOTP etc.).
It's so bad that Google's own authenticator has a "time synch" functionality or something like that in the very TOTP app (and it helps!). This speaks volume as to how bad and how not-solved-at-all the issue of drifting/wrong clocks is.
I much prefer U2F.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#96Stop it with this cloak and dagger BS. Just set a shared secret on it: https://github.com/google/tcpauth (Yes, MD5 is safe for this use) With tcp MD5 your connection is even secured against an active attacker who can sniff. They can't inject, or even RST the connection. Even if they can sniff and spoof everything.
> Yes, MD5 is safe for this use Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according to Wikipedia) cryptographers recommended upgrading to SHA-1 in 1996 already? This project's first commit was well, well beyond the deprecation of MD5. It's a bit safer than but also not entirely unlike putting a Windows 7 on the internet just because there are n…
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 for many things and it’s slowly but surely being deprecated but it doesn’t mean it’s completely broken for every usecase.
Just to be clear I’m not stating that MD5 is necessarily safe for the usecase the GP states it is.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#97Unlike port knocking (which folks seem to be mentioning a lot), this seems like it only has 1,000,000 possible locations that can rapidly be scanned. Knocking has multiplicative growth and so many more possibilities. Perhaps you could include honeypots in the IPv6 range where you’re not bound that block the user, but this seems less reliable overall. I’m sure this is just great fun, but perhaps not something to think…
Port knocking sucks (subject to replay attacks).
Look at Single Packet Authentication. Fwknop is a solid implementation.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#98Earlier quoted context omitted.
> Yes, MD5 is safe for this use Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according to Wikipedia) cryptographers recommended upgrading to SHA-1 in 1996 already? This project's first commit was well, well beyond the deprecation of MD5. It's a bit safer than but also not entirely unlike putting a Windows 7 on the internet just because there are n…
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 never happen and we're stuck with MD5 indefinitely.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#99There 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.
Of course, if you're the one setting up the network it's always secure, it's only if someone else does it that you are vulnerable.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#100Make sure your time servers are configured correctly. My department had several Silicon Graphics workstations. Running IRIX, they machines determine amongst themselves which has the most accurate time and they vote that one as the Timemaster. Any new machines added would take their time from the Timemaster. The oldest machine was Timemaster and 8.5 minutes off. Took me week to figure out why my brand workstation had…
Man. Time based bugs are some of the worst. I spent weeks trying to figure out what was wrong with some of my scripts running under WSL. Apparently wsl Linux kernel had a bug that could cause time to drift by minutes.
My favorite time bug:
Someone on a team I was on spent probably weeks working on a way to process an inbound sensor data stream (which was generated by another bit of software also maintained by us). The data was akin to an odometer, increasing over time based on usage. The trouble was there appeared to be two parallel streams of the same name, which were always offset from each other and while the offset varied they were always roughly close. The algorithm this person came up with eventually sorted them into "thing_1" and "thing_2" streams, at which point it got turned over to me to display. It actually worked pretty well, for what it's worth.
I started asking how am I supposed to show this to a user to make use of, what does this even represent?... but never got an adequate answer. So I started looking at the whole chain, and what I found was the piece of software generating the data had a small bug: it used "hh" instead of "HH" in the timestamp, but also no am/pm. The timestamps were supposed to be 24h and looked like it, but 9:02AM and 9:02PM both came in as "09:02". To confirm, we checked the database and, sure enough, every bit of data was between 1:00am and 12:59pm. In the end we fixed the timestamp bug and threw out the processing code.
It's simultaneously a hilarious date bug, a face-palming colossal waste of time, and a lesson on how not to run technical teams (the manager had no technical skill, and the "team" of ~7 was very siloed and each operated more like teams of 1-2).