> I thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have?
Are you talking about the secret shared between the NAS and the RADIUS server? It's only used to scramble some attributes (like MS-MPPE-Send-Key), but not all of them. Message-Authenticator is one that's not scrambled. Looking at this FreeRADIUS dictionary file I have, I see 42 out of ~6000 attributes that are scrambled.
Anyway, yeah, if you have a bigass shared secret, it's going to be infeasible to guess. I'm pretty sure that the long-standing very, very strong suggestion for operators has been something like "If you don't co-locate your RADIUS server and your NAS, then you really need have a bigass shared secret, and probably want to be using something like IPSec to secure the connection between the two." [0][1]
> They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges.
Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or other relevant documentation that indicates that this is what's going on?
[0] or WAN and LAN interfaces, if the ports are actually separate, entirely-independent interfaces, rather than bound up in a switch
It's trivial to look up the switch port configuration of a consumer router once you put OpenWRT on it. The most common topology is the CPU has two RGMII/XGMII or similar links to an 8-port switch chip, five more ports of the switch are connected PHYs for external ports and configured for the LAN VLAN, and the last port is connected to a PHY for an external port and configured for the WAN VLAN. This does not result in any VLAN tags being emitted over the wire, but from the perspective of the switch silicon it's just one of many possible VLAN configurations. Changing which physical port is the WAN port is as simple as assigning a different switch port to that VLAN. If you did want VLAN tags emitted on a particular port, it's a single checkbox or single-character config file change.
> Buses have a long tradition of user-hostile design. "Exact change only"...
On every pay-in-cabin bus I've ever ridden, this is synonymous with "No change given". The machines are quite happy to accept more money than is needed for a single ticket, and the reason for that is pretty obvious.
> It has always baffled me why they make it so hard for first-time users in particular.
The SFMTA (the San Francisco bus/train operator) provides a document that addresses almost everything you brought up. [0] The "unhelpful and condescending and impatient drivers" thing isn't addressed, but I've never run into a Muni driver that was anything but helpful. [3] As an added bonus, the most useful information about fares is posted on the paybox inside the bus.
>> Buses have a long tradition of user-hostile design. "Exact change only"...
> On every pay-in-cabin bus I've ever ridden, this is synonymous with "No change given". The machines are quite happy to accept more money than is needed for a single ticket, and the reason for that is pretty obvious....the most useful information about fares is posted on the paybox inside the bus
That's fair, but (1) when I was a kid and starting out riding a bus, I didn't know that; and (2) as that same kid, neither my family nor I had very much money at all and paying "extra" for something is just not something you do. Consider it a cultural thing. "inside the bus" is good but insufficient when I'm deciding between walking a mile or chancing the bus that I don't understand. (I almost always walked the mile. I was cheap, and I hated looking stupid in front of unsympathetic people.)
As for Muni, I didn't live where I could use it until I was no longer that kid. But adult me fully agrees with you. My experience with Muni has been much better than with most other busses I've used.
I see. Your complaint is that in vehicles that are staffed only with a driver, the driver refuses to handle change, and that -in your youth- your parents didn't provide you with any information (whether directly from them, or published by your local transit authority) about how mass transit worked in your area.
There's not much the transit authority can do about your parents' decision to leave you ill-informed. I can tell you that obligating the solo driver to handle change would be significantly user-hostile for the passengers currently on the vehicle. The tradeoff made is the correct one.
As you're probably aware, there's also good news: for a while now, many (most?) transit systems permit payment with radio cards that are linked to a preexisting pool of money, rather than having to handle cash inside the vehicle.
Learning that it was almost always faster to walk from 4th and King to my place in the TL in the three hour period around "rush hour", and often faster late at night -depending on how out of sync the bus and Caltrain arrival times were- was lifechanging in a couple of ways.
Because of Muni's inability to stick to schedule, [0] the Nextbus displays are absolutely essential for making the "Do I walk, or do I wait?" decision. I hate stops that don't have them.
It's a damn shame that the city didn't build many more subway lines during the boom times.
[0] Granted, it's not entirely their fault; they have to contend with SF traffic, too.
> What is the correct number of crazy people you think you should meet on the bus?
As many as you'd expect to meet given how many choose to use the bus to go somewhere.
Retorts:
"Buses shouldn't be mobile homeless shelters." Sure, I agree. But I also agree that someone who has paid their fare and isn't disrupting the safe operation of the bus is entitled to ride the bus. If I want to purchase a ticket and sit my ass down for an hour and a half [0] to watch the city go by, then -assuming there's a seat available for my ass- I'm entitled to do that.
"I shouldn't have to sit next to smelly people." It's not just the poor or crazy that can be smelly. Your diet influences your odor, and some diets make you smell very strongly. Some folks just douse on the perfumes and that sort of thing triggers the migraine headaches of some other folks. As you age, you may lose reliable control of your bladder and bowels. ("Adult undergarments" are a thing people buy for a reason, after all.)
"I shouldn't feel uncomfortable in public." I'm sympathetic, but it's simply a fact of life that you will sometimes feel uncomfortable when around other people.
[0] Last I checked, Muni tickets offer gratis transfers to any other bus or train for 90 minutes after the time of purchase. OTOH, operators rarely check the validity of the tickets of riders, so -IMO- sitting on transit all damn day is fine by me... just so long as you get another ticket if yours is expired and the operator requests that you do so.
As someone who has used very many "cloud providers" (including GCP, AWS, and Azure), it cannot be said that Azure is the most stable. GCP is far better for stability and reliability than Azure.
The extensive experience with Enterprise Authentication that the decades of use of Active Directory has given Microsoft may mean that their SSO and Enterprise Authentication stuff is the best out of those on offer. I wouldn't know about that... I just made (and destroyed) VMs and was often driven to frustration whenever Azure failed to reliably perform that simple task.
There is, yes. The rumor mill suggests that the default limit is 30.
At $DAYJOB, we had a (not very special) special arrangement with GCP, and I never heard of anyone who was unable to create a project in our company's orgs [0].
Given how Google never, ever wants to have a human do customer support, I expect a robot will quickly auto-approve requests for "number of projects" quota increases. I know that's how it worked at work.
[0] ...with the exception of errors caused by GCP flakiness and other malfunction, of course.
As long as you are over a certain spend. I started something for my own project and went to apply the recommended architecture, which does not work without a quota increase. As it was from a fresh account, the email was we won't look at this until you spend or pre spend so much money. Frankly, for a trail period when evaluating at prior enterprises, that would have made me just say no to their cloud. One expects that the recommended architecture can be deployed in the trial run without hoops.
It was pretty sobering when Google demonstrated to me a new and novel way that made them the actual threat to my account security. I thought that by carefully refusing to publish anything with their add-ons (YouTube, Docs, Android Store, etc, etc) that I'd avoid getting swept up in an autoomated account-wide bannination, but, nope. A perfectly ordinary login to the account I'd had for years from the exact same location and IP address I'd used the day before was "suspicious" and required "recovery".
> What should they have done? Just permit everyone to avoid upgrading to 2FA indefinitely?
Yes. I've had online accounts for nearly as long as there's been an "online". The only time I've ever lost control of an account was due to 2FA.
2FA should always be optional for one's personal accounts. [0] People who can securely manage passwords simply don't need it. And if Organized Crime or Mossad wants access to my accounts, 2FA is not going to stop them.
[0] Corporate accounts and hardware are a different matter. You manage those however your employer commands you to manage them.
If the government is being too obvious about the fact that the entity in question is nothing more than its puppet, then something can be done about that. Entities that are government entities in everything but name can be considered to be government entities and become subject to all the relevant restrictions. There's some fancy-ass phrase for this, but I can't remember it at the moment.
Also, the third-party doctrine hasn't been good enough for certainly the last thirty and maybe the last hundred years. But, authoritarians aren't easily separated from their tools of oppression, so I expect to not see that cluster of regulations updated to be actually protective within my lifetime.
Are you talking about the secret shared between the NAS and the RADIUS server? It's only used to scramble some attributes (like MS-MPPE-Send-Key), but not all of them. Message-Authenticator is one that's not scrambled. Looking at this FreeRADIUS dictionary file I have, I see 42 out of ~6000 attributes that are scrambled.
Anyway, yeah, if you have a bigass shared secret, it's going to be infeasible to guess. I'm pretty sure that the long-standing very, very strong suggestion for operators has been something like "If you don't co-locate your RADIUS server and your NAS, then you really need have a bigass shared secret, and probably want to be using something like IPSec to secure the connection between the two." [0][1]
[0] <https://datatracker.ietf.org/doc/html/rfc3579#section-4.3.3>
[1] <https://datatracker.ietf.org/doc/html/rfc3579#section-4.2>
reply