I really can't recall. This was back when the original StarCraft first came out. This was in the day where my internet was ISDN or maybe asymmetric 512k cable-modem down and 56k modem up. It was a small size map that had land all around the edges, but the whole center was water, mostly filled with an island that had one fairly short bridge to the outside land at one corner. The island had some crystals, and the outside ring had some at the 2 corners, with the forth corner opposite the bridge being a start point. There might have been a few crystals in other spots, I don't recall exactly.

The trick was that the guy on the outside could do a 'slow rush' if it was done exactly right he could hit the island and win, if the island guy did ANYTHING except build basic units. This was mostly because it was easy to localize your opponents base/hive. Likewise you could work out that the island player could win if the outer player didn't create a way to cut off one of the two routes around the outside at exactly the right time. I don't recall the details perfectly, but I could probably still play it. Once you know the layout of the map its not too hard for a good player to see how to play it and then it comes out a draw most of the time. The really good players could beat you once they figured it out. I think maybe 2 or so players ever beat me cold on it, they must have been truly the very best of the best on Battle.net.

Obviously, this is pretty much tautological. Enough money will solve ANY problem. The truth is no plant is 100% inspected. You can think otherwise and you are wrong. Look at VT Yankee's Tritium Leak problem. They weren't not doing an inspection procedure. The inspections they were doing were NOT FINDING A PROBLEM, and that means that (unbeknownst to the operator) some things aren't being properly inspected. Its not usually a deliberate thing, its simply that you WILL fail to find problems. It happens all the time. As plants age its more and more likely that these hidden problems exist in more and more critical components.

Sorry, I've worked around industrial facilities, including nuclear power plants. Hell, I've stood on top of the core of a research reactor and watched the Cerenkov glow, installed instruments at VY Yankee, etc. Lets just take VY as a good example. They COULD NOT, and DID NOT inspect plumbing underneath the plant (in fact they denied said plumbing even existed). The result was a tritium leak. There are simply pieces of these plants that can't be inspected. Trust me, I know all about ultrasound, x-rays, conductivity, etc etc etc. You can't be sure without putting eyeballs on it. Time and time again that has been proven, and some things we know we can't really inspect.

You can say that if you want, that doesn't make it true. There's clearly stuff inside these plants that nobody can look at and things that are so expensive to replace that building a new plant is cheaper. That's all that's required. You can't replace the pressure vessel on a PWR, not possible.

