151–160 of 200 posts
If frequency hopping IPv6 becomes popular, I wonder how long until we start having IPv6 exhaustion problems?
Never. > The [ipv6] address space therefore has 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses https://en.wikipedia.org/wiki/IPv6
Earlier quoted context omitted.
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.
What TCP stacks support TCP-AO? They do support TCP-MD5. That's why.
If frequency hopping IPv6 becomes popular, I wonder how long until we start having IPv6 exhaustion problems?
Never. > The [ipv6] address space therefore has 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses https://en.wikipedia.org/wiki/IPv6
That's not even counting the 65535 ports you could then use.
Earlier quoted context omitted.
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.
However I don't think my server has 600000 years of runtime, or a sane firewall config is gonna allow 1 million connections a second.
Earlier quoted context omitted.
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…
TOTP systems are supposed to implement a sliding window to account for reasonable clock differences, usually within 5 minutes. Devices further off from that really do have a problem, and should not be trusted. I also find it hard to believe that so many devices are so far off, given the ubiquitous access to GPS (atomic clock) signals and NTP on networks. This has been a solved problem for a long time.
Earlier quoted context omitted.
Never. > The [ipv6] address space therefore has 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses https://en.wikipedia.org/wiki/IPv6
If for some crazy reason you wanted to give each byte of memory and storage in a supercomputer its own IPv6 address, you'd be able to scale up to 300 septillion (301,936,594,947,653,725,323,264) nodes, each with 1 terabyte of RAM and 1 petabyte of storage, before IPv6 ran out of individual addresses. That's not even counting the 65535 ports you could then use.
Earlier quoted context omitted.
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.
A very annoying DNS over HTTPS/TLS circular dependency bug manifests itself if your device doesn't have an RTC, or the battery is dead, or the clock is sufficiently skewed. Clock is fucked, so TLS certs don't verify due to validity times, so DNS is broken, so NTP cant look up domains, so the clock can't be set...
On the one hand there's not very much else you can do since you're pointing at bits of thin air and saying "there's the trust chain" in the first place, but on the other hand plaintext DNS is... not much better?
Of course that's when the existential "why even DoH in the first place" starts (with side servings of "this feels so wrong putting it on the security report")...
(...Why do I suddenly feel like disabling certificate verification is going to catch on in a big way in embedded ntpds, almost like a standard best practice... aaaaaaaaa)
Earlier quoted context omitted.
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.
Is there any reference material about the culture of "if it's in the intranet it's safe"? I have had this problem with some enterprise clients, but I would like to have reference material that I can use as an authoritive source. An obvious thing that springs to mind is that the default campus network design that is in all the standard Cisco designs let to basically everything being vulnerable when the last exchange e…
Earlier quoted context omitted.
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.
"Defense in depth" is often quoted when people want to add further complexity to a system. There are cases where adding a security mechanism that adds complexity has a benefit that is so large that it's justified (e.g. adding TLS or ASLR). But it always needs to be balanced, because complexity adds attack surface.
The system linked here seems like it's adding a whole lot of complexity and only has a very weak case to be made for what it's good for.