How about they kill activation too while they are at it, especially for VLK licensees? Why businesses have to bounce machines off of MS's activation servers when they will end up getting rebuilt anyway, or have to set up core MAK servers for six month activations at a time is insane. A business is under the barrel of the BSA anyway, so they won't be pirating Windows/Office (at least if they want to stay in business after firing an employee who rats them out.)
OGA/WGA/activation is pointless. It annoys the legit users while the pirates are happily ignoring it.
The same technology that is used to give a decent bidet clean and check the urine for problems can be easily used as evidence for job termination, or even probable cause for search warrants should it find certain chemicals in the pee stream.
Meh, misspelled Zuckerberg. My feeling is that FB will be allowed to operate... provided they "cooperate" and let an interest like The9 have a controlling stake, and would mean that FB would have to hand to the PLA the source code of their backend application.
Great deal for China -- another technology obtained for free, without any IP limitations (patents/copyrights/trademarks). For FB? Maybe it might bring in some money through ads, but is it worth the cost?
If it were me, I'd say no, however I'm one of those boring people who believes in security and privacy over expanding the bottom line.
Facebook would be happily allowed into a fascist state. Especially in return for being allowed to do business, they offered unfettered access of their database of that nation, and other nation's to that country's intelligence services. This is my fear about Zukerberg making a deal with the devil, that US and European data "accidently" gets replicated to PLA servers. Of course, one should never put anything on FB that shouldn't be public, but on the other hand, this data shouldn't be easily available for data miners in a hostile nation.
There is a big difference between learning to bang out code (most coding shops I've seen demand 10,000 lines of code a day regardless of bugs), versus true computer science and the core concepts.
True computer science is more than 1/0s. It is being able to deal with the layers of abstraction from the pulses of electricity running around a CPU to how a user points and fertilizes their donkeys on FarmVille.
Several example puzzles that are overlooked when one thinks about CS:
Advanced concepts of structures more complicated than a linked list -- circular buffers, heaps, stacks, caches, hash tables.
Dealing with a hard disk. Being able to position the read/write head not just on top of the data you want, but right before it, so you get blocks before and after the read, or if handed a bunch of reads from sectors, the most optimal way to read them all, giving priority to the ones that need it the most first, and which to cache first, which others to dump.
Process scheduling. Round robin may sound good, but there are times when it may not be optimal.
Security from the ground up on a computer. This is almost an art form, where any component can be compromised.
Storage. What is the most optimal way to store data on a certain format? Gray codes? Just plain 1s and zeroes? 6 and 2 encoding like DOS 3.3 on the Apple ][ floppies?
Integrity of data. There is a reason why NoSQL isn't used in anything production-grade, and why ACID when it pertains to data storage has nothing to do with the stuff that comes on blotter paper.
CS is sort of squeezed between two things. CS graduates end up going into coding, or they end up in IT. It is hard to do much with a "pure" CS background these days, unless one is starting a company and has VC access to start pursuing cool things. The engineering aspect (new hard disks, etc) end up being the realm of the EEs and MEs.
If we went to a CA model with the supervising CA demand rigorous security specifications and insta-revoke of CA keys if they go out of bounds, CAs would be useful.
Another good model would be going to a WOT system. I trust Verisign a lot more than I do an Elbonian CA. So, having a system where I mark that in my key database and that ends up on key servers will mitigate what a rogue CA can do even if their root cert is in browsers. However, exactly as you said, average users need to learn basic cryptography.
Joe Sixpack doesn't care how high a chance of a key being authentic is; he just wants to see a lock icon on the Duff Beer site when he is buying a sign for his mancave. He just wants stuff to "work", even if it results in disastrously broken things like communal keys, or CAs that are untrustworthy in the Web browser.
Ideally, browsers should have three SSL security levels:
Self-signed SSL cert. For the average user, it shouldn't bring up a lock icon, but something different saying the site is using some basic, untrusted cryptography to communicate.
CA certs. Usual lock icon. Perhaps a green lock icon for the EV certs. I'd like to see a "temperature gauge" with CA certs, because I trust Verisign, Thawte, RSA, and Symantec far more than I do some CA in Elbonia who happens to have their root cert marked as trusted in the browser.
Certs that are explicitly trusted, where the key ID, fingerprint, and other information is marked as secure in the browser. The SSH protocol does this; shouldn't browsers do this especially if you know what key you are communicating with? This way, no jacked CA could say a bogus key is real. You either communicate to the right key, or it gets rejected.
As a stopgap measure, Web browsers should have the option to notify you if a cert changed, and show it. The Certificate Patrol add-on in Firefox does this, but this should be built into the browser.
Any device made by a sane security designer would either generate a key pair where a cert would be sent to the device maker to be certified, or have a unique private key installed at the factory where it can be signed with a CA before it ships (although this gives the issue of trusting pre-generated keys even though they are individual and different per device.)
With how brutal attacks through the Internet are, this is bordering on criminal negligence on a massive scale.
Of course, it looks like the only way to get around this (assuming the Web server on the WAN side can be disabled) is to have ssh available, ssh in to a hardened machine on the inside (that has a unique, known key), then view the config page with a browser. Even VPN connections couldn't be trusted.
It would be nice if Android could join this list. However, it would require some changes to its structure:
1: Encryption of more than just APK files on the SD card. Even 2.3 doesn't support this. In the corporate market, this is completely hamstringing Android from ever getting more than a token foothold. Apple understood this, and made a deal with MS so their devices can properly store anything Exchange related encrypted. The Droid Pro is advertised as having encryption in 2011. Google needs to get on the ball and address this, and it doesn't take that much to deal with this issue.
First, you have a random 256 bit key stored in a protected location (where it can be easily and thoroughly erased.) This is tied to the passcode or PIN on the Android device. When the customer enters the passcode, it unlocks EncFS protected directories and stores the key in two locations in RAM (one normal, one bit-inverted with the keys flipping every so often.) The SD card can optionally be completely protected by EncFS.
Another good way of encrypting which goes beyond files (but the downside is that the card is only readable on Windows with FreeOTFE) would be completely encrypting the SD card using LUKS. The advantage of using LUKS is that everything on the card is protected.
2: A way to encrypt backups. One of Android's strong points is that it is not tied to one computer like iOS devices or WM devices. However, it would be good if Google had an official standard for backing up data so each phone vendor doesn't take this into their own hands. Titanium Backup and nandroid are ideal for home use, but not enterprise solutions. Instead, something profile based that can happily scoop up the APKs that are not flagged copy-protected [1], make note of the copy-protected apps so they can be reinstalled via the Marketplace, and then have the encrypted file saved to the SD card, or exportable to the computer via other means.
3: Profile compliance. Some companies lock out backups, demand 15 character PINs, and those changed every 2 days, disable camera and screenshot capability, and other nasty stuff. Eventually, Android will have to play ball here (preferably with virtual machine capability as mentioned on another/. article), if it wants a foothold in the enterprise market.
Would these changes be good? #1 would be good regardless. #2 and #3 may make Android less friendly to consumers and developers.
What one goes to college for these degrees is less of the degree, but more of being able to bag an internship. Companies want known goods, and they receive reams full of resumes from people who have degrees from everywhere from Elbonia U all the way from MIT/Harvard/Yale/Miskatonic graduates in the top 10% of the class.
The key in college which isn't told to most students is college isn't about getting grades and beer bong slamming. It is about getting internships and contacts so when graduation day is at hand, there is not just jobs lined up [1], but there is an actual position, contract, and start date ready for you the second you get out.
[1]: Jobs lined up mean jack squat. Companies get shut down, or they go into hiring freezes. There is a big difference from having a position obtained from an internship than having "jobs lined up".
This kill switch will help in casual theft cases. Drunk corporate officer leaves laptop in nightclub. It gets grabbed by a club rat. Next day, IT disables the CPU. If the machine is found again, recovering the data even with an erased TPM isn't hard. BitLocker can store the recovery bits in Active Directory, or even as a data recovery agent, so if the laptop is recovered, the key can be reinputted and the TPM information resealed, or the drive can be unlocked and mounted by IT for document recovery.
For people like us, its a deterrent. It also is useful for laptops with TPM chips and soldered on CPUs, where blowing out the CPU means that the data can't be moved to a new machine and accessed.
However for the crackhead on the street, if he sees a laptop, even if he knows it may be DOA when he hands it to the fence, he will be going to grab it.
This kill switch is really less of deterring theft than making sure that enterprise assets are secure.
Here is something that may not be on the front lines of security, but it does help with dealing with the after-effects of an attack -- the humble backup strategy in a company.
No, backups are not exciting like a new security appliance or software which is advertised like it can stop a zombie apocalypse in its tracks (IIRC, the only product that has this capability is Microsoft Forefront, claimed by their ads a couple years ago). Nor do they give bragging rights. However, if a machine gets nailed in an attack (and you know when the hit took place), a good backup policy means large downtime differences.
Lets take a simple company with one location. They have a backup server (can be anything... PC running Retrospect, or something higher end like an EMC Avamar). It used a pool of disks (RAID on a controller or a Drobo on the low end, tier 3 storage on a SAN, perhaps T2 if one machine has a really tight backup window), and then periodically copies the stuff stored on it to tape for offsite rotations or long term archiving.
An "acute" attack happens, where people find what the entry point was. Bare metal restores are doable and servers can be reloaded quickly and brought back into action with relative ease.
A "chronic" attack happens, where servers were compromised over time and knowing when the initial intrusion took place is hard to impossible. It would take some time piecing files back, but stuff can be recovered, assuming a decent tape rotation where every so often, tapes are stored indefinitely. However, it is almost certainly doable.
The worst case with doing backups like this is compromise of the backup server. Having multiple machines for different servers can help compartmentalize this risk, and since backup servers really only do a single function (ask a machine for data over a couple ports, get the data, and reverse on restores), they can be locked down thoroughly, even in their own VLAN with just the critical backup ports being available.
With this in mind, why are not backups focused on more in companies? Security is important, but second to that is the ability to get back running after a breach. Yes, backups are boring, but the security appliances are not going to get back a company's data if someone does get around them.
I also recommend option 3 -- a platform change, which can minimize breaches. This is different from handing someone an Ubuntu CD and saying "SUK LESS", because depending on what applications someone is running, swapping to a different OS may or may not be possible. For example, a lot of users can swap to Linux because the core applications they use would be present. Others might use Photoshop or World of Warcraft, commercial items which work on OS X or Windows, so a Mac might be a good idea. Still other people play Windows games, so they really can't jump to something different.
Another option is #4 -- A KVM switch and a tightly locked down PC for banking. Then a PC that can be easily formatted and restored for games and general usage. This way, a blackhat might be able to bag someone's WoW account, but not their checking account.
Routers get updated less often because they do far less than a full general purpose computer, which could have any components (Web browser, applications, services, hardware devices) break of have security issues.
Essentially on the outside, an attacker can attack the IP stack of a hardened firewall and that is essentially it. On the inside, a Web server and/or a SSH server, as well as the IP stack are pretty much the only points it can be nailed. Of course, there are likely others, but these would be the main ones that a router would be attacked at.
You hit the nail on the head here. The problem I see is that people tend to rely on one of the following for their organizational security:
1: Host security. 2: Security of core/edge routers and switches. 3: Cross platform antivirus utilities. 4: Prayer to eldrich horrors.
One needs to take all four elements into account. For example, you use the routers to separate departments and machines from each other. Then, you make sure server security is tight with ipchains, Windows "firewall", and other items. Then you slap on the AV programs to make the bean counters happy. Finally, you get the tomes out (the Necronomicon ex Solaris) and do the horrific, unprintable acts as per the man pages.
This way, if the router decides to just move traffic without worrying about IP rules, the servers can defend themselves. If a server or workstation gets compromised, its ability to attack other machines is limited.
That is true as of now, but things can change. There are a lot of technology pieces that are in use now that can push free, unregulated speech to the edges of the Internet:
1: "Blue pill" variants. These would be hardened chips, or just hypervisor modifications which would periodically freeze a CPU's execution, scan a machine's RAM for stuff, then if it finds something either shuts the machine down, or shuts it down and phones home about it. This same technology can ensure only signed operating systems boot. This is a technology different from TPM chips because it is active and part of the boot process, as opposed to sitting on the site and just taking in hashes, then only releasing a key if a hash series matches.
2: NAC and health checking. If a machine isn't "authorized", either by not running a "legal" OS, or the hardware is not "trusted", it won't get the ability to connect.
3: Closed computing. Closed environments where the user has no access to root/Administrator are getting dangerously close to the desktop. One can see Android, iOS, or variants ending up on the desktop. End users would actually be happy because they wouldn't have to worry about system admin tasks. However, in this environment, it is trivial to have monitoring tools in place that can't be disabled by the end user.
4: No such thing as net neutrality. ISPs have no legal responsibility to carry sites, and if they so chose, they could make a website that looks like Google.com, but in reality be something completely different, and route traffic there. So, ISPs can easily make a blacklist of sites whose packets are either dropped, or whose users are logged, then those users are dropped off the Internet. Because of the monopolies, it wouldn't take more than just 3-4 ISPs cooperating to ensure someone has no net access other than through borrowed logins, and a policy of dropping anyone who allows blacklisted users to connect would fix that in a hurry.
So, it wouldn't take much for all these pieces to come into place, and everyone who once used the Web now ends up using essentially a thin terminal to Compuserve 2.0 and pays by the hour online, by the sites visited... and all use is of course handed over to advertisers in toto.
This is something that a lot of organizations with deep pockets would benefit from. Advertisers would have more info to sell, insurance companies would be able to raise rates or find people's secret lifes as reasons to kick them off the rolls. ISPs would benefit from the data available to advertisers for mining, as well as all the additional fees. Commercial software developers would not have piracy as an issue, nor F/OSS software competing. Record labels can charge people any fees they want (5 cents per song per play.) LEOs would have easy pickings to dredge up details to do cases on people.
So, everyone benefits from the Internet going back to a CIS/AOL/Prodigy arrangement, except the end user.
1: Slowing down Iran's nuclear ambitions is in China's interests because when Iran does have the bomb, who knows what direction it may be sent.
2: Having Stuxnet blamed on the US/Israel is a good thing for China -- the more countries hostile to the west, the better.
3: If a conflict does break out, China could easily make a deal with Iran by offering to have the Red Guard protect the country in return for oil rights. This would ensure them a strong strategic base in the Middle East essentially forever.
But it may not be even China. Yesterday, along a similar topic, I stated that it could be a group of sociopathic people who have a skillz level far better than a script kiddy. There are people out there with a lot of knowledge and access to the 0-day scene who would love to do something like this just for kicks. They don't like any foreign power, so being instrumental in slowing one foreign power's aims while having it blamed on other people would accomplish their goals. There are people out there who would love to cause an incident, and then "watch the world burn", regardless of the consequences.
If done right, it wouldn't be too expensive. The main thing is that the ISP is intended to serve computer professionals, and is built around doing the job, doing the job right, protecting customer data, and providing service from people with a clue to people with a clue.
The Blizzard Authenticator is a VASCO device. It is a different mechanism than SecurID, but functionally similar.
For something other than a Web login, we need one step up from a passive identification, because it isn't unheard of for malware to compromise a Web browser so completely that it will show a user one balance, when in reality, their assets are being moved offshore.
What we really need is something like the IBM ZTIC -- a device that not just helps with authentication, but provides a mean of confirming transactions that malware cannot mess with. The worst malware can do is drop the USB connection to the device. Why should this functionality be on a dedicated device and not a cellphone? Lower attack profile. Nothing is 100%, but it is far harder to compromise a dedicated security device running a hardened embedded OS on ARM's TrustZone than essentially a general purpose computer.
I would love an ISP that is essentially for sysadmins. No BS, but solid tech support (no script readers, but people who actually know UNIX.) It would have the following features:
1: Limited numbers of customers. This is not an ISP for Joe Sixpack. Perhaps a friend referral system like some Google betas, perhaps a "clue test". There are many companies who want Joe and Aunt Tillie; this ISP isn't one of them. This way, someone coming from thisisp.com has an E-mail address that is distinctive.
2: NNTP caching. It isn't competing with EasyNews, but USENET is something an old school ISP always had.
3: Squid proxy. Let the ISP do the caching.
4: Proxy/VPN service. It would be nice to have the ISP handle traffic for iPhones or Android devices to ward off attacks from Firesheep or other items.
5: Exchange. No, this isn't with the UNIX ways, but so many things these days depend on Exchange, (such as being able to erase mobile devices if lost/stolen.)
6: A decent mirror updated often. Ideally, RedHat, Ubuntu, Debian, *BSD, CentOS, Linux kernel patches, and other items. Bonus points for full repos as well.
7: The usual Web page support, with database access to the usual OSS ones, as well as Oracle and DB/2.
8: Backups standard. If it gets stored, it gets backed up.
9: Home directories have file access through the web, and are stored on a WAFL or other system where snapshots are easily retrieved.
10: E-mail privacy. Unless there is a court order, the mailbox contents are only accessible by the user, or admins doing their duties.
11: SLAs. All data is backed up onto encrypted media so a tape dropping off a truck doesn't mean compromise, all E-mail is stored on encrypted LUNs so someone yanking hard disks out doesn't get data. Finally, a guarantee that if the company is going to go under, there is money to cover complete destruction of all stored customer data by a certain date unless specifically asked for in writing. This way, someone doesn't pick up the liquidated assets and sell the information.
12: The banhammer. Someone has a machine that has obvious signatures of a botnet, and the user has not stated he may be running honeypots, that box gets yanked and the user is redirected to a Web page telling him to reinstall, or take full responsibility for any honeypots. Same with lots of spam out port 25, or repeated connections to port 22 for brute force password guessing. A user who can't clean up their mess doesn't belong as as subscriber.
13: Logs (mail, router, etc) are kept for a fairly short time (2-3 days to a week) then deleted unless a court order asks for them to be kept, or there is a security issue that means they need to be kept longer.
14: No advertisers, period. The ISP makes its cash from subscriber fees. This way, there is no conflict of interest.
15: Ad-dropping transparent proxies. This would be a feature that could be turned (default off), so people wouldn't have to worry about Adblock and such when viewing the Web.
16: SecurID as an option. This way, someone can check mail on not so trusted computers and be resistant to not having their account hijacked. The session can be hijacked, but no more than that.
Heck, an ISP could also go into the cloud VM business, and even offer Linux or Windows VPS hosting, which helps find more uses for the money spent.
+1. I'd love to see small "retail"/"boutique" ISPs reappear, like how we had the funky ones in the 90s before broadband killed the little guys off. For example, I miss the old io.com and other places.
It is more of a case of why bother. There are a lot of things one can try to remember, but why waste the time when better things can be done? After 30+ websites, and numerous root passwords, yes, one can remember them, but why take the time to do that when you can just store them in an offline device? I trust that my Android phone which is well backed up will remember accounts and root passwords to machines that I have not logged into in years.
If one can remember all their passwords, more power to them. However, having a password manager on a trusted device may save a lot of headaches later on when the "well-remembered" root password ends up being wrong, and it would take a long trip to physically reset the box to get back access.
It would be nice to have a secondary authentication mechanism that is a de facto standard. Person buys card, or app for phone, and it works on any bank or website regardless. Because the secondary auth mechanism is bought separate from the account, one can remain reasonably anonymous by using a device only for throwaway accounts, and when done with those accounts, physically chucking the authenticator.
With an authenticator in place, a webmaster can just drop code to have time delays for brute forcing, and call it done. Even if a blackhat bags the hash table and knows the user's passwords, without the physical authenticator, it won't do the intruder much good.
Easy fix. I assume that because you have been on/. a while by your UID, you perform basic daily backups of your systems, or at least have your documents copied off via a service like Mozy, Carbonite, Backblaze, or the like. Normal backups should easily handle this problem. If you use an external disk or backup server, a hardware failure just means a quick restore. If everything is trashed, you can restore (albeit slowly) from Mozy. In either case, your data will be retrievable. It also can't hurt to make a copy of your password storage database (the kdb or kdbx file) so if it does get corrupted, you have a known good copy.
If you are really worried about the security of your password file, buy an Ironkey. This way, they will be stored on a hardware encrypted volume that will fry after 10 bad password guesses.
Of course, if you are concerned about storing passwords on a potentially compromisable computer, there is an easy fix for that. KeePass is available as an app for the iPhone and Android. You can also download a number of password utilities, and put dummy entries in them, except for the one you actually use. This way, a thief who grabs your iDevice will have no clue which password utility has actual usable data. Some other password managers will lock or erase their database after a number of failed guesses.
Don't forget that you can use your Web browser for storing passwords (I prefer Firefox for this, because it can require a password before giving access to what is stored), and you can get an extension like FEBE to make sure they are backed up just in case of profile corruption.
Slashdot Mirror
How about they kill activation too while they are at it, especially for VLK licensees? Why businesses have to bounce machines off of MS's activation servers when they will end up getting rebuilt anyway, or have to set up core MAK servers for six month activations at a time is insane. A business is under the barrel of the BSA anyway, so they won't be pirating Windows/Office (at least if they want to stay in business after firing an employee who rats them out.)
OGA/WGA/activation is pointless. It annoys the legit users while the pirates are happily ignoring it.
The same technology that is used to give a decent bidet clean and check the urine for problems can be easily used as evidence for job termination, or even probable cause for search warrants should it find certain chemicals in the pee stream.
Meh, misspelled Zuckerberg. My feeling is that FB will be allowed to operate... provided they "cooperate" and let an interest like The9 have a controlling stake, and would mean that FB would have to hand to the PLA the source code of their backend application.
Great deal for China -- another technology obtained for free, without any IP limitations (patents/copyrights/trademarks). For FB? Maybe it might bring in some money through ads, but is it worth the cost?
If it were me, I'd say no, however I'm one of those boring people who believes in security and privacy over expanding the bottom line.
Facebook would be happily allowed into a fascist state. Especially in return for being allowed to do business, they offered unfettered access of their database of that nation, and other nation's to that country's intelligence services. This is my fear about Zukerberg making a deal with the devil, that US and European data "accidently" gets replicated to PLA servers. Of course, one should never put anything on FB that shouldn't be public, but on the other hand, this data shouldn't be easily available for data miners in a hostile nation.
There is a big difference between learning to bang out code (most coding shops I've seen demand 10,000 lines of code a day regardless of bugs), versus true computer science and the core concepts.
True computer science is more than 1/0s. It is being able to deal with the layers of abstraction from the pulses of electricity running around a CPU to how a user points and fertilizes their donkeys on FarmVille.
Several example puzzles that are overlooked when one thinks about CS:
Advanced concepts of structures more complicated than a linked list -- circular buffers, heaps, stacks, caches, hash tables.
Dealing with a hard disk. Being able to position the read/write head not just on top of the data you want, but right before it, so you get blocks before and after the read, or if handed a bunch of reads from sectors, the most optimal way to read them all, giving priority to the ones that need it the most first, and which to cache first, which others to dump.
Process scheduling. Round robin may sound good, but there are times when it may not be optimal.
Security from the ground up on a computer. This is almost an art form, where any component can be compromised.
Storage. What is the most optimal way to store data on a certain format? Gray codes? Just plain 1s and zeroes? 6 and 2 encoding like DOS 3.3 on the Apple ][ floppies?
Integrity of data. There is a reason why NoSQL isn't used in anything production-grade, and why ACID when it pertains to data storage has nothing to do with the stuff that comes on blotter paper.
CS is sort of squeezed between two things. CS graduates end up going into coding, or they end up in IT. It is hard to do much with a "pure" CS background these days, unless one is starting a company and has VC access to start pursuing cool things. The engineering aspect (new hard disks, etc) end up being the realm of the EEs and MEs.
If we went to a CA model with the supervising CA demand rigorous security specifications and insta-revoke of CA keys if they go out of bounds, CAs would be useful.
Another good model would be going to a WOT system. I trust Verisign a lot more than I do an Elbonian CA. So, having a system where I mark that in my key database and that ends up on key servers will mitigate what a rogue CA can do even if their root cert is in browsers. However, exactly as you said, average users need to learn basic cryptography.
Joe Sixpack doesn't care how high a chance of a key being authentic is; he just wants to see a lock icon on the Duff Beer site when he is buying a sign for his mancave. He just wants stuff to "work", even if it results in disastrously broken things like communal keys, or CAs that are untrustworthy in the Web browser.
Ideally, browsers should have three SSL security levels:
Self-signed SSL cert. For the average user, it shouldn't bring up a lock icon, but something different saying the site is using some basic, untrusted cryptography to communicate.
CA certs. Usual lock icon. Perhaps a green lock icon for the EV certs. I'd like to see a "temperature gauge" with CA certs, because I trust Verisign, Thawte, RSA, and Symantec far more than I do some CA in Elbonia who happens to have their root cert marked as trusted in the browser.
Certs that are explicitly trusted, where the key ID, fingerprint, and other information is marked as secure in the browser. The SSH protocol does this; shouldn't browsers do this especially if you know what key you are communicating with? This way, no jacked CA could say a bogus key is real. You either communicate to the right key, or it gets rejected.
As a stopgap measure, Web browsers should have the option to notify you if a cert changed, and show it. The Certificate Patrol add-on in Firefox does this, but this should be built into the browser.
+1
Any device made by a sane security designer would either generate a key pair where a cert would be sent to the device maker to be certified, or have a unique private key installed at the factory where it can be signed with a CA before it ships (although this gives the issue of trusting pre-generated keys even though they are individual and different per device.)
With how brutal attacks through the Internet are, this is bordering on criminal negligence on a massive scale.
Of course, it looks like the only way to get around this (assuming the Web server on the WAN side can be disabled) is to have ssh available, ssh in to a hardened machine on the inside (that has a unique, known key), then view the config page with a browser. Even VPN connections couldn't be trusted.
It would be nice if Android could join this list. However, it would require some changes to its structure:
1: Encryption of more than just APK files on the SD card. Even 2.3 doesn't support this. In the corporate market, this is completely hamstringing Android from ever getting more than a token foothold. Apple understood this, and made a deal with MS so their devices can properly store anything Exchange related encrypted. The Droid Pro is advertised as having encryption in 2011. Google needs to get on the ball and address this, and it doesn't take that much to deal with this issue.
First, you have a random 256 bit key stored in a protected location (where it can be easily and thoroughly erased.) This is tied to the passcode or PIN on the Android device. When the customer enters the passcode, it unlocks EncFS protected directories and stores the key in two locations in RAM (one normal, one bit-inverted with the keys flipping every so often.) The SD card can optionally be completely protected by EncFS.
Another good way of encrypting which goes beyond files (but the downside is that the card is only readable on Windows with FreeOTFE) would be completely encrypting the SD card using LUKS. The advantage of using LUKS is that everything on the card is protected.
2: A way to encrypt backups. One of Android's strong points is that it is not tied to one computer like iOS devices or WM devices. However, it would be good if Google had an official standard for backing up data so each phone vendor doesn't take this into their own hands. Titanium Backup and nandroid are ideal for home use, but not enterprise solutions. Instead, something profile based that can happily scoop up the APKs that are not flagged copy-protected [1], make note of the copy-protected apps so they can be reinstalled via the Marketplace, and then have the encrypted file saved to the SD card, or exportable to the computer via other means.
3: Profile compliance. Some companies lock out backups, demand 15 character PINs, and those changed every 2 days, disable camera and screenshot capability, and other nasty stuff. Eventually, Android will have to play ball here (preferably with virtual machine capability as mentioned on another /. article), if it wants a foothold in the enterprise market.
Would these changes be good? #1 would be good regardless. #2 and #3 may make Android less friendly to consumers and developers.
What one goes to college for these degrees is less of the degree, but more of being able to bag an internship. Companies want known goods, and they receive reams full of resumes from people who have degrees from everywhere from Elbonia U all the way from MIT/Harvard/Yale/Miskatonic graduates in the top 10% of the class.
The key in college which isn't told to most students is college isn't about getting grades and beer bong slamming. It is about getting internships and contacts so when graduation day is at hand, there is not just jobs lined up [1], but there is an actual position, contract, and start date ready for you the second you get out.
[1]: Jobs lined up mean jack squat. Companies get shut down, or they go into hiring freezes. There is a big difference from having a position obtained from an internship than having "jobs lined up".
This kill switch will help in casual theft cases. Drunk corporate officer leaves laptop in nightclub. It gets grabbed by a club rat. Next day, IT disables the CPU. If the machine is found again, recovering the data even with an erased TPM isn't hard. BitLocker can store the recovery bits in Active Directory, or even as a data recovery agent, so if the laptop is recovered, the key can be reinputted and the TPM information resealed, or the drive can be unlocked and mounted by IT for document recovery.
For people like us, its a deterrent. It also is useful for laptops with TPM chips and soldered on CPUs, where blowing out the CPU means that the data can't be moved to a new machine and accessed.
However for the crackhead on the street, if he sees a laptop, even if he knows it may be DOA when he hands it to the fence, he will be going to grab it.
This kill switch is really less of deterring theft than making sure that enterprise assets are secure.
Here is something that may not be on the front lines of security, but it does help with dealing with the after-effects of an attack -- the humble backup strategy in a company.
No, backups are not exciting like a new security appliance or software which is advertised like it can stop a zombie apocalypse in its tracks (IIRC, the only product that has this capability is Microsoft Forefront, claimed by their ads a couple years ago). Nor do they give bragging rights. However, if a machine gets nailed in an attack (and you know when the hit took place), a good backup policy means large downtime differences.
Lets take a simple company with one location. They have a backup server (can be anything... PC running Retrospect, or something higher end like an EMC Avamar). It used a pool of disks (RAID on a controller or a Drobo on the low end, tier 3 storage on a SAN, perhaps T2 if one machine has a really tight backup window), and then periodically copies the stuff stored on it to tape for offsite rotations or long term archiving.
An "acute" attack happens, where people find what the entry point was. Bare metal restores are doable and servers can be reloaded quickly and brought back into action with relative ease.
A "chronic" attack happens, where servers were compromised over time and knowing when the initial intrusion took place is hard to impossible. It would take some time piecing files back, but stuff can be recovered, assuming a decent tape rotation where every so often, tapes are stored indefinitely. However, it is almost certainly doable.
The worst case with doing backups like this is compromise of the backup server. Having multiple machines for different servers can help compartmentalize this risk, and since backup servers really only do a single function (ask a machine for data over a couple ports, get the data, and reverse on restores), they can be locked down thoroughly, even in their own VLAN with just the critical backup ports being available.
With this in mind, why are not backups focused on more in companies? Security is important, but second to that is the ability to get back running after a breach. Yes, backups are boring, but the security appliances are not going to get back a company's data if someone does get around them.
I also recommend option 3 -- a platform change, which can minimize breaches. This is different from handing someone an Ubuntu CD and saying "SUK LESS", because depending on what applications someone is running, swapping to a different OS may or may not be possible. For example, a lot of users can swap to Linux because the core applications they use would be present. Others might use Photoshop or World of Warcraft, commercial items which work on OS X or Windows, so a Mac might be a good idea. Still other people play Windows games, so they really can't jump to something different.
Another option is #4 -- A KVM switch and a tightly locked down PC for banking. Then a PC that can be easily formatted and restored for games and general usage. This way, a blackhat might be able to bag someone's WoW account, but not their checking account.
Routers get updated less often because they do far less than a full general purpose computer, which could have any components (Web browser, applications, services, hardware devices) break of have security issues.
Essentially on the outside, an attacker can attack the IP stack of a hardened firewall and that is essentially it. On the inside, a Web server and/or a SSH server, as well as the IP stack are pretty much the only points it can be nailed. Of course, there are likely others, but these would be the main ones that a router would be attacked at.
You hit the nail on the head here. The problem I see is that people tend to rely on one of the following for their organizational security:
1: Host security.
2: Security of core/edge routers and switches.
3: Cross platform antivirus utilities.
4: Prayer to eldrich horrors.
One needs to take all four elements into account. For example, you use the routers to separate departments and machines from each other. Then, you make sure server security is tight with ipchains, Windows "firewall", and other items. Then you slap on the AV programs to make the bean counters happy. Finally, you get the tomes out (the Necronomicon ex Solaris) and do the horrific, unprintable acts as per the man pages.
This way, if the router decides to just move traffic without worrying about IP rules, the servers can defend themselves. If a server or workstation gets compromised, its ability to attack other machines is limited.
That is true as of now, but things can change. There are a lot of technology pieces that are in use now that can push free, unregulated speech to the edges of the Internet:
1: "Blue pill" variants. These would be hardened chips, or just hypervisor modifications which would periodically freeze a CPU's execution, scan a machine's RAM for stuff, then if it finds something either shuts the machine down, or shuts it down and phones home about it. This same technology can ensure only signed operating systems boot. This is a technology different from TPM chips because it is active and part of the boot process, as opposed to sitting on the site and just taking in hashes, then only releasing a key if a hash series matches.
2: NAC and health checking. If a machine isn't "authorized", either by not running a "legal" OS, or the hardware is not "trusted", it won't get the ability to connect.
3: Closed computing. Closed environments where the user has no access to root/Administrator are getting dangerously close to the desktop. One can see Android, iOS, or variants ending up on the desktop. End users would actually be happy because they wouldn't have to worry about system admin tasks. However, in this environment, it is trivial to have monitoring tools in place that can't be disabled by the end user.
4: No such thing as net neutrality. ISPs have no legal responsibility to carry sites, and if they so chose, they could make a website that looks like Google.com, but in reality be something completely different, and route traffic there. So, ISPs can easily make a blacklist of sites whose packets are either dropped, or whose users are logged, then those users are dropped off the Internet. Because of the monopolies, it wouldn't take more than just 3-4 ISPs cooperating to ensure someone has no net access other than through borrowed logins, and a policy of dropping anyone who allows blacklisted users to connect would fix that in a hurry.
So, it wouldn't take much for all these pieces to come into place, and everyone who once used the Web now ends up using essentially a thin terminal to Compuserve 2.0 and pays by the hour online, by the sites visited... and all use is of course handed over to advertisers in toto.
This is something that a lot of organizations with deep pockets would benefit from. Advertisers would have more info to sell, insurance companies would be able to raise rates or find people's secret lifes as reasons to kick them off the rolls. ISPs would benefit from the data available to advertisers for mining, as well as all the additional fees. Commercial software developers would not have piracy as an issue, nor F/OSS software competing. Record labels can charge people any fees they want (5 cents per song per play.) LEOs would have easy pickings to dredge up details to do cases on people.
So, everyone benefits from the Internet going back to a CIS/AOL/Prodigy arrangement, except the end user.
China has a lot to gain by doing this:
1: Slowing down Iran's nuclear ambitions is in China's interests because when Iran does have the bomb, who knows what direction it may be sent.
2: Having Stuxnet blamed on the US/Israel is a good thing for China -- the more countries hostile to the west, the better.
3: If a conflict does break out, China could easily make a deal with Iran by offering to have the Red Guard protect the country in return for oil rights. This would ensure them a strong strategic base in the Middle East essentially forever.
But it may not be even China. Yesterday, along a similar topic, I stated that it could be a group of sociopathic people who have a skillz level far better than a script kiddy. There are people out there with a lot of knowledge and access to the 0-day scene who would love to do something like this just for kicks. They don't like any foreign power, so being instrumental in slowing one foreign power's aims while having it blamed on other people would accomplish their goals. There are people out there who would love to cause an incident, and then "watch the world burn", regardless of the consequences.
If done right, it wouldn't be too expensive. The main thing is that the ISP is intended to serve computer professionals, and is built around doing the job, doing the job right, protecting customer data, and providing service from people with a clue to people with a clue.
Obligatory XKCD: http://www.xkcd.com/806/
The Blizzard Authenticator is a VASCO device. It is a different mechanism than SecurID, but functionally similar.
For something other than a Web login, we need one step up from a passive identification, because it isn't unheard of for malware to compromise a Web browser so completely that it will show a user one balance, when in reality, their assets are being moved offshore.
What we really need is something like the IBM ZTIC -- a device that not just helps with authentication, but provides a mean of confirming transactions that malware cannot mess with. The worst malware can do is drop the USB connection to the device. Why should this functionality be on a dedicated device and not a cellphone? Lower attack profile. Nothing is 100%, but it is far harder to compromise a dedicated security device running a hardened embedded OS on ARM's TrustZone than essentially a general purpose computer.
I would love an ISP that is essentially for sysadmins. No BS, but solid tech support (no script readers, but people who actually know UNIX.) It would have the following features:
1: Limited numbers of customers. This is not an ISP for Joe Sixpack. Perhaps a friend referral system like some Google betas, perhaps a "clue test". There are many companies who want Joe and Aunt Tillie; this ISP isn't one of them. This way, someone coming from thisisp.com has an E-mail address that is distinctive.
2: NNTP caching. It isn't competing with EasyNews, but USENET is something an old school ISP always had.
3: Squid proxy. Let the ISP do the caching.
4: Proxy/VPN service. It would be nice to have the ISP handle traffic for iPhones or Android devices to ward off attacks from Firesheep or other items.
5: Exchange. No, this isn't with the UNIX ways, but so many things these days depend on Exchange, (such as being able to erase mobile devices if lost/stolen.)
6: A decent mirror updated often. Ideally, RedHat, Ubuntu, Debian, *BSD, CentOS, Linux kernel patches, and other items. Bonus points for full repos as well.
7: The usual Web page support, with database access to the usual OSS ones, as well as Oracle and DB/2.
8: Backups standard. If it gets stored, it gets backed up.
9: Home directories have file access through the web, and are stored on a WAFL or other system where snapshots are easily retrieved.
10: E-mail privacy. Unless there is a court order, the mailbox contents are only accessible by the user, or admins doing their duties.
11: SLAs. All data is backed up onto encrypted media so a tape dropping off a truck doesn't mean compromise, all E-mail is stored on encrypted LUNs so someone yanking hard disks out doesn't get data. Finally, a guarantee that if the company is going to go under, there is money to cover complete destruction of all stored customer data by a certain date unless specifically asked for in writing. This way, someone doesn't pick up the liquidated assets and sell the information.
12: The banhammer. Someone has a machine that has obvious signatures of a botnet, and the user has not stated he may be running honeypots, that box gets yanked and the user is redirected to a Web page telling him to reinstall, or take full responsibility for any honeypots. Same with lots of spam out port 25, or repeated connections to port 22 for brute force password guessing. A user who can't clean up their mess doesn't belong as as subscriber.
13: Logs (mail, router, etc) are kept for a fairly short time (2-3 days to a week) then deleted unless a court order asks for them to be kept, or there is a security issue that means they need to be kept longer.
14: No advertisers, period. The ISP makes its cash from subscriber fees. This way, there is no conflict of interest.
15: Ad-dropping transparent proxies. This would be a feature that could be turned (default off), so people wouldn't have to worry about Adblock and such when viewing the Web.
16: SecurID as an option. This way, someone can check mail on not so trusted computers and be resistant to not having their account hijacked. The session can be hijacked, but no more than that.
Heck, an ISP could also go into the cloud VM business, and even offer Linux or Windows VPS hosting, which helps find more uses for the money spent.
+1. I'd love to see small "retail"/"boutique" ISPs reappear, like how we had the funky ones in the 90s before broadband killed the little guys off. For example, I miss the old io.com and other places.
It is more of a case of why bother. There are a lot of things one can try to remember, but why waste the time when better things can be done? After 30+ websites, and numerous root passwords, yes, one can remember them, but why take the time to do that when you can just store them in an offline device? I trust that my Android phone which is well backed up will remember accounts and root passwords to machines that I have not logged into in years.
If one can remember all their passwords, more power to them. However, having a password manager on a trusted device may save a lot of headaches later on when the "well-remembered" root password ends up being wrong, and it would take a long trip to physically reset the box to get back access.
It would be nice to have a secondary authentication mechanism that is a de facto standard. Person buys card, or app for phone, and it works on any bank or website regardless. Because the secondary auth mechanism is bought separate from the account, one can remain reasonably anonymous by using a device only for throwaway accounts, and when done with those accounts, physically chucking the authenticator.
With an authenticator in place, a webmaster can just drop code to have time delays for brute forcing, and call it done. Even if a blackhat bags the hash table and knows the user's passwords, without the physical authenticator, it won't do the intruder much good.
Easy fix. I assume that because you have been on /. a while by your UID, you perform basic daily backups of your systems, or at least have your documents copied off via a service like Mozy, Carbonite, Backblaze, or the like. Normal backups should easily handle this problem. If you use an external disk or backup server, a hardware failure just means a quick restore. If everything is trashed, you can restore (albeit slowly) from Mozy. In either case, your data will be retrievable. It also can't hurt to make a copy of your password storage database (the kdb or kdbx file) so if it does get corrupted, you have a known good copy.
If you are really worried about the security of your password file, buy an Ironkey. This way, they will be stored on a hardware encrypted volume that will fry after 10 bad password guesses.
Of course, if you are concerned about storing passwords on a potentially compromisable computer, there is an easy fix for that. KeePass is available as an app for the iPhone and Android. You can also download a number of password utilities, and put dummy entries in them, except for the one you actually use. This way, a thief who grabs your iDevice will have no clue which password utility has actual usable data. Some other password managers will lock or erase their database after a number of failed guesses.
Don't forget that you can use your Web browser for storing passwords (I prefer Firefox for this, because it can require a password before giving access to what is stored), and you can get an extension like FEBE to make sure they are backed up just in case of profile corruption.