I'm guessing one use will be following criminals from the air to relay positions. That, and keeping track of a car on a protracted chase, although from what I read, this bird doesn't have that long a radius and run time compared to a helicopter. I wonder if it is cheaper to spin something like this up than get the police in the air, so that is one reason this is being looked into.
Doesn't even need a password. Just include a variable length file of random contents in the archive.
The most secure bet is just to password protect the archive with WinRAR, have the password available in the notes (this can be easily changed around so an automatic scanner can't pick up the password, similar to how/. obfuscates E-mail addresses), and call it done.
Steering column locks are a joke to a serious thief. When I was in college out of high school, my car got broken into, and the steering column smashed open. What kept the vehicle from disappearing is the fact that I put in a kill switch so it would start, but as soon as the ignition returned to "on", it would immediately stall. So, frustrated thieves would just haul ass out of there after a few failed starts.
From what I have personally experienced. What doesn't work:
Normal car alarms.
What does work:
Kill switches. Time is not on the side of thieves, and having to fish through the dash to find the splicing is not in most of their playbooks unless the vehicle is worth it.
There are other ways to pop open cars. Take the slim jim for example. Even if that doesn't work, the metal on car doors is thin, so someone using a screwdriver to peel back the metal around the door handle, or perhaps punch the door handle in to be able to pull on the locking rod. This is why there are third party reinforcing plates sold (Jimmi Jammer) to protect against exactly that.
Other than adding heavy gauge containers (either bolting or even welding them down), it is almost impossible to stop smash-and-grabbers.
Even the manual way is susceptible to an old attack -- tryout keys. These are keys that are cut with patterns that usually tend to work on most vehicles.
I wish STRATTEC and other vehicle lock makers would change the physical lock's keyway every 2-3 years. This will cut down on people's keys randomly fitting other vehicles. Other items can be added (such as items like items found in Evva-Inox's keys) without sacrificing the reliability an automotive lock has to have.
Maybe the physical security of the lock isn't a big focus, especially because almost any lock on a vehicle can easily be sprung with a crowbar after the window glass gets smashed. However, it would be nice for carmakers to have options for heavier duty locks to help deter the smash and grab meth-head.
Fundamentally, the problem isn't like DRM, although I agree that nothing is 100% secure, and if someone can make it, someone can break it.
DRM is where Alice has encrypted to stuff to send to Bob, and wants to prevent Charlie from getting to it. However, Bob and Charlie are the same person.
The problem with the remote communication is easier (though not trivial in any way) -- Alice wants to send stuff to Bob, keep it out of Charlie's hands, and Charlie isn't connected to either endpoint.
For the standard cryptography issue, we have stuff that can withstand the test of time. However, keyfobs usually don't have the power to do regular cryptography, so shortcuts have to be taken (KeeLoq is a good example of trying to balance security with low CPU ability.)
The ideal security? Having a key cylinder that has physical contacts (or use NFC) where the key and the vehicle can communicate without concern about eavesdropping or a live MITM. The two devices negotiate a one-time pad which gets stored, and then a symmetric key. The key is when the OTP is exhausted, so some security is maintained. This is a simple mechanism, and an eavesdropper is not going to be able to decode a properly implemented OTP. For additional security, the key can ID itself with a public/private keypair, but in an ideal symmetric crypto setup (where there are no third parties), assymetric cryptography isn't really needed after the two parties are able to recognize and keep a shared key (think WPA2-PSK).
Devil's advocate here: Cydia is another market for apps, but its presence is highly dependent on the work the Dev Team does in getting out a usable jailbreak. It is only a matter of time where Apple has enough resistance to JBing built into their devices that when a JB is ready to go, the device is last year's model. Even then, unless the JB uses an exploit that is a hardware based one, Apple just issues a 0.0.1 fix that patches that hole and uses the SHSH mechanism to prevent downgrading.
I don't really count Cydia as a complete alternative to Apple's App Store. It may not be available for the iPhone 5 for a good long while. I consider Cydia awesome, but I wouldn't rely on it being available this time next year on Apple's next gen iOS devices.
Bingo. One of the reasons I love Android and Google's Marketplace is that some apps have a VERY fast development cycle. I have seen features requested for an app in the feedback at 1:30 PM, and an update with that feature in the app by the developer at 4:30 PM the same day. Same with bugs, someone mentions them, they get stomped by fast reacting developers in hours.
Contrast this to the iOS model where an app developer had an issue with some saved game files, uploaded an update so people can actually save their work, and it took almost 1-2 weeks for the update to appear on iTunes. This was before iTunes Connect was down for the holidays [1].
This isn't to say Amazon's model is bad. I just fear that instead of being able to choose between Google versus Amazon that the choice will be foisted upon us by whomever gives the cellular carriers a sweeter deal. Both stores have advantages and shortcomings, and having a choice is important. However, if I end up having to choose between Amazon's model versus Google's, I'd choose Google's just because it is a more open way of publishing and allows developers to get stuff fixed and added very quickly.
[1]: It is understandable Apple turned off iTunes Connect during the Christmas/New Years rush.
My point got lost here. The point is that Chinese companies actually seem to devote resources to computer security and IT infrastructure because they are seeing the mistakes companies are making on the other side of the Pacific. Even the Chinese government is laying fiber like there is no tomorrow.
Here in the US, we don't need corporate dorms -- we escaped that stuff in the Gilded age (but with the political climate, we may be heading back towards that direction.) Instead, more than just a token effort is needed in a lot of businesses when it comes to IT infrastructure and security.
Nail, head hit. I have worked for people who had bosses who had zero interest in anything other than cost. The same people that I lambast for putting basic security precautions as an extreme low priority, due to their attitude of "security has no ROI."
What is ironic is that even though this makes the quarterly figures look good, it is killing competitiveness long term. Another example is R&D. Not product research, but true R&D where people discover something, shrug, put it on a shelf for 20 years, then it becomes immensely marketable (think Corning and Gorilla Glass as the prime example of this.) Instead any groundbreaking research ends up being done overseas or by small firms which are bought out, or have their IP infringed upon. If research is done, it is for a product to cough up this quarter or perhaps this FI, and usually it is how to add a gewgaw to something existing and palm that off on the market.
You mention China. Chinese companies know how to lock their doors down. They know what happens if you run your company with your fly open, and most of the companies over there wouldn't even be in business had it not been for "borrowed" IP from the West. Take Foxconn as an example. For a company that size making so many Apple products (including ramping up production on unannounced items), they are quite airtight about what their factories produce even with the hordes of workers they have. Had this been a company run by the typical PHB here in the US (with their usual lack of interest in security), everyone and their brother would know what the iPhone 5 looks like, and perhaps even have the source code for that rendition of iOS.
I wish the US would start borrowing from China in this regard. Even with security aside, just because a company's IT infrastructure works today doesn't mean it will work 5 years, or perhaps even six months from now without major issues. Taking a charge off quarterly earnings to fix problems now means a lot of less wasted money when the upgrades have to be done post-haste.
Offsite place != password list on browser. For most sites, having the password list stored encrypted in a Web browser is likely more secure than just bouncing off of a remote site that has unknown security habits. For all we know, a site people use for logins could just be storing passwords in crypt (3) format, max 8 digits, or even plaintext with some XOR secret sauce thrown in.
Security is as good as the weakest link in the chain, and I tend to trust the machine I'm on more than I do some provider who really was not built from the ground up for security.
Of course, for critical things to daily life (bank accounts,/. account), those don't get stored/cached anywhere.
Client cert security is great in that respect. A website can keep track of the cert ID by itself, and it doesn't really matter what the CA says, wrong cert == no access. Plus, no passwords are ever exchanged, so all a blackhat can do is just grab your public key, and hope for a quantum computing breakthrough.
The downside of client cert security are two factors: First, one doesn't want to tie all their stuff to one cert, so one needs to have the ability to make multiple certificates. Second, is moving the certs in a secure fashion from place to place. If this isn't done right, the blackhat can slurp up the decrypted private key material, or tell a smart card to do signing/decryption for it, and do a MITM on the victim's computer.
One of the best proposals I've seen on/. for authentication would be a little bit awkward, but beats passwords. Enter your username at a site. The site presents a serial number. The user selects the serial number, signs it with their PGP/gpg key, and pastes the signature. The server validates the file against the key and grants/denies access. With this method, the server doesn't need to maintain much state (other than the serial number to prevent replay attacks), and no sensitive material is exchanged.
Personally, I'd never want one entity to have the keys to the kingdom. Not MS with Passport/.NET, not FB, not OpenID, nobody. I'd rather use passwords that can be memorized, a password list stored on my smartphone, or passwords stored in Firefox. I rather pack my own parachute than have not just my ID from FB connected with tons of sites, but possibly my password.
However, if people want a SSO, with their eggs in one basket, lets at least have the basket made from something stronger than crepe paper strips and a generic white glue.
This is already happening where sites depend on another for authentication. If you want Cydia to recognize you and allow you access to purchased apps, you have to authenticate from Google or FB. Someone hacks the account that the Cydia stuff depends on, they can lock a person out of hundreds of dollars of purchased items, or even possibly rack up significant charges if an Amazon login is tied in with that.
Ideally, if a website is constructed from scratch for others to use it as a SSO, it should have not just top notch security (goot luck with this, as most PHBs view security as having no ROI), as well as allow for multiple personas with no way that subscriber sites, either by ad cookies, Flash shared objects or other means can tie the personas together. If a site can't offer this, they at least need to be able to deal with multiple users from the same person.
If FB becomes the Net's SSO, it better have the following features, or else people are betting their privacy and reputation on something quite unproven:
1: Ability to have two factor authentication. OpenID isn't perfect, but one can use a VASCO token with it. The cream of the crop would be SecurID tokens. Of course, using SMS or apps on Android/iOS/BlackberryOS/etc. would be useful too.
2: If a site asks for authentication via FB, a way to ensure that the login page is genuine. PayPal is good at this. I worry about people getting spoofed by a SSL page with a FB login that isn't really from FB proper.
3: Better password recovery in case tokens get lost/stolen. At the minimum, better questions than "what is your dog's name?" Of course, the answers to these are stored as mentioned in #4 here.
4: Solid password storage. Crypto 101 here: You never store a password. Ideally, you never store a result value. What you store is some known text encrypted with the password hash (hashed a number of times to slow down brute forcing). TrueCrypt's password mechanism is the best out there.
5: A third party vetting this security mechanism. This doesn't need to be FIPS compliant (it should be though), but at least have some validation from an independent source that the authentication is done right, the data center is secure, etc.
6: SSL with all contact throughout the authentication process. This is a basic thing, but for performance reasons, sites don't like using SSL unless forced to.
7: Ideally, posting the SSL keys on some other source, so one can tell if a CA is spoofing the cert or not.
8: It's corny, but consider a unique login picture per user that is used at some sites, Yahoo being the most widely used. This way, when you enter your username, if you don't get the picture, you likely got phished.
9: Store passwords of unlimited length. I've seen too many sites which ignore any characters after the eighth one.
10: Have the ability to turn off third party logins either temporarily or permanently. For example, if one is going on vacation with no Internet connections, the ability to disable SSO logins until they come back is a solid security measure.
I'd love a ROM for these that essentially just makes the PS3 and all its features available to a Linux distribution. Similar to the Other OS functionality, except with full access to the hardware.
There are a lot of cool things a PS3 could do. It is inexpensive, reliable hardware. Of course, XMBC can address the media aspects, but for non-media, I can think of a few things (some can already be done):
1: Hook it up to an external disk array, and use it as a NAS head, with encryption. Perhaps have it rsync to a gmailfs directory for backups to the "cloud" of critical files. 2: Three Ethernet ports, so it can do some complicated firewalling/IDS/IPS/content filtering/NAT. 3: Persistent storage for a squid cache, a caching DNS, DHCP, DDNS. 4: RADIUS server for the wireless router. 5: LDAP 6: Mail gateway. 7: VPN server. 8: SSH gateway.
These are relatively boring things for a PC to do, but a PS3 has the advantage of being relatively inexpensive, reliable, and a non-x86 architecture, which may help things if an attacker manages to get arbitrary code executing.
I almost wish Sony allowed this in the first place -- there is a vast, untapped market for an all in one home server appliance, that doesn't just provide file and print serving, but authentication, caching, and many other features.
If MS has something like all-you-can-watch video similar to the all-you-can-download subscription system for the Zune, it might be something worth considering.
However, why does MS need a TV set top box? They already have one... the XBox 360.
I just wish more printers had Postscript support as a fallback when drivers are not available. Of course, some of the printer specific features wouldn't be there, but almost anything out there understands Postscript, so it can at least get B&W prints or even color on paper. Maybe not on the low end inkjets where price is everything, but at least tack it on the color laser printers that either have a NIC, or a wireless interface.
For me, the US government and police are not why I bother with encryption. In fact, they are the least of my worries because they have other means (DPI, packet logs at the carrier) to obtain data.
Where encryption comes into handy is denying criminals the information present. Something like what the parent said where people leave a house at a certain time could be used for a good time to commit a burglary or a home invasion. The note to the bookie could be used for blackmail especially if the thief found where one worked. The knowledge of where a daughter is staying may be just what the creepy guy with the empty dungeon is looking for.
I always use encryption, and highly recommend people do the same, not because of fear of the police/FBI/NSA/Illuminati/Horde/Alliance, but because it keeps a physical theft of computer equipment a physical theft -- it doesn't allow for data to be stolen as well. For example, backup hard disks. If one gets stolen, the thief has a usable HDD. However, the thief does not have the data stored on it that is protected by a FDE tool like TrueCrypt, LUKS, or FileVault.
Best of all worlds would be a hardware crypto chip that zeroes out the keys after "X" failed PIN attempts. If it is decently tamper-resistant like the chip on a CAC, it would be more than enough to protect a phone. All this chip does is store a 256 bit key , then when the device boots and the PIN is entered, hands it over to the OS to complete mounting of filesystems and booting. The OS then uses the chip to validate the PIN entry if the screen is locked. Too many wrong attempts, and the chip automatically overwrites all RAM and powers off the phone. Of course, some remote process (sshd) would have access, but this can be handled by the OS and perhaps ruleset changes via ipfw or iptables when the screen is locked/unlocked.
What affects a company affects a lot of people. My home PC gets compromised, I end up getting the consequences. A company gets nailed, there are a lot of people affected, including the employees, the clients, the vendors, the building they do business -- a whole large amount of entities, both persons and other businesses.
Blackhats know this and this is why SMBs (not to mention enterprises) are such a juicy target.
This is why most people use enterprise level security at home, and not the other way around.
I agree with you about that -- there should be a difference between a hack (as in using the CDMA pulses so you can have a strata 1 NTP server on your phone), versus an app.
On Android, apps have a lot more freedom. Take Exchange for instance. Even though Android is still lacking Exchange encryption, Touchdown from Nitrodesk provides this. Having Exchange in an app also separates it from the OS, so work and personal contacts don't end up merging.
Ten candidates (IMHO) for best Android hacks, as in true hacks:
1: Rageinthecage -- one of the most useful ways to get root. 2: nandroid -- image based backups and restores -- great if swapping ROMS and want to go back to an older one without having to reload all your apps. 3: Titanium Backup -- backs up app, app data, and market info. This way, a restore is easy. 4: Modified busybox binaries which allow a lot more uses. 5: Droidwall. If an app doesn't need to do more than phone home for licensing, it shouldn't have Net access unless part of its functionality. 6: Utilities that scale clock speed with how the device is being used. 7: Using unionfs to add space for apps in internal memory using an ext3 partition on the SD card. 8: Support for LUKS in the ROM allowing for files to be stored encrypted on the SD card. 9: Using FUSE, mounting a Gmail user as a filesystem using IMAP. Then using eCryptfs to ensure the contents are protected. 10: Using iptables to block adsites by low level IP.
I was in the same boat when my WM phone croaked last year. The WM phone was insanely customizable, had very good encryption, easy to back up, and the custom ROMS for it were excellent.
Depending on the Android phone you get (Nexus 1 and Nexus at the top of the heap for ease of customizability, and a crapshoot with other phone makers, although HTC seems to suck the least), you might be able to find a really cool, stable ROM. Usually a stable one (that dispenses with the UI junk that phone makers and cellular carriers add on) is a good bet. Add to this nandroid for being able to make backups and restore them, as well as a overclock tool, and it makes using an Android device quite pleasurable.
I wouldn't count MS out yet, but I rather wait a couple iterations and see how WP7 is going to turn out. If MS does it right, it can easily take over the Blackberry market with Sharepoint and Exchange support.
Dual core devices are not new. The HTC Wizard had this in '05. However, the phone had separate cores so the radio could do what it needed to while the OS was able to do what it needed, both cores running at a fairly low clock speed. The device had a pretty amazing battery life though.
I'd like to see multiple cores... perhaps fast and slow (but battery saving) cores and a smart process scheduler. This would go a way to help with battery life, as well as provide smoother performance for apps.
From what I read, they have to be running in the foreground for the alarm to work. If one just flips to the app and lets it sit, that's fine, but a lot of people do E-mail, FB, and other things, then hit the home screen and let the iPhone remain on the Springboard, where the app can't do an alarm unless the device is jailbroken.
Slashdot Mirror
I'm guessing one use will be following criminals from the air to relay positions. That, and keeping track of a car on a protracted chase, although from what I read, this bird doesn't have that long a radius and run time compared to a helicopter. I wonder if it is cheaper to spin something like this up than get the police in the air, so that is one reason this is being looked into.
Doesn't even need a password. Just include a variable length file of random contents in the archive.
The most secure bet is just to password protect the archive with WinRAR, have the password available in the notes (this can be easily changed around so an automatic scanner can't pick up the password, similar to how /. obfuscates E-mail addresses), and call it done.
Steering column locks are a joke to a serious thief. When I was in college out of high school, my car got broken into, and the steering column smashed open. What kept the vehicle from disappearing is the fact that I put in a kill switch so it would start, but as soon as the ignition returned to "on", it would immediately stall. So, frustrated thieves would just haul ass out of there after a few failed starts.
From what I have personally experienced. What doesn't work:
Normal car alarms.
What does work:
Kill switches. Time is not on the side of thieves, and having to fish through the dash to find the splicing is not in most of their playbooks unless the vehicle is worth it.
There are other ways to pop open cars. Take the slim jim for example. Even if that doesn't work, the metal on car doors is thin, so someone using a screwdriver to peel back the metal around the door handle, or perhaps punch the door handle in to be able to pull on the locking rod. This is why there are third party reinforcing plates sold (Jimmi Jammer) to protect against exactly that.
Other than adding heavy gauge containers (either bolting or even welding them down), it is almost impossible to stop smash-and-grabbers.
Even the manual way is susceptible to an old attack -- tryout keys. These are keys that are cut with patterns that usually tend to work on most vehicles.
I wish STRATTEC and other vehicle lock makers would change the physical lock's keyway every 2-3 years. This will cut down on people's keys randomly fitting other vehicles. Other items can be added (such as items like items found in Evva-Inox's keys) without sacrificing the reliability an automotive lock has to have.
Maybe the physical security of the lock isn't a big focus, especially because almost any lock on a vehicle can easily be sprung with a crowbar after the window glass gets smashed. However, it would be nice for carmakers to have options for heavier duty locks to help deter the smash and grab meth-head.
Fundamentally, the problem isn't like DRM, although I agree that nothing is 100% secure, and if someone can make it, someone can break it.
DRM is where Alice has encrypted to stuff to send to Bob, and wants to prevent Charlie from getting to it. However, Bob and Charlie are the same person.
The problem with the remote communication is easier (though not trivial in any way) -- Alice wants to send stuff to Bob, keep it out of Charlie's hands, and Charlie isn't connected to either endpoint.
For the standard cryptography issue, we have stuff that can withstand the test of time. However, keyfobs usually don't have the power to do regular cryptography, so shortcuts have to be taken (KeeLoq is a good example of trying to balance security with low CPU ability.)
The ideal security? Having a key cylinder that has physical contacts (or use NFC) where the key and the vehicle can communicate without concern about eavesdropping or a live MITM. The two devices negotiate a one-time pad which gets stored, and then a symmetric key. The key is when the OTP is exhausted, so some security is maintained. This is a simple mechanism, and an eavesdropper is not going to be able to decode a properly implemented OTP. For additional security, the key can ID itself with a public/private keypair, but in an ideal symmetric crypto setup (where there are no third parties), assymetric cryptography isn't really needed after the two parties are able to recognize and keep a shared key (think WPA2-PSK).
No additional DRM as a stipulation? That is just fine with me.
Devil's advocate here: Cydia is another market for apps, but its presence is highly dependent on the work the Dev Team does in getting out a usable jailbreak. It is only a matter of time where Apple has enough resistance to JBing built into their devices that when a JB is ready to go, the device is last year's model. Even then, unless the JB uses an exploit that is a hardware based one, Apple just issues a 0.0.1 fix that patches that hole and uses the SHSH mechanism to prevent downgrading.
I don't really count Cydia as a complete alternative to Apple's App Store. It may not be available for the iPhone 5 for a good long while. I consider Cydia awesome, but I wouldn't rely on it being available this time next year on Apple's next gen iOS devices.
Bingo. One of the reasons I love Android and Google's Marketplace is that some apps have a VERY fast development cycle. I have seen features requested for an app in the feedback at 1:30 PM, and an update with that feature in the app by the developer at 4:30 PM the same day. Same with bugs, someone mentions them, they get stomped by fast reacting developers in hours.
Contrast this to the iOS model where an app developer had an issue with some saved game files, uploaded an update so people can actually save their work, and it took almost 1-2 weeks for the update to appear on iTunes. This was before iTunes Connect was down for the holidays [1].
This isn't to say Amazon's model is bad. I just fear that instead of being able to choose between Google versus Amazon that the choice will be foisted upon us by whomever gives the cellular carriers a sweeter deal. Both stores have advantages and shortcomings, and having a choice is important. However, if I end up having to choose between Amazon's model versus Google's, I'd choose Google's just because it is a more open way of publishing and allows developers to get stuff fixed and added very quickly.
[1]: It is understandable Apple turned off iTunes Connect during the Christmas/New Years rush.
My point got lost here. The point is that Chinese companies actually seem to devote resources to computer security and IT infrastructure because they are seeing the mistakes companies are making on the other side of the Pacific. Even the Chinese government is laying fiber like there is no tomorrow.
Here in the US, we don't need corporate dorms -- we escaped that stuff in the Gilded age (but with the political climate, we may be heading back towards that direction.) Instead, more than just a token effort is needed in a lot of businesses when it comes to IT infrastructure and security.
Nail, head hit. I have worked for people who had bosses who had zero interest in anything other than cost. The same people that I lambast for putting basic security precautions as an extreme low priority, due to their attitude of "security has no ROI."
What is ironic is that even though this makes the quarterly figures look good, it is killing competitiveness long term. Another example is R&D. Not product research, but true R&D where people discover something, shrug, put it on a shelf for 20 years, then it becomes immensely marketable (think Corning and Gorilla Glass as the prime example of this.) Instead any groundbreaking research ends up being done overseas or by small firms which are bought out, or have their IP infringed upon. If research is done, it is for a product to cough up this quarter or perhaps this FI, and usually it is how to add a gewgaw to something existing and palm that off on the market.
You mention China. Chinese companies know how to lock their doors down. They know what happens if you run your company with your fly open, and most of the companies over there wouldn't even be in business had it not been for "borrowed" IP from the West. Take Foxconn as an example. For a company that size making so many Apple products (including ramping up production on unannounced items), they are quite airtight about what their factories produce even with the hordes of workers they have. Had this been a company run by the typical PHB here in the US (with their usual lack of interest in security), everyone and their brother would know what the iPhone 5 looks like, and perhaps even have the source code for that rendition of iOS.
I wish the US would start borrowing from China in this regard. Even with security aside, just because a company's IT infrastructure works today doesn't mean it will work 5 years, or perhaps even six months from now without major issues. Taking a charge off quarterly earnings to fix problems now means a lot of less wasted money when the upgrades have to be done post-haste.
Offsite place != password list on browser. For most sites, having the password list stored encrypted in a Web browser is likely more secure than just bouncing off of a remote site that has unknown security habits. For all we know, a site people use for logins could just be storing passwords in crypt (3) format, max 8 digits, or even plaintext with some XOR secret sauce thrown in.
Security is as good as the weakest link in the chain, and I tend to trust the machine I'm on more than I do some provider who really was not built from the ground up for security.
Of course, for critical things to daily life (bank accounts, /. account), those don't get stored/cached anywhere.
Client cert security is great in that respect. A website can keep track of the cert ID by itself, and it doesn't really matter what the CA says, wrong cert == no access. Plus, no passwords are ever exchanged, so all a blackhat can do is just grab your public key, and hope for a quantum computing breakthrough.
The downside of client cert security are two factors: First, one doesn't want to tie all their stuff to one cert, so one needs to have the ability to make multiple certificates. Second, is moving the certs in a secure fashion from place to place. If this isn't done right, the blackhat can slurp up the decrypted private key material, or tell a smart card to do signing/decryption for it, and do a MITM on the victim's computer.
One of the best proposals I've seen on /. for authentication would be a little bit awkward, but beats passwords. Enter your username at a site. The site presents a serial number. The user selects the serial number, signs it with their PGP/gpg key, and pastes the signature. The server validates the file against the key and grants/denies access. With this method, the server doesn't need to maintain much state (other than the serial number to prevent replay attacks), and no sensitive material is exchanged.
Personally, I'd never want one entity to have the keys to the kingdom. Not MS with Passport/.NET, not FB, not OpenID, nobody. I'd rather use passwords that can be memorized, a password list stored on my smartphone, or passwords stored in Firefox. I rather pack my own parachute than have not just my ID from FB connected with tons of sites, but possibly my password.
However, if people want a SSO, with their eggs in one basket, lets at least have the basket made from something stronger than crepe paper strips and a generic white glue.
This is already happening where sites depend on another for authentication. If you want Cydia to recognize you and allow you access to purchased apps, you have to authenticate from Google or FB. Someone hacks the account that the Cydia stuff depends on, they can lock a person out of hundreds of dollars of purchased items, or even possibly rack up significant charges if an Amazon login is tied in with that.
Ideally, if a website is constructed from scratch for others to use it as a SSO, it should have not just top notch security (goot luck with this, as most PHBs view security as having no ROI), as well as allow for multiple personas with no way that subscriber sites, either by ad cookies, Flash shared objects or other means can tie the personas together. If a site can't offer this, they at least need to be able to deal with multiple users from the same person.
If FB becomes the Net's SSO, it better have the following features, or else people are betting their privacy and reputation on something quite unproven:
1: Ability to have two factor authentication. OpenID isn't perfect, but one can use a VASCO token with it. The cream of the crop would be SecurID tokens. Of course, using SMS or apps on Android/iOS/BlackberryOS/etc. would be useful too.
2: If a site asks for authentication via FB, a way to ensure that the login page is genuine. PayPal is good at this. I worry about people getting spoofed by a SSL page with a FB login that isn't really from FB proper.
3: Better password recovery in case tokens get lost/stolen. At the minimum, better questions than "what is your dog's name?" Of course, the answers to these are stored as mentioned in #4 here.
4: Solid password storage. Crypto 101 here: You never store a password. Ideally, you never store a result value. What you store is some known text encrypted with the password hash (hashed a number of times to slow down brute forcing). TrueCrypt's password mechanism is the best out there.
5: A third party vetting this security mechanism. This doesn't need to be FIPS compliant (it should be though), but at least have some validation from an independent source that the authentication is done right, the data center is secure, etc.
6: SSL with all contact throughout the authentication process. This is a basic thing, but for performance reasons, sites don't like using SSL unless forced to.
7: Ideally, posting the SSL keys on some other source, so one can tell if a CA is spoofing the cert or not.
8: It's corny, but consider a unique login picture per user that is used at some sites, Yahoo being the most widely used. This way, when you enter your username, if you don't get the picture, you likely got phished.
9: Store passwords of unlimited length. I've seen too many sites which ignore any characters after the eighth one.
10: Have the ability to turn off third party logins either temporarily or permanently. For example, if one is going on vacation with no Internet connections, the ability to disable SSO logins until they come back is a solid security measure.
I'd love a ROM for these that essentially just makes the PS3 and all its features available to a Linux distribution. Similar to the Other OS functionality, except with full access to the hardware.
There are a lot of cool things a PS3 could do. It is inexpensive, reliable hardware. Of course, XMBC can address the media aspects, but for non-media, I can think of a few things (some can already be done):
1: Hook it up to an external disk array, and use it as a NAS head, with encryption. Perhaps have it rsync to a gmailfs directory for backups to the "cloud" of critical files.
2: Three Ethernet ports, so it can do some complicated firewalling/IDS/IPS/content filtering/NAT.
3: Persistent storage for a squid cache, a caching DNS, DHCP, DDNS.
4: RADIUS server for the wireless router.
5: LDAP
6: Mail gateway.
7: VPN server.
8: SSH gateway.
These are relatively boring things for a PC to do, but a PS3 has the advantage of being relatively inexpensive, reliable, and a non-x86 architecture, which may help things if an attacker manages to get arbitrary code executing.
I almost wish Sony allowed this in the first place -- there is a vast, untapped market for an all in one home server appliance, that doesn't just provide file and print serving, but authentication, caching, and many other features.
If MS has something like all-you-can-watch video similar to the all-you-can-download subscription system for the Zune, it might be something worth considering.
However, why does MS need a TV set top box? They already have one... the XBox 360.
I just wish more printers had Postscript support as a fallback when drivers are not available. Of course, some of the printer specific features wouldn't be there, but almost anything out there understands Postscript, so it can at least get B&W prints or even color on paper. Maybe not on the low end inkjets where price is everything, but at least tack it on the color laser printers that either have a NIC, or a wireless interface.
For me, the US government and police are not why I bother with encryption. In fact, they are the least of my worries because they have other means (DPI, packet logs at the carrier) to obtain data.
Where encryption comes into handy is denying criminals the information present. Something like what the parent said where people leave a house at a certain time could be used for a good time to commit a burglary or a home invasion. The note to the bookie could be used for blackmail especially if the thief found where one worked. The knowledge of where a daughter is staying may be just what the creepy guy with the empty dungeon is looking for.
I always use encryption, and highly recommend people do the same, not because of fear of the police/FBI/NSA/Illuminati/Horde/Alliance, but because it keeps a physical theft of computer equipment a physical theft -- it doesn't allow for data to be stolen as well. For example, backup hard disks. If one gets stolen, the thief has a usable HDD. However, the thief does not have the data stored on it that is protected by a FDE tool like TrueCrypt, LUKS, or FileVault.
Best of all worlds would be a hardware crypto chip that zeroes out the keys after "X" failed PIN attempts. If it is decently tamper-resistant like the chip on a CAC, it would be more than enough to protect a phone. All this chip does is store a 256 bit key , then when the device boots and the PIN is entered, hands it over to the OS to complete mounting of filesystems and booting. The OS then uses the chip to validate the PIN entry if the screen is locked. Too many wrong attempts, and the chip automatically overwrites all RAM and powers off the phone. Of course, some remote process (sshd) would have access, but this can be handled by the OS and perhaps ruleset changes via ipfw or iptables when the screen is locked/unlocked.
What affects a company affects a lot of people. My home PC gets compromised, I end up getting the consequences. A company gets nailed, there are a lot of people affected, including the employees, the clients, the vendors, the building they do business -- a whole large amount of entities, both persons and other businesses.
Blackhats know this and this is why SMBs (not to mention enterprises) are such a juicy target.
This is why most people use enterprise level security at home, and not the other way around.
I agree with you about that -- there should be a difference between a hack (as in using the CDMA pulses so you can have a strata 1 NTP server on your phone), versus an app.
On Android, apps have a lot more freedom. Take Exchange for instance. Even though Android is still lacking Exchange encryption, Touchdown from Nitrodesk provides this. Having Exchange in an app also separates it from the OS, so work and personal contacts don't end up merging.
Ten candidates (IMHO) for best Android hacks, as in true hacks:
1: Rageinthecage -- one of the most useful ways to get root.
2: nandroid -- image based backups and restores -- great if swapping ROMS and want to go back to an older one without having to reload all your apps.
3: Titanium Backup -- backs up app, app data, and market info. This way, a restore is easy.
4: Modified busybox binaries which allow a lot more uses.
5: Droidwall. If an app doesn't need to do more than phone home for licensing, it shouldn't have Net access unless part of its functionality.
6: Utilities that scale clock speed with how the device is being used.
7: Using unionfs to add space for apps in internal memory using an ext3 partition on the SD card.
8: Support for LUKS in the ROM allowing for files to be stored encrypted on the SD card.
9: Using FUSE, mounting a Gmail user as a filesystem using IMAP. Then using eCryptfs to ensure the contents are protected.
10: Using iptables to block adsites by low level IP.
I was in the same boat when my WM phone croaked last year. The WM phone was insanely customizable, had very good encryption, easy to back up, and the custom ROMS for it were excellent.
Depending on the Android phone you get (Nexus 1 and Nexus at the top of the heap for ease of customizability, and a crapshoot with other phone makers, although HTC seems to suck the least), you might be able to find a really cool, stable ROM. Usually a stable one (that dispenses with the UI junk that phone makers and cellular carriers add on) is a good bet. Add to this nandroid for being able to make backups and restore them, as well as a overclock tool, and it makes using an Android device quite pleasurable.
I wouldn't count MS out yet, but I rather wait a couple iterations and see how WP7 is going to turn out. If MS does it right, it can easily take over the Blackberry market with Sharepoint and Exchange support.
Dual core devices are not new. The HTC Wizard had this in '05. However, the phone had separate cores so the radio could do what it needed to while the OS was able to do what it needed, both cores running at a fairly low clock speed. The device had a pretty amazing battery life though.
I'd like to see multiple cores... perhaps fast and slow (but battery saving) cores and a smart process scheduler. This would go a way to help with battery life, as well as provide smoother performance for apps.
From what I read, they have to be running in the foreground for the alarm to work. If one just flips to the app and lets it sit, that's fine, but a lot of people do E-mail, FB, and other things, then hit the home screen and let the iPhone remain on the Springboard, where the app can't do an alarm unless the device is jailbroken.