The type of Hungarian notation Spolsky uses at Fog Creek is different than the Hungarian once pushed by Microsoft.
Hungarian notiation (of any variety) started (and ended) at Microsoft.
Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian.
If you're working at Fog Creek you're writing code in a custom in-house programming language as well as using Hungarian notation. I don't think the example is generally useful or applicable to anyone else.
Which would be basically everyone who didn't learn to write software on Windows.
If you have a reasonable type system and language, leverage it to enforce semantics that Spolsky suggests you use Hungarian notation to imply by convention.
You'll be much less likely to be castigated by the individual who has to maintain your code after you. Microsoft has put Hungarian notation to rest, nobody else o speak of uses it, and you shouldn't either.
Not necessarily. What about exploiting VPN clients?
IPSec is a disaster, one aspect of which is having a client daemon listening on an open port for isakmp/ike key exchange.
There's also the configuration to consider. Using PSK or aggressive mode for VPNs can be considered bad but are you really going to deploy a full RADIUS solution just to access a web server?
Provisionally "yes", but I'd actually use OpenVPN, wired into our existing directory infrastructure.
Compare this to using public key based auth on SSH, I know which one I'd rather have for a web server.
Why do you consider it a net win to reduce the entry barrier to only one exploit, one bad user password, or one misconfigured host?
Is a VPN significantly less likely to be exploitable than SSH?
Yes, for a few reasons.
First, a VPN provides defense in-depth -- compromising a server now requires finding two unpatched vulnerabilities:
* You must find a vulnerability in the VPN implementation that allows you to leverage the VPN or the VPN host to forward your traffic.
* You must then find an additional vulnerability to use against the actual secured hosts made available over the VPN connection.
There should be a firewall between the VPN entry-point and your internal networks, to limit access to unapproved services.
As a single point of entry, a VPN is also easier to secure. If all servers are inaccessible except for approved services, then a single server running an unapproved vulnerable service (or an account with a weak password or key) does not open the door to immediate external compromise.
This single entry point also allows you to offset the likelyhood of user failure (such as choosing poor passwords) by using additional two-factor authentication. RSA SecurID or PKCS#11 are often too heavyweight for using every time you want to SSH'ing into a host, but they're far more reasonable for initially connecting to the VPN.
What do you mean by "humbling lesson"? If anyone finds an unpatched flaw and uses it to exploit some servers, then it doesn't matter who takes care of the servers. It doesn't matter if it's ptacek or a random admin. It's a new, unknown problem (if the claim about a 0day is real).
The experts at Matasano should know better than to leave sshd internet-accessible. That's what is humbling, because exposing the smallest possible attack surface is exactly how you defend against an unknown problem, and there's literally no good reason (besides laziness) to leave sshd exposed to the public internet.
Also they're "hacking" the frontend web server. Is that post really interesting in any way? They didn't get to any sensitive information (or didn't publish it). They also didn't get into any personal system, so I doubt there was any real harm done. (otherwise they would brag about it even more)
Or, they simply didn't bother going further -- owning the front-end web server is fairly embarassing for a company like Matasano.
Quite a few individuals store their credentials on front-end web servers, or even SSH to other servers from the front-end servers. Owning -any- server is often a very big deal.
Whether an optimization is worth pursuing depends on the business requirements, how much the it costs to implement, and whether there are any additional gains beyond avoiding power, space, and personnel costs.
Simply picking an efficient (both for the developer, and in terms of implementation) language/platform can be enough to start with, and will help you avoid being boxed in later.
It's not cheap, and you don't have to be Google for it to matter. Most of the time, the costs are just non-obvious to engineering.
Here are some rough numbers.
Power for a single 48U rack usually runs $200-$300/month for two 20amp circuits (possibly +2 for redundancy). A modern 1U server draws anywhere from (roughly) 1.66 to 2.5 amps, and you can only use 80% of a circuit's maximum supported load due to safety regulations, resulting in a total supported count of between 12 to 19 mid-range servers per rack. Higher-end servers have a significantly increased power draw, but potentially higher efficiency, and there can be a significant advantage to leveraging multi-core systems.
In addition to rackspace and power, each server must obviously be connected to the network. The switches draw enough power to potentially decrease the number of supported servers.
Each rack costs roughly $500/month (plus power), and often requires advanced provisioning to ensure that rackspace is available, and if possible, located in the same area. It's not unusual to buy an entire block of space well ahead of actual use to ensure that the business' growth can be accommodated.
Additionally, one requires an operations staff to maintain the servers. Hard drives fail, backups must be done, hardware must be ordered, tested, and finally, deployed. Simple deployment of a single server, including the networking configuration, travel time, and physical work can easily consume 4-8 hours of operations staff time.
When you add together the operational and capital expenditures, I'm not really convinced that the idea is so simple as "servers are cheap, programmers are expensive". Servers, electricity, physical space, and the labor necessary to install and maintain them are not particularly cheap.
I'd propose a new mantra: programmers are expensive, and so are servers and IT, and so let's try to not be monomaniacally flippant about it. Software can be easy to write AND perform reasonably well, and to say otherwise simply appears to be a false dichotomy fronted by those who benefit from it most.
Hungarian notiation (of any variety) started (and ended) at Microsoft.
Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian.
If you're working at Fog Creek you're writing code in a custom in-house programming language as well as using Hungarian notation. I don't think the example is generally useful or applicable to anyone else.