There are ALWAYS fundamental parts of the structure and inaccessible elements (pipes routing through masses of concrete or running under foundations for instance which are simply impractical to ever replace. In the case of nuclear power plants these things include highly critical parts like steel pressure vessels (which are degraded by neutron capture reactions amongst other things). You may be able to INSPECT these things, but once you deem that they've worn out its just game over, you decommission.

Another aspect of this problem is that it isn't simple to inspect things either. In many cases it can simply be impossible and the things that are hardest to inspect are also likely to be the things that can't be replaced. What ends up happening is that someone makes a model and says "this aught to last 20 years" and 19 years later another guy gets paid by the owner to make a new model that says "this aught to last 40 years". Now, the new model should be realistic, but it may be far less conservative and as we know models aren't perfect.

For this reason the really prudent thing to do is stick with the initial estimates, they're probably the most conservative, and decommission when the design lifetime is reached. Its LIKELY to be a bit conservative but as one poster stated above its all about risk vs reward. Nothing is totally safe or sure, but the longer you run an old nuclear reactor the more likely it is that components will be weakened and compromised. You just never know what sort of unforeseen event is going to then put stress on things. A pipe that was 200% stronger than necessary when it was made and is still 140% stronger than necessary is still now too weak to withstand 180% of its original maximum load. That might be "Never supposed to happen" but a 36 meter tsunami wasn't either. Shit happens.

Exactly. The WHOLE POINT of the door is to make it impossible for anyone to get into the flight deck no matter what.

Exactly, they were having some weird issue that they were trying to understand. They really didn't have anything to communicate with HQ ABOUT, and they had no idea that their actions were liable to cause the aircraft to stall, until it happened, at which point there was no time (or point) to calling for help.

OTOH a long drawn out fire that selectively cripples portions of the aircraft seems quite unlikely to have prevented any possibility of communicating. While it may be true that pilots 'fly first and talk later' they also generally call for help pretty quickly when they can. Its human nature if nothing else to want someone to know what's happening so they can share their predicament. Its not exactly HARD for a pilot to make a radio call. In fact the process of making a distress call is deliberately VERY simple and straightforward. It involves generally pushing a button and talking.

The telling thing is the time frame. I'd buy the fire hypothesis if all of these maneuvers happened in a period of a few minutes and then the plane simply cruised off in some random direction and eventually crashed. That's not what happened though, the plane turned, changed altitude several times over a period of something like 40 minutes, AVOIDING RADAR, and then finally turned onto a course directly for the most remote part of the ocean. Fire simply doesn't explain that.

Fire also doesn't explain which things failed.

The perpetrator (pilot or co-pilot) simply waits for his opposite to go take a leak. Evidence is the event happened right after the sign-off with Malaysian ATC, a good time to imagine someone got up and left the cockpit. The perp then locks the cabin door and can do anything they want from then on, everyone else is just along for the ride. So he cuts cabin air, puts on his mask, climbs to 45,000 ft for a few minutes (not really necessary but maybe he's just being thorough, or maybe he doesn't even do that). Anyway, he's now got a 777 to himself and proceeds to lay in a course for the most god-forsaken part of the southern ocean.

Honestly, how hard is this? Its not like people expect this kind of thing. Its even possible a passenger could have done it. The cockpit door would be closed, but again someone may have come out into the cabin, a sudden unexpected rush by someone strong and quick with some training, they could quite plausibly seize the cockpit and then the same scenario plays out.

You don't turn around, you vector for the nearest runway long enough to stop on and scream for help! There wasn't so much as a single SOS from this aircraft, yet it made several turns and altitude changes, which wouldn't happen with an aircraft that was flying uncontrolled. It just doesn't really add up. Its also VERY unlikely a 777 would continue to fly at all after electrical system damage so extensive that its ACARS, transponder, and all radio systems failed and the flight crew was either killed or completely unable to enter the cockpit. That would require quite a weird and selective type of damage.

How about a hack? Software could do all of that stuff and is a lot more believable than a fire...

Just goes to show, there's no such thing as enough SQA...

I had the most fun with StarCraft back when it FIRST came online. I crafted a small map with an island in the center and a ring of land around it, and one bridge onto the island. One guy started at the outside, opposite from the bridge, and the other started on the island. The funny thing was you could equally well win with any race from either starting position, but you had to know EXACTLY what to do right off, even the most minuscule deviation from the optimum (and not 100% obvious) build pattern would spell certain doom. It was incredibly fun to pick off the really highly rated players. 95% of them would figure it out after the first inevitable loss, but of course I would always blithely agree to reverse positions and beat them again with the equally tricky strategy for the other starting position. It took a LOT of tweaking to get that map perfect, but I think I must have been around 90:1 win:loss ratio on it. Not that this means I was really THAT good, not at all, lol. I bet that map is still floating around somewhere.

The cure for that was in the paper, only specific accounts would be able to perform the initialization. Other accounts can authenticate, but they won't contribute to the initial setup of the vector space.

I suppose in essence you are correct, you could encrypt the whole file. So it just comes down to which is more convenient presumably.

99.9999% of all web applications, even the most incredibly custom stuff, uses a known framework that uses a known type of hashing and a salt that is stored in some standard place. Thus you don't really have to do any super complicated legwork. Even if you aren't SURE what your target is using there aren't that many choices and you can guess that MOST PHP programs use X, and most things deployed on JBoss use Y, and etc. looking at the length and form of the hash can often reduce the problem as well. If you can create an account on the victim system beforehand you have a known plaintext to play with also, which will give you your answer instantly assuming you have the salt or salting algo.

Just store the state of the vector space that corresponds to proper initialization in some sort of HSM. As part of the boot process you load that into memory and you are now initialized and ready to do full-strength authentication. If the startup process for your system is properly implemented this shouldn't present any unusual security problem. Its probably possible to automate this kind of process as well (say if said HSM only outputs data, so it would actually generate a 'boot command' including the vector space state, and send it to the application shell on starup, then the HSM would shut down until your system was reset).

I don't think any of the objections I've seen raised here are really valid. This kind of scheme is certainly more work than simple hashed passwords, but at this point it kinda seems like those aren't really adequate anymore, eh?