There is also the UNIX philosophy. The endless chain of reboots was especially horrid in the 95/98/ME days where if one wanted an IP address change, or some other network item, reboot time.
UNIX machines historically were rarely rebooted, unless someone was dropping the box into single user mode for level 0 dumps and a guarentee that no other programs were touching the filesystems.
In general, there was only one reason for an unplanned UNIX reboot, and that was a dead NFS handle which locked up a machine. Almost everything else (except security or hardware issues) could wait until the next downtime window.
Oh, don't get UNIX people started about reinstalls. IMHO, only times a machine should ever be reinstalled are after a hardware failure, after a major security breach, or if going to a major version of an OS, where an upgrade would leave a ton of useless and potentially dangerous amount of cruft behind. Even in most of these cases, a bare metal restore is better than a reinstallation so that applications don't have to be reinstalled, retuned, and reconfigured.
3.x Netware was pretty darn bulletproof, provided you didn't mind copying the Bindery stuff to every different server, and one had to use IPX or nothing.
There are three things from it that were notable:
1: If a user doesn't have access to something, it doesn't show up in a listing. No directories or files with "access denied" messages, just making them more curious.
2: The OS was simple and had very limited functionality. Want some feature? Buy a third party NLM. Netware 3.11 had next to no attack surface.
3: The console commands kept the riffraff out. No point and drool interface. To use it, you had to at know the basics of what you were doing.
The one thing I wish was passed on to modern operating systems was feature #1. Out of sight, out of mind. If a directory isn't shown, a user won't bother trying to get access to it, as opposed to something saying "permission denied".
Re:Does anyone know if this leads to a soft-hack
on
Hardware TPM Hacked
·
· Score: 2, Interesting
My question:
Would a mass produced chip that is on a lot of business PC motherboards, and which is stated to have little to no physical resistance to attack have all this? TPMs are not that expensive, so I'm sure they would not have near the physical anti-tamper technology that a CAC, a smart cartd, an IBM crypto PCI card, much less a 3U HP HSM would have.
I do know what not to do. When someone estimates a programming job in number of beers, I get worried. If someone says that a security patch to an existing application is a one beer job, then I hope for the best, and that regression testing and QA catch anything new that cropped in.
There is another fact: When people start getting nailed for stuff they did in the past, others will get wind of it. What will happen then is that there will be a mass switchover to VPN services. Offshore VPN services. And because people will pay good money per month for this, someone in some country will be happy to lay the fiber and drop in the servers so Americans can browse their pr0n without the fear of being eavesdropped on.
Already, as a consultant, I have had SMBs ask me about a company-wide tunneling of their outgoing Web traffic to an offshore proxy, so if their competition managed to nab router logs from a peer or ISP, they wouldn't be able to tell what employees are researching for product development. TOR nodes are not a solution for this because of the sheer bandwidth of the traffic involved (no P2P stuff, but video and other things.) So, for a high bandwidth bridge to help anonymize traffic, I ended up dropping a beefy server at a coloc and having all their outgoing traffic go to that. I know the coloc's policy on traffic, and since that is a sane one [1], essentially everything from the VPN on out is pretty secure.
So, if the FBI and other places push and get ISPs to start logging, they will end up starting an arms race that they might be able to win (especially with multi-national treaties like ACTA on their side and bans on cryptography), but it will be at best a Pyrrhic victory. At the worst, people will start doing point to point mesh connections and start bypassing the Internet altogether.
My question: It is understandable to hold logs for LEO needs. I'm not concerned with this. I am gravely afraid of backdoors which allow not just legit law enforcement access... but blackhats who find these doors (and trust me, they WILL find them especially with the deep pockets that a lot of blackhat organizations have) and are able to mount attacks through it and the only thing that can be done by law abiding citizens or businesses is to yank the Ethernet cord and pull off the Internet altogether.
[1]: The coloc in question holds basic logs for a few days, and they won't be given out unless they get an official court order. Not a request or a post-it note, but an official court document served by a constable. They even have a SLA/privacy guarantee on this. It may not be bulletproof, but it at least is better than no privacy policy or contract at all.
XP does not have a protected mode. The next best thing would be to run a virtual machine utility and browse in that. Then when done browsing, close the VM and have all changes rolled back to the previous snapshot. If you want bookmarks preserved, put that directory on another virtual drive that keeps its state (and doesn't get rolled back like the system.)
Barring running in a VM, you can create a non-admin user in XP, switch to that for your Web browsing, and only use that user for browsing. Your sensitive documents and such would remain on your main user.
Devil's advocate: The parent AC post stated one of the biggest reasons why IE is prevalent. The other is that IE is part of the OS. Because of this, it is already vetted by the legal eagles, the licensing bean counters, and the other muckety-mucks you find in larger companies. There is no need to get IE approved as part of an official corporate image, because it is present, like it or not. So, companies tend to use it because it is there, it has decent security on Vista and Windows 7 (especially combined with DEP), and can be controlled by GPOs.
My concern is that CAs are a single point of failure, and because there are so many eggs in the CA basket, eventually some blackhat organization will find a way to compromise one. This compromise can be remote attacks, or if the stakes are high enough, blackmailing one of the core employees to allow access to the HSM (hardware storage module) for signing a few certificates from Elbonia off the record.
One idea is to have the Web browser store the hash of the previously used certificate that the domain used. So when someone visits bank.com, if the cert is the same, it will just go through. If it is different (or if this is the first time a user visited the site), it will check the CA, perhaps check a web of trust to see if that certificate is genuine or bogus, and give the user info that way. For most users, just an info bar similar to the one in Firefox for remembering passwords may be enough.
Of course, I'd like to see self-signed certs accepted without question. However, just as other people have stated, the Web browser just wouldn't show a lock icon unless someone adds the cert into a trusted database. This would force attackers who wanted to sniff passwords to go from passively eyeballing the wire into having to actively MITM connections.
I see this with both the GIMP and OOo. People market them as Photoshop or OOo clones. However, they are not. Marketing them as clones always puts them forever into catchup mode, trailing Microsoft or Adobe.
I'm not a dedicated artist, so for what I do, the GIMP is an excellent tool. It does what I need it to, be it resizing pictures, changing formats, some basic touch-up work.
OOo is similar. Base is an excellent utility for small database applications (I use it for names/character/places for my SF writings.)
The key is to offer the product as another tool for the job. For example, for a bolt, I can use a socket wrench, a crescent wrench, an adjustable wrench, or a set of pliers. Open Office should be pitched as a crescent wrench to extract a bolt. Not a socket wrench clone. Different type of tool, but the job gets done (ceteris paribus.)
Perhaps merging a PGP-like web of trust interlink with SSL security. So, if a close friend trusts foo.com as a CA, then the Web browser would assume that. If a friend dislikes blarf.com, the Web browser will pop up something saying that the CA isn't that liked among friends.
Problem is that for/. readers, a system like this would make perfect sense. However, most people seem to just want to connect to a site, see a little padlock icon and assume that they can log into their bank safely. They don't care about CAs, web of trusts, CRLs, SLCs... just that they can access whatever with some reasonable security.
What is ironic is that I can do this in IE with no problems. I drag a certificate to the untrusted store, either systemwide or as a user, and even if root certs are updated, that cert remains untrusted.
One time pads are truly secure, but the hard part is getting a copy of the OTP from Alice to Bob via a secured route, as anyone who intercepts it has full and unfettered access. Also, depending on the amount of data transferred, the amount of bytes stored on the OTP might run out.
Instead, if you are designing a cryptosystem where the two endpoints are "introduced" to each other, and essentially only talk to each other, so public key cryptography isn't needed, there is one method you can do:
Each device "knows" about the other and has 1024 bits that only it and the other device has. (This can be copied manually via a USB flash drive, or the devices could be temporarily connected and they negotiate this info.)
Then, the devices can do a basic Diffie-Hellman handshake, except encrypted with the first 256 bits, and another 256 bits used for the initialization vector (if needed). Once both sides negotiate a session key, before that key is used, it is encrypted using the last 512 bits as a key/IV. This way, even if someone is able to figure out the first key used to encrypt the D-H handshake, the session key is still unguessable without a major break in the cryptographic algorithm, or a compromise of one of the endpoints.
The advantage of this setup is that it is quick -- public key cryptography is computationally intensive. The disadvantage is that this system only works with a small amount of devices before it becomes unwieldy, similar to hosts files.
Even better might be having a cryptographic token, either something like a SecurID card except with a replacable battery, or a USB smart card that stores a private key on board. This way, an authorized user just needs to dig out the keyfob, jam it in a port or type in the 6-8 digit number plus the password as mentioned above, and access is granted. A remote attacker most likely would not have physical access to the cryptographic token, so that slams the door on a lot of attacks right there, forcing the blackhat to do a brute force attack, which can be mitigated by adding delays, or locking out the incoming IP for a period of time.
Easy way to relate serial numbers to passwords: Append a secret value to the S/N, hash the value (SHA-512 comes to mind), take the first x number of characters (preferably more than 20, 64 would be best). This way, the serial number doesn't really matter because without the nonce added, it won't give meaningful information.
Of course, the machine that has the secret value (and I hope this is something that changes with each model), is going to be heavily locked down.
Another good method is just to use a 1:1 hash mapping. The serial gets mapped to a random value, and that mapping is stored in a database. This way, there is absolutely no way to calculate one value from the other.
Ultimately, it would be nice to have an OS independant repository. It would have to work like DNS where one connects to a core server, gets pointed to the application vendor's repository (or an OS repository), then the app vendor points to the URL. This way, the damage done by a damaged root repository "pointer" would be minimized, especially if vendors used signing keys and all requests were done via SSL.
This way, a user-mode program could automatically check what is installed, grab a list of where to get URLs of updates, download them, and tell the user to log on as an admin and install these. Or it can be run with Administrator or root authority, and do it automatically.
Companies and organizations can set the root server to be pointing to an internal machine, so patches could be approved in a test environment before propagating to production servers (similar to WSUS.)
There is a reason for that. In a lot of corporations, getting *any* third party application approved for a system image takes a lot of time and trouble. It has to go past the licensing bean counters, the legal team (proper idemnification to prevent patent lawsuits is a big concern), a deployment team, a team whose job it is to minimize software maintainence (time spent updating third apps == less profit), etc. So, because IE is included with the OS, it, in a sense, is already vetted and is already ahead of other Web browsers when it comes to the signoff hurdles by the PHBs. IE is already licensed with the OS, and because it is part of Windows, it gets vetted by internal departments.
Of course, there are ways to package and use other browsers, even in environments where system images have to be completely locked down. VMWare's ThinApp is one of the more elegant solutions to this I have seen.
The good thing is that IE8 is at least decent security, especially on Vista and newer where it runs in a sandbox. This doesn't stop attacks, but it forces attackers to have to jump one more hurdle before they get control of that user's context.
What Web browser and OS designers should start focusing on isn't just the Web browser as the core of security. What attackers are going after are the add-ons. Because add-ons store persistant user info, have access to the filesystem, and can run binary code directly on the platform, all it takes is a simple buffer overrun, and an add-on can give full user (or even worse, Administrator/root) access to a blackhat. Until add-ons are corraled in a secure sandbox by a combination of the Web browser (for rendering), and the OS (to ensure a process's context is not going to be able to affect others), it will be a whack-a-mile game with finding and stomping browser/add-on exploits.
Until then, perhaps the most secure solution (next to AdBlock and NoScript in Firefox) would be running the Web browser as a user in a VM, and having the VM roll back all changes when closed. This way, malware would have to get user context, get admin authority, then find a way to bust out of the hypervisor to the host OS. All possible, but very tough. On a BSD, running the VM emulator software in a jail and using ZFS to roll back the directory structure to a saved snapshot would provide even more security even if the VM got compromised.
The civilian applications of this are tremendous too. SAR (search and rescue) support in areas where even motorcycle transport is dicey (Moab, etc), moving portable gear (generators if the mule can carry them) to a desolate area after a disaster. Additional help for hikers to carry stuff to and from a remote camp. A group of hunters can send a robot back to main camp to pick up another set of kegs, so the main partiers don't have to stumble down a trail at night.
Security isn't about how hardened your OS is, although it is a crucial ingredient (if you have bad apples, a chef can't make a good apple pie no matter how good. However, a bad chef can take perfectly good fruit and make something horrid.)
What is lacking in a lot of companies is an actual security policy. Encryption is the easy stuff. Making sure there is a department-wide policy, making sure users adhere to it, and keeping some type of mechanism in place for recovery if an employee leaves is what is tough, and what a lot of companies will refuse to pay the bucks for.
First line of security are the tools: You have firewalls, IDS systems, routers, and content filters to protect the network side. You have security guards, HID locks, Abloy PROTEC locks for backups, CCTV cameras, and alarms for the physical security. For data at rest protection, you have BitLocker, LUKS, EncFS, PGP, TrueCrypt, PointSec, or other mechanism to store data encrypted. For backups that go offsite, you have your hardware do the encryption (HP LTO-4 drives), or have the software have the government certified AES libraries (Retrospect, Backup Exec, TSM, Networker).
However, you can be sitting on the best tools in the world, but if they are not used in a coherant form by clued employees, they won't help things. For example, a machine could be protected with PGP and require a smart card to boot it. However, if the machine doesn't have a firewall or protection from network attacks, the DAR (data at rest) protection is pointless. Similar if a laptop has extreme antivirus utilities, but is always left in coffee shops unattended.
Obligatory car analogy: A company can pay millions for a fleet of semis, but without competant drivers, they will just sit in the parking lot and not do a thing.
Security isn't something you can just buy off the shelf. You can buy tools, but it takes expertise to implement everything into a solid security gestalt that is workable and protects company (and employee) assets.
Physical volume isn't that big an issue (assuming a cartridge size that can fit in a hand and be easily shuttled around by a tape robot). In fact, people touted DLT/LTO as more reliable because it was a larger format so it could store more, compared to 8mm/AIT. They also touted that the linear scanning of tracks was more error-tolerant than the helical heads.
To make sure: Tape isn't for everyone. A tape drive that holds a reasonable amount of data (800 gigs native or more) will cost you $4000. For a SOHO or a small business, they might be better off cost-wise by buying a bunch of USB/IEEE1394/e-SATA drives and use those for storing backup sets, rotating drives in and out for offsite security.
For a lot of people, a microSD card is enough for a basic backup. However, what might work for one person may not even be useful for another. For example, I don't just like backing up documents, but my whole desktop. This way, if a hard disk fails, I can restore to a known good image, bare metal instead of spending time reinstalling the OS, reinstalling apps, and finding all the documents.
Very true. However, you have one drive/library/rack, and one set of tape heads, for a large number of tapes. This means the total moving parts in a storage pool is far lower compared to a backup set consisting of a box of hard drives. If a tape drive dies, it is expensive, but it can be replaced and generally not cause loss of data. The media is separate from the reader. If the heads die on a hard disk, you are facing a very expensive recovery process if anything is stored on that drive that is wanted.
The biggest issue with tape is keeping the density and cartridge capacity up. Even though tapes and magnetic hard drives share a lot in common, storing data on rust is where the similarities end. Tape media contacts the head and is read while the head is contacting, as opposed to HDDs which float very close to the surface of a disk. So, the material the magnetic domains are on has to be sturdy enough for physical contact. Tape does have an advantage that it has more space to store data than a disk platter. However, a lot of that space is taken up by error correction, since there is no way to relocate bad sectors on the fly with tape, and if a block goes bad, it goes bad, no way to recover without ECC, or a way to duplicate the lost data.
What tape has over hard disks is simplicity. A DLT or LTO-5 tape has one reel for a moving part. Compare that to a hard disk which has the platters, the heads, the wires, and the motors. Drop a tape, and it almost certainly is recoverable. Drop a hard disk, and a person never knows if the hard drive is completely dead, or will die very soon due to the impact. This is also important when it comes to archiving. Tapes, you can put in their cases, drop them axis vertical in an Iron Maiden tub, and your data is secure. With hard disks, you have to put them in padded boxes to help dampen vibrations which can kill the drive.
Tape drive makers are also responding to the clarion call of encryption. HP's LTO-4 line supports SPIN/SPOUT encryption capabilities. You can set it to use the same passphrase on multiple tapes, or use backup software which sets a different key on each tape and manages which key goes to which tape for better security. Software like Retrospect, Backup Exec, or bru also offer AES encryption with libraries certified by the US government. So, a tape backup is decently secure.
Tapes can be set to be read-only. This is important because it means that a tape read on a compromised machine won't be able to be tampered with. Some tape systems (DLT) offer WORM functionality to allow for secure archiving of data with the data cryptographically signed by the tape drive. This is important when one has to deal with HIPAA and archiving of data for 7 years, or the FAA and archiving airplane data for 50 years.
Tapes are fast. This is also one of their weaknesses. If you don't feed them the full amount of their pipeline, the tape drive has to stop and reverse. "Shoe-shining" is not good for tape life, nor the life on heads. So one needs to have tape drives preferably on a computer with the I/O paths to handle it [1].
Finally, once you buy the drive, tapes are the best bang for byte you can get. Even older tape formats like LTO-4 that give 800 gigs native for $40 is still fairly cheap for the capacity.
[1]: Ideally, the best use of tape is a network backup server with a good RAID array. You back the machines up to the array, then copy the data to tape. This way, network glitches do not slow down the data being slapped on the tapes.
One thing that got US farmers out of the Dust Bowl days (the main thing being the end of the multi-year drought) is using crop rotation techniques. It is sort of ironic that that same lesson will have to be learned by farmers again, when oil becomes too expensive to use as fertilizer. Since we are past peak oil, it really is only a matter of time.
What would separate a RPG from the RTS are decisions leading to different campaigns. Say you have a band of chainsaw fencers. You can take out the drow outpost, or the human citadel. Depending on which group's outpost gets the beatdown, the rest of the game will have campaigns that go either way. The next mission would either help a drow spider-queen secure her new outpost, or you fight with the humans to push out invaders to reclaim claim ancient breweries.
In general, a RTS campaign is linear. Modern RPGs have many branches, side quests, and endings. (Always exceptions... Final Fantasy, for example.)
This has been going on for a long time. If one stretched things, they could say that World of Warcraft is a FPS with an extreme number of powerups. However, FPS is a concept is a known quantity. You put out something in this type of genre, and you will almost certainly break even at the minimum.
Finding new ways to do a RPG combat system is hard. There are not that many ways to do combat, so FPS mechanics is one of the most used. Turn by turn combat used to be the RPG mainstay, but for many people, it is too slow a method of resolving conflict. There are other combat systems, but if a game relies too much on arcade reflexes, it might turn people away.
For single player, most likely the best bet for a modern RPG these days would be a system used by NWN and NWN2, where people can pause the action before making their next decision, but if they know what exactly is going on, can still do an almost real-time battle.
What I've not seen that much of are RPGs with RTS mechanics. Picture having your group of people that you start out with at a beginning of the game, and each of them has some ability and weakness. There would have to be more plot and character development for an RPG to separate it from Warcraft 1-3 (adding multiple endings, having side quests), but it could be done.
One scenario using these type of mechanics could be pushing back some orcs [1] who are pillaging some nearby villages. You send in some scouts to see what exactly their weaknesses are (one village has an orc wizard fireballing buildings. Another has an orc chieftain who keeps his band up with heals. Still another has a warrior chieftain.) Then you send whatever guys you have that would be the best against the type of enemy at hand. With different playstyles, one could have a lot of grunt troops and just swarm the villages, send in ranged troops (with some melee in front as a distraction), or perhaps even find a way to use some type of negotiating skill to get the orc tribal leaders to accept a keg of ogre swill as treasure enough so they stop their invasion.
Another scenario could be a castle siege. You have your forces and need to punch a hole in the castle walls, while fending off forces coming from other sides. Part of the RPG would be doing side quests. One side quest earns you better siege engines. Another gets enemy troops to not join in on the fight. Still another side quest just might allow the player to earn such a famous/infamous reputation that they can just bypass the siege altogether and have the opposing side open the doors and surrender.
This isn't to say this has not been done before, but RPG/RTS mechanics are not something seen often in modern games. What sets RPGs apart from "plain old" RTS/FPS games is having multiple endings, multiple side quests, and different consequences for player actions. For example, if a PC is an extremely good diplomat, it may allow for some battles to be skipped or handled in a different way. Similar if a PC does side quests for a reputation. Throwing in some mini-games [2] may be the answer here as a way to help (perhaps use the RTS engine so the player can work as a mercenary general in order to help your side get land or resources in between plot advances.)
[1]: Classic AD&D/LoTR orcs which would be more than happy to stuff any intelligent race in a stewpot. Except dwarves. They are just too hard to clean.
[2]: One recent mini-game I liked was the Risk-like one in James Cameron's "Avatar". It was fairly tough because you had very little territory at the start, so you could either play your chances slowly, or start the mini game every so often, because you got more money as the main game progressed. Mini games have to be done right though. For example, the card one in FF8 a lot of players just skipped for the most part.
I just considered it a movie. No more. There are a lot of people drawing parallels between the RDA and $group_in_authority and the Na'vi and $persecuted_group. However, I'm sure with any popular movie which isn't using the same stale IP as before, this could be put into place. People alluded the Empire in Star Wars to groups in real life when that debuted.
"Avatar" is a movie, a piece of sci-fi. No more. The RDA doesn't symbolize US marines any more than the UAC space marines in Doom: The Movie.
To me, I was more puzzled by how a race of hunter/gatherers have absolutely perfect teeth to a person, than seeing that fictional sides in a sci fi movie related to real life groups.
Slashdot Mirror
There is also the UNIX philosophy. The endless chain of reboots was especially horrid in the 95/98/ME days where if one wanted an IP address change, or some other network item, reboot time.
UNIX machines historically were rarely rebooted, unless someone was dropping the box into single user mode for level 0 dumps and a guarentee that no other programs were touching the filesystems.
In general, there was only one reason for an unplanned UNIX reboot, and that was a dead NFS handle which locked up a machine. Almost everything else (except security or hardware issues) could wait until the next downtime window.
Oh, don't get UNIX people started about reinstalls. IMHO, only times a machine should ever be reinstalled are after a hardware failure, after a major security breach, or if going to a major version of an OS, where an upgrade would leave a ton of useless and potentially dangerous amount of cruft behind. Even in most of these cases, a bare metal restore is better than a reinstallation so that applications don't have to be reinstalled, retuned, and reconfigured.
3.x Netware was pretty darn bulletproof, provided you didn't mind copying the Bindery stuff to every different server, and one had to use IPX or nothing.
There are three things from it that were notable:
1: If a user doesn't have access to something, it doesn't show up in a listing. No directories or files with "access denied" messages, just making them more curious.
2: The OS was simple and had very limited functionality. Want some feature? Buy a third party NLM. Netware 3.11 had next to no attack surface.
3: The console commands kept the riffraff out. No point and drool interface. To use it, you had to at know the basics of what you were doing.
The one thing I wish was passed on to modern operating systems was feature #1. Out of sight, out of mind. If a directory isn't shown, a user won't bother trying to get access to it, as opposed to something saying "permission denied".
My question:
Would a mass produced chip that is on a lot of business PC motherboards, and which is stated to have little to no physical resistance to attack have all this? TPMs are not that expensive, so I'm sure they would not have near the physical anti-tamper technology that a CAC, a smart cartd, an IBM crypto PCI card, much less a 3U HP HSM would have.
I do know what not to do. When someone estimates a programming job in number of beers, I get worried. If someone says that a security patch to an existing application is a one beer job, then I hope for the best, and that regression testing and QA catch anything new that cropped in.
There is another fact: When people start getting nailed for stuff they did in the past, others will get wind of it. What will happen then is that there will be a mass switchover to VPN services. Offshore VPN services. And because people will pay good money per month for this, someone in some country will be happy to lay the fiber and drop in the servers so Americans can browse their pr0n without the fear of being eavesdropped on.
Already, as a consultant, I have had SMBs ask me about a company-wide tunneling of their outgoing Web traffic to an offshore proxy, so if their competition managed to nab router logs from a peer or ISP, they wouldn't be able to tell what employees are researching for product development. TOR nodes are not a solution for this because of the sheer bandwidth of the traffic involved (no P2P stuff, but video and other things.) So, for a high bandwidth bridge to help anonymize traffic, I ended up dropping a beefy server at a coloc and having all their outgoing traffic go to that. I know the coloc's policy on traffic, and since that is a sane one [1], essentially everything from the VPN on out is pretty secure.
So, if the FBI and other places push and get ISPs to start logging, they will end up starting an arms race that they might be able to win (especially with multi-national treaties like ACTA on their side and bans on cryptography), but it will be at best a Pyrrhic victory. At the worst, people will start doing point to point mesh connections and start bypassing the Internet altogether.
My question: It is understandable to hold logs for LEO needs. I'm not concerned with this. I am gravely afraid of backdoors which allow not just legit law enforcement access... but blackhats who find these doors (and trust me, they WILL find them especially with the deep pockets that a lot of blackhat organizations have) and are able to mount attacks through it and the only thing that can be done by law abiding citizens or businesses is to yank the Ethernet cord and pull off the Internet altogether.
[1]: The coloc in question holds basic logs for a few days, and they won't be given out unless they get an official court order. Not a request or a post-it note, but an official court document served by a constable. They even have a SLA/privacy guarantee on this. It may not be bulletproof, but it at least is better than no privacy policy or contract at all.
XP does not have a protected mode. The next best thing would be to run a virtual machine utility and browse in that. Then when done browsing, close the VM and have all changes rolled back to the previous snapshot. If you want bookmarks preserved, put that directory on another virtual drive that keeps its state (and doesn't get rolled back like the system.)
Barring running in a VM, you can create a non-admin user in XP, switch to that for your Web browsing, and only use that user for browsing. Your sensitive documents and such would remain on your main user.
Devil's advocate: The parent AC post stated one of the biggest reasons why IE is prevalent. The other is that IE is part of the OS. Because of this, it is already vetted by the legal eagles, the licensing bean counters, and the other muckety-mucks you find in larger companies. There is no need to get IE approved as part of an official corporate image, because it is present, like it or not. So, companies tend to use it because it is there, it has decent security on Vista and Windows 7 (especially combined with DEP), and can be controlled by GPOs.
My concern is that CAs are a single point of failure, and because there are so many eggs in the CA basket, eventually some blackhat organization will find a way to compromise one. This compromise can be remote attacks, or if the stakes are high enough, blackmailing one of the core employees to allow access to the HSM (hardware storage module) for signing a few certificates from Elbonia off the record.
One idea is to have the Web browser store the hash of the previously used certificate that the domain used. So when someone visits bank.com, if the cert is the same, it will just go through. If it is different (or if this is the first time a user visited the site), it will check the CA, perhaps check a web of trust to see if that certificate is genuine or bogus, and give the user info that way. For most users, just an info bar similar to the one in Firefox for remembering passwords may be enough.
Of course, I'd like to see self-signed certs accepted without question. However, just as other people have stated, the Web browser just wouldn't show a lock icon unless someone adds the cert into a trusted database. This would force attackers who wanted to sniff passwords to go from passively eyeballing the wire into having to actively MITM connections.
I see this with both the GIMP and OOo. People market them as Photoshop or OOo clones. However, they are not. Marketing them as clones always puts them forever into catchup mode, trailing Microsoft or Adobe.
I'm not a dedicated artist, so for what I do, the GIMP is an excellent tool. It does what I need it to, be it resizing pictures, changing formats, some basic touch-up work.
OOo is similar. Base is an excellent utility for small database applications (I use it for names/character/places for my SF writings.)
The key is to offer the product as another tool for the job. For example, for a bolt, I can use a socket wrench, a crescent wrench, an adjustable wrench, or a set of pliers. Open Office should be pitched as a crescent wrench to extract a bolt. Not a socket wrench clone. Different type of tool, but the job gets done (ceteris paribus.)
Perhaps merging a PGP-like web of trust interlink with SSL security. So, if a close friend trusts foo.com as a CA, then the Web browser would assume that. If a friend dislikes blarf.com, the Web browser will pop up something saying that the CA isn't that liked among friends.
Problem is that for /. readers, a system like this would make perfect sense. However, most people seem to just want to connect to a site, see a little padlock icon and assume that they can log into their bank safely. They don't care about CAs, web of trusts, CRLs, SLCs... just that they can access whatever with some reasonable security.
What is ironic is that I can do this in IE with no problems. I drag a certificate to the untrusted store, either systemwide or as a user, and even if root certs are updated, that cert remains untrusted.
One time pads are truly secure, but the hard part is getting a copy of the OTP from Alice to Bob via a secured route, as anyone who intercepts it has full and unfettered access. Also, depending on the amount of data transferred, the amount of bytes stored on the OTP might run out.
Instead, if you are designing a cryptosystem where the two endpoints are "introduced" to each other, and essentially only talk to each other, so public key cryptography isn't needed, there is one method you can do:
Each device "knows" about the other and has 1024 bits that only it and the other device has. (This can be copied manually via a USB flash drive, or the devices could be temporarily connected and they negotiate this info.)
Then, the devices can do a basic Diffie-Hellman handshake, except encrypted with the first 256 bits, and another 256 bits used for the initialization vector (if needed). Once both sides negotiate a session key, before that key is used, it is encrypted using the last 512 bits as a key/IV. This way, even if someone is able to figure out the first key used to encrypt the D-H handshake, the session key is still unguessable without a major break in the cryptographic algorithm, or a compromise of one of the endpoints.
The advantage of this setup is that it is quick -- public key cryptography is computationally intensive. The disadvantage is that this system only works with a small amount of devices before it becomes unwieldy, similar to hosts files.
Even better might be having a cryptographic token, either something like a SecurID card except with a replacable battery, or a USB smart card that stores a private key on board. This way, an authorized user just needs to dig out the keyfob, jam it in a port or type in the 6-8 digit number plus the password as mentioned above, and access is granted. A remote attacker most likely would not have physical access to the cryptographic token, so that slams the door on a lot of attacks right there, forcing the blackhat to do a brute force attack, which can be mitigated by adding delays, or locking out the incoming IP for a period of time.
Easy way to relate serial numbers to passwords: Append a secret value to the S/N, hash the value (SHA-512 comes to mind), take the first x number of characters (preferably more than 20, 64 would be best). This way, the serial number doesn't really matter because without the nonce added, it won't give meaningful information.
Of course, the machine that has the secret value (and I hope this is something that changes with each model), is going to be heavily locked down.
Another good method is just to use a 1:1 hash mapping. The serial gets mapped to a random value, and that mapping is stored in a database. This way, there is absolutely no way to calculate one value from the other.
Ultimately, it would be nice to have an OS independant repository. It would have to work like DNS where one connects to a core server, gets pointed to the application vendor's repository (or an OS repository), then the app vendor points to the URL. This way, the damage done by a damaged root repository "pointer" would be minimized, especially if vendors used signing keys and all requests were done via SSL.
This way, a user-mode program could automatically check what is installed, grab a list of where to get URLs of updates, download them, and tell the user to log on as an admin and install these. Or it can be run with Administrator or root authority, and do it automatically.
Companies and organizations can set the root server to be pointing to an internal machine, so patches could be approved in a test environment before propagating to production servers (similar to WSUS.)
There is a reason for that. In a lot of corporations, getting *any* third party application approved for a system image takes a lot of time and trouble. It has to go past the licensing bean counters, the legal team (proper idemnification to prevent patent lawsuits is a big concern), a deployment team, a team whose job it is to minimize software maintainence (time spent updating third apps == less profit), etc. So, because IE is included with the OS, it, in a sense, is already vetted and is already ahead of other Web browsers when it comes to the signoff hurdles by the PHBs. IE is already licensed with the OS, and because it is part of Windows, it gets vetted by internal departments.
Of course, there are ways to package and use other browsers, even in environments where system images have to be completely locked down. VMWare's ThinApp is one of the more elegant solutions to this I have seen.
The good thing is that IE8 is at least decent security, especially on Vista and newer where it runs in a sandbox. This doesn't stop attacks, but it forces attackers to have to jump one more hurdle before they get control of that user's context.
What Web browser and OS designers should start focusing on isn't just the Web browser as the core of security. What attackers are going after are the add-ons. Because add-ons store persistant user info, have access to the filesystem, and can run binary code directly on the platform, all it takes is a simple buffer overrun, and an add-on can give full user (or even worse, Administrator/root) access to a blackhat. Until add-ons are corraled in a secure sandbox by a combination of the Web browser (for rendering), and the OS (to ensure a process's context is not going to be able to affect others), it will be a whack-a-mile game with finding and stomping browser/add-on exploits.
Until then, perhaps the most secure solution (next to AdBlock and NoScript in Firefox) would be running the Web browser as a user in a VM, and having the VM roll back all changes when closed. This way, malware would have to get user context, get admin authority, then find a way to bust out of the hypervisor to the host OS. All possible, but very tough. On a BSD, running the VM emulator software in a jail and using ZFS to roll back the directory structure to a saved snapshot would provide even more security even if the VM got compromised.
The civilian applications of this are tremendous too. SAR (search and rescue) support in areas where even motorcycle transport is dicey (Moab, etc), moving portable gear (generators if the mule can carry them) to a desolate area after a disaster. Additional help for hikers to carry stuff to and from a remote camp. A group of hunters can send a robot back to main camp to pick up another set of kegs, so the main partiers don't have to stumble down a trail at night.
Security isn't about how hardened your OS is, although it is a crucial ingredient (if you have bad apples, a chef can't make a good apple pie no matter how good. However, a bad chef can take perfectly good fruit and make something horrid.)
What is lacking in a lot of companies is an actual security policy. Encryption is the easy stuff. Making sure there is a department-wide policy, making sure users adhere to it, and keeping some type of mechanism in place for recovery if an employee leaves is what is tough, and what a lot of companies will refuse to pay the bucks for.
First line of security are the tools: You have firewalls, IDS systems, routers, and content filters to protect the network side. You have security guards, HID locks, Abloy PROTEC locks for backups, CCTV cameras, and alarms for the physical security. For data at rest protection, you have BitLocker, LUKS, EncFS, PGP, TrueCrypt, PointSec, or other mechanism to store data encrypted. For backups that go offsite, you have your hardware do the encryption (HP LTO-4 drives), or have the software have the government certified AES libraries (Retrospect, Backup Exec, TSM, Networker).
However, you can be sitting on the best tools in the world, but if they are not used in a coherant form by clued employees, they won't help things. For example, a machine could be protected with PGP and require a smart card to boot it. However, if the machine doesn't have a firewall or protection from network attacks, the DAR (data at rest) protection is pointless. Similar if a laptop has extreme antivirus utilities, but is always left in coffee shops unattended.
Obligatory car analogy: A company can pay millions for a fleet of semis, but without competant drivers, they will just sit in the parking lot and not do a thing.
Security isn't something you can just buy off the shelf. You can buy tools, but it takes expertise to implement everything into a solid security gestalt that is workable and protects company (and employee) assets.
Physical volume isn't that big an issue (assuming a cartridge size that can fit in a hand and be easily shuttled around by a tape robot). In fact, people touted DLT/LTO as more reliable because it was a larger format so it could store more, compared to 8mm/AIT. They also touted that the linear scanning of tracks was more error-tolerant than the helical heads.
To make sure: Tape isn't for everyone. A tape drive that holds a reasonable amount of data (800 gigs native or more) will cost you $4000. For a SOHO or a small business, they might be better off cost-wise by buying a bunch of USB/IEEE1394/e-SATA drives and use those for storing backup sets, rotating drives in and out for offsite security.
For a lot of people, a microSD card is enough for a basic backup. However, what might work for one person may not even be useful for another. For example, I don't just like backing up documents, but my whole desktop. This way, if a hard disk fails, I can restore to a known good image, bare metal instead of spending time reinstalling the OS, reinstalling apps, and finding all the documents.
Very true. However, you have one drive/library/rack, and one set of tape heads, for a large number of tapes. This means the total moving parts in a storage pool is far lower compared to a backup set consisting of a box of hard drives. If a tape drive dies, it is expensive, but it can be replaced and generally not cause loss of data. The media is separate from the reader. If the heads die on a hard disk, you are facing a very expensive recovery process if anything is stored on that drive that is wanted.
The biggest issue with tape is keeping the density and cartridge capacity up. Even though tapes and magnetic hard drives share a lot in common, storing data on rust is where the similarities end. Tape media contacts the head and is read while the head is contacting, as opposed to HDDs which float very close to the surface of a disk. So, the material the magnetic domains are on has to be sturdy enough for physical contact. Tape does have an advantage that it has more space to store data than a disk platter. However, a lot of that space is taken up by error correction, since there is no way to relocate bad sectors on the fly with tape, and if a block goes bad, it goes bad, no way to recover without ECC, or a way to duplicate the lost data.
What tape has over hard disks is simplicity. A DLT or LTO-5 tape has one reel for a moving part. Compare that to a hard disk which has the platters, the heads, the wires, and the motors. Drop a tape, and it almost certainly is recoverable. Drop a hard disk, and a person never knows if the hard drive is completely dead, or will die very soon due to the impact. This is also important when it comes to archiving. Tapes, you can put in their cases, drop them axis vertical in an Iron Maiden tub, and your data is secure. With hard disks, you have to put them in padded boxes to help dampen vibrations which can kill the drive.
Tape drive makers are also responding to the clarion call of encryption. HP's LTO-4 line supports SPIN/SPOUT encryption capabilities. You can set it to use the same passphrase on multiple tapes, or use backup software which sets a different key on each tape and manages which key goes to which tape for better security. Software like Retrospect, Backup Exec, or bru also offer AES encryption with libraries certified by the US government. So, a tape backup is decently secure.
Tapes can be set to be read-only. This is important because it means that a tape read on a compromised machine won't be able to be tampered with. Some tape systems (DLT) offer WORM functionality to allow for secure archiving of data with the data cryptographically signed by the tape drive. This is important when one has to deal with HIPAA and archiving of data for 7 years, or the FAA and archiving airplane data for 50 years.
Tapes are fast. This is also one of their weaknesses. If you don't feed them the full amount of their pipeline, the tape drive has to stop and reverse. "Shoe-shining" is not good for tape life, nor the life on heads. So one needs to have tape drives preferably on a computer with the I/O paths to handle it [1].
Finally, once you buy the drive, tapes are the best bang for byte you can get. Even older tape formats like LTO-4 that give 800 gigs native for $40 is still fairly cheap for the capacity.
[1]: Ideally, the best use of tape is a network backup server with a good RAID array. You back the machines up to the array, then copy the data to tape. This way, network glitches do not slow down the data being slapped on the tapes.
One thing that got US farmers out of the Dust Bowl days (the main thing being the end of the multi-year drought) is using crop rotation techniques. It is sort of ironic that that same lesson will have to be learned by farmers again, when oil becomes too expensive to use as fertilizer. Since we are past peak oil, it really is only a matter of time.
What would separate a RPG from the RTS are decisions leading to different campaigns. Say you have a band of chainsaw fencers. You can take out the drow outpost, or the human citadel. Depending on which group's outpost gets the beatdown, the rest of the game will have campaigns that go either way. The next mission would either help a drow spider-queen secure her new outpost, or you fight with the humans to push out invaders to reclaim claim ancient breweries.
In general, a RTS campaign is linear. Modern RPGs have many branches, side quests, and endings. (Always exceptions... Final Fantasy, for example.)
This has been going on for a long time. If one stretched things, they could say that World of Warcraft is a FPS with an extreme number of powerups. However, FPS is a concept is a known quantity. You put out something in this type of genre, and you will almost certainly break even at the minimum.
Finding new ways to do a RPG combat system is hard. There are not that many ways to do combat, so FPS mechanics is one of the most used. Turn by turn combat used to be the RPG mainstay, but for many people, it is too slow a method of resolving conflict. There are other combat systems, but if a game relies too much on arcade reflexes, it might turn people away.
For single player, most likely the best bet for a modern RPG these days would be a system used by NWN and NWN2, where people can pause the action before making their next decision, but if they know what exactly is going on, can still do an almost real-time battle.
What I've not seen that much of are RPGs with RTS mechanics. Picture having your group of people that you start out with at a beginning of the game, and each of them has some ability and weakness. There would have to be more plot and character development for an RPG to separate it from Warcraft 1-3 (adding multiple endings, having side quests), but it could be done.
One scenario using these type of mechanics could be pushing back some orcs [1] who are pillaging some nearby villages. You send in some scouts to see what exactly their weaknesses are (one village has an orc wizard fireballing buildings. Another has an orc chieftain who keeps his band up with heals. Still another has a warrior chieftain.) Then you send whatever guys you have that would be the best against the type of enemy at hand. With different playstyles, one could have a lot of grunt troops and just swarm the villages, send in ranged troops (with some melee in front as a distraction), or perhaps even find a way to use some type of negotiating skill to get the orc tribal leaders to accept a keg of ogre swill as treasure enough so they stop their invasion.
Another scenario could be a castle siege. You have your forces and need to punch a hole in the castle walls, while fending off forces coming from other sides. Part of the RPG would be doing side quests. One side quest earns you better siege engines. Another gets enemy troops to not join in on the fight. Still another side quest just might allow the player to earn such a famous/infamous reputation that they can just bypass the siege altogether and have the opposing side open the doors and surrender.
This isn't to say this has not been done before, but RPG/RTS mechanics are not something seen often in modern games. What sets RPGs apart from "plain old" RTS/FPS games is having multiple endings, multiple side quests, and different consequences for player actions. For example, if a PC is an extremely good diplomat, it may allow for some battles to be skipped or handled in a different way. Similar if a PC does side quests for a reputation. Throwing in some mini-games [2] may be the answer here as a way to help (perhaps use the RTS engine so the player can work as a mercenary general in order to help your side get land or resources in between plot advances.)
[1]: Classic AD&D/LoTR orcs which would be more than happy to stuff any intelligent race in a stewpot. Except dwarves. They are just too hard to clean.
[2]: One recent mini-game I liked was the Risk-like one in James Cameron's "Avatar". It was fairly tough because you had very little territory at the start, so you could either play your chances slowly, or start the mini game every so often, because you got more money as the main game progressed. Mini games have to be done right though. For example, the card one in FF8 a lot of players just skipped for the most part.
I just considered it a movie. No more. There are a lot of people drawing parallels between the RDA and $group_in_authority and the Na'vi and $persecuted_group. However, I'm sure with any popular movie which isn't using the same stale IP as before, this could be put into place. People alluded the Empire in Star Wars to groups in real life when that debuted.
"Avatar" is a movie, a piece of sci-fi. No more. The RDA doesn't symbolize US marines any more than the UAC space marines in Doom: The Movie.
To me, I was more puzzled by how a race of hunter/gatherers have absolutely perfect teeth to a person, than seeing that fictional sides in a sci fi movie related to real life groups.