Android already has sandboxing. Every app installs under its own user ID by default, and if it wants more permissions, it will ask the user on install, and the user can deny it.
Even if this app had no permissions whatsoever except to display on the screen and send info back to a server, it would be successful, as it made for social engineering, as opposed to having the primary function as being compromise of the Android device.
I'd say it is a change that is not going away post 30. I've seen people start texting when it came available and still do today, because it has become easier than a voice call in a number of situations, and that text messages almost always get through. Plus, it beats voice mail especially for a very short note such as "we arrived at the pub."
The main technology that was replaced by texting is the pager. A lot of pagers will miss the signal being set out by the broadcast station, especially in a server room. So one used to work in a data center, come out, then get your manager telling you about angry people in other departments who say they have been paging you for hours repeatedly because of something. Since most pagers were one-way, the paging service could only send out a single paging notification. Now, as soon as one steps out of the data center, a text message gets received. This way one can reply "call the helldesk because IT is not allowed to work on items without a trouble ticket. If you don't like that, please have your department manager call IT's so the proper time is credited. [1]" Of course, some two-way pagers would have services which would resend until the pager acknowledged that it got the page, but those were few and far between.
Before SMS, it also took some effort to send something more than just a phone number to a pager. You either had to have a terminal or two-way pager, or in some cases, call the paging service's operator and dictate a text.
Eventually cellphones got some sort of paging feature where you could leave a message, or hit "5" on the voice mail and leave a text page. This was good because the phone, being a two way device, would eventually pick up the notification.
Compared to the catch-as-catch-can system of one way pagers, and even two way pagers which required spending time calling voice mail, SMS is a lot nicer. It doesn't matter what network someone is on for cellphone service, you can reach them. And if more details are needed, one can just fire up a voice call. You also don't need to be paying for a paging service on top of your cellphone service (and paging services got expensive, easily $100-$200 a month if you have a two way pager that allowed you to reply.) Finally, with device convergence, one only needs a single device, perhaps two (home/work phones) on the belt. Gone are the days of a sysadmin having to have a Batman-esque belt with a pager, a PDA, and a cellphone at all times at work, and when on call.
Of course, MMS gives some advantages. If you don't have someone's E-mail, you can send them a copy of the Excel document they have been wanting to their phone.
[1]: In medium to large businesses, having everything documented on trouble tickets means the difference between getting additional admins to handle tasks come the next FY, versus losing headcount because of the perception that IT is not doing anything. If you don't have it documented on a trouble ticket, it didn't happen.
Good. This was changed from when the authenticators would require a fax of ID info before it would be removed on Blizzard's end. Now, I just wish Blizzard (technically Vasco) could make an Android app.
An app is just as good, provided the phone isn't compromised. As of now, malware on devices isn't a major issue, and most devices have a very solid privilige system to ensure that one app can't compromise another (Android's system is the best because each app is signed and has its own UID and unless it asks for the privs on install, it cannot access other app's data.)
Optimally, the best of all worlds would be an app that signs/decrypts a private key on the SIM card (key never leaves the card), and the iPhone, Android, or Java app is just a UI front end to that.
The best of all worlds would be having this type of authentication be present on a generic SIM card app. This way, one can replace their cellphone, or swap from the Blackberry used for work to a low-end "phone and SMS only" model for weekends, and still have the unique authentication sequence needed for banks and other things. Since SIM cards already have a PIN mechanism in place that blocks access after 3-10 attempts, this is a perfect place to store authentication credentials.
Of course, there are CDMA providers, but R-UIM cards should offer the same functionality. For CDMA providers that are not using R-UIM cards... well, we can always dream.
I also worked for companies that had this problem. What I did was buy a USB card that had an internal slot, and not just all external ports. I then plugged the dongle into that. This way, if someone wanted to take the licensing controller, they would have to take the machine off the rack (decently secure datacenter, locked rack enclosure, security screws [1],) and crack it open (padlocked and sealed [2] case, intrusion sensors) which would certainly be noticed. [3]
[1]: They are not secure against a determined attacker who would slot the screw with a Dremel tool, but it will slow someone down, and be obvious to the cameras present.
[2]: http://www.americancasting.com/info-padlock-seals-xpc-2.asp is what I use on the back of cases. I could use the plastic seals, but with these, there is no excuse of "accidently" snapping one off. Disclaimer: I am not affiliated in any way with either of these products, but these do the job for the security needs.
[3]: Musicians have a similar issue. People know that certain music products have license key dongles and that if it gets stolen, the software vender will not replace them, so thieves will prowl nightclubs to look for the dongles and yank them out of laptops. My solution to this with musicians who have rackmount equipment is a 2-3U locking drawer that has a USB hub in the back and the cable threaded in such a way that a strong pull only will detach the cable, and not bring along any goodies with it.
I am not a fan of anything mandatory, but I do like having it as an option for these reasons:
1: An account stolen can mean tens of thousands of dollars to a blackhat organization which can be used to make nastier keyloggers. Usually the account is then botted out with mining hacks until it trips a Blizzard sensor serverside and gets autobanned. Of course, said account has any goods that are on it stripped and the cash bounced from account to account in order to "launder it".
2: My account is an identity. There are some people whom I can only reach through WoW (people stationed overseas, for example.) So, in-game mail is usually the best way to keep in contact with them. Having that compromised wouldn't be good.
3: Passwords need to go the way of the dodo when it comes to public authentication. I'd love to see a standard replacement (not just openID, but something that can be used for authentication on standalone servers not dependant on anyone else's) where one can have the card communicate online to trade public keys, then do offline authentication from there on out, similar to how Bluetooth devices get paired up initially, then function securely when separated. Ultimately, client certificates on a smart card would be the best replacement, but this can be beaten by active malware which intercepts browser requests doing a MITM and displaying bogus info to the user.
I wouldn't mind a smart card attached to US driver's licenses worked as a US DoD CAC, or like the Finnish design.
Believe it or not, cards like this could make a whole privacy ecosystem. Picture if once the government CA certifies the card is yours, then all they have to do is stick a signed certificate that you are over 18 or 21 on it. Then, all you do is swipe the card at a bar, and the bar not just assured that they are not breaking laws, but they don't have to know your birthdate, name, or any other info.
Similar certificates can be used too. A college can sign someone's key saying they graduated with a B. S. in chainsaw fencing. The accreditation agency can sign the college's cert ensuring that at the time the degree passed standards. A police station could scan someone's criminal record and issue a SLC (short lived certificate) saying that for these 30 days, an application has been proven to have -no- criminal history.
This would improve privacy tremendously. Just have a certificate stating the critical piece of information, no more. Of course, giving the user the ability to show/hide certificates on a key would be good as well.
We already have this: Client certificates. These are a standard function of most Web browsers. Even mobile browsers (PIE for example) handle this without issue. What one does is store one's private client key in a smart card (I use Aladdin eTokens, there are other brands. Make sure you can find a driver and PKCS #11 compatibility for the OS in question.)
What does this give? If malware affects a machine, there is no way to copy the private key out of the smart card (the signing and decrypting are done on the smart card, not on the computer.)
Of course, this ups the malware attack level -- capture the user's PIN and silently use the device if plugged in, but this is a *lot* more intrusive and an active attack than just a passive keylogger which can compromise 99.99% of all site logins today.
You can add a PINpad onto the smart card, but again, how does one know if it was an authentic Web browser wanting access before logging in, versus malware wanting to insert itself in a MITM attack between the browser and the site (IBM's ZTIC is for defending against this.)
The trick is raising the security barrier. A program that does active MITM attacks is a lot easier to find and smash by an IDS than one that just hooks an interrupt and sits in the background spitting packets out every so often to the blackhat's site.
I have two issues with authenticators. First, what happens if the battery dies? On PayPal, you can have multiple authenticators to prevent having to send faxes and prove you are you, if one of them gives up the ghost. IIRC [1], Blizzard only allows one authenticator, and if that one decides to take a dirt nap, it is very difficult to regain control of an account.
Blizzard's authenticators are OK, they are rebranded VASCO DigiPass Go 6 models (PayPal uses DigiPass Go 3s.) For the money, they are a great buy.
My other issue is that the software authentication is for a number of phones and Java based, but none for Windows Mobile, nor Android. It would be nice to see an Android app that can do this functionality. Combine this with mobile authentication, and this would be a solid winner with some failsafe-ness built in. Of course, if someone loses their phone, that could be a problem, but that is why one would have software authentication as well as a device that gets tucked away somewhere safe.
Best of all worlds would be standard offline authenticator software (OATH compatible, etc) that is built into the iPhone OS, Android, and other phone operating systems. It would be seeded via a SMS handshake, then the user can just pull up the application, enter a PIN to unlock the app, copy the number showing on the screen either into a window asking for it, or append it to one's password, and have secure, standard offline access regardless of application.
[1]: I could be completely wrong, but I didn't find any documentation to state otherwise.
Don't forget that the computing time (big O) goes up by the cube of the size of the key when doing RSA. So something that takes 2 seconds at 1024 bits will take 8 seconds at 2048 bits.
Right now, RSA is still solid if you use at least 2048 bits for your key (which is the maximum size of a lot of smart cards). However, the key sizes that RSA needs are getting so large (some recommendations on keylength.com even go near 16384 bit keys), that it might be good to find another algorithm like ECC which only uses 200-300 bits for a secure key.
Hardware encrypted USB drives offer two things over software:
1: Can be made to be platform independent. The encryption can work just as well if you plug the drive on an AIX machine, just as if you plugged it onto Windows.
2: It does not require root or admin level privs, especially if one is using computers at a public computer lab which are locked down completely. Some universities lock down their computer labs, so having the AES encryption in hardware is the only way to ensure that private documents stay private.
Just like the filesystem problem, unfortunately, there is no one block encryption standard that allows mounting filesystems across all platforms. The closest is likely TrueCrypt because it supports Linux, Macs, and Windows. However other widely used platforms like AIX, Solaris, and HP-UX are left out.
There is one thing about your drives that is cool -- enterprise level administration. This way, should an employee leave a company (assuming they relenquish possession of the drive), the data is still recoverable.
Even without that, that type of encrypted drive is something I wish universities and colleges would give out to their professors who store their lesson plans and tests on removable flash media. This way, if someone rips off the drive from a faculty computing place, it won't reveal the answers to upcoming exams. Also, with the enterprise recovery, should someone lose a password, recovery is easy.
This is why some cryptosystems which still use 56 or 64 bit keys with AES use a method called key strengthening. If a 56 key is going to be used in a cryptosystem, it gets hashed a large number of times to delay CPU usage. This way, an attacker has to spend the CPU cycles on the 2^56 keyspace on each key before they can check to see if that is a valid guess or not.
TrueCrypt does this. It does a number of hashing iterations of the passphrase before it is attempted to be used as a key to open a volume.
This is why I like drives with proven security records like the IronKey, as well as smart cards. The controller doesn't just want a key for decryption, it will stop bad password guesses by either adding a longer and longer delay time before a password request ir processed, or just overtly erase stored keys after someone guesses wrong. Of course, I'm sure some well-heeled organization with an advanced chip fab can take a smart card apart to yank out a stored key, but an organization that rich likely will start with a rubber hose first (cue proper XKCD panel here.)
Instead of unlimited guesses, a proper security device limits the amount of brute force guesses to 3-20 or so before the curtain goes down.
If this was done knowingly, this is only going to bite the makers in the butt. There are already proven solid USB flash drives (IronKey) that have solid AES encryption and a very good authentication mechanism, and it will make those drives stand out for people who want solid security.
What will happen if hardware USB flash drives prove wanting is that more companies will resort to using software based encryption packages to ensure the contents are encrypted. BitLocker is part of the operating system (and in businesses, Windows 7 Enterprise is the only edition of Windows 7 which uses KMS-based activation so expect that to be the most common edition of Windows in businesses, and that edition has BitLocker.) PGP and other third party security companies also offer policies that can completely encrypt removable media before it is allowed to be written to.
So, unless hardware drive providers can provide us assurances of security, companies will take their cash to PointSec and PGP Incorporated and only buy the bare-bones models USB flash drives without the advanced security features, as the software provides both the security, as well as enterprise level assurance that if the media is removable, it will be encrypted.
What is funny is that in 1991, the NeXT had an implementation of ECC Fast Elliptic Encryption as part of the OS (think NeXTStep 2). However due to ITAR regs, it was removed from subsequent versions.
If symmetric key cryptography gets broken in general, what likely will happen is that the well heeled businesses would have a link between sites using quantum encryption. This link is extremely slow, so it would be used to set up session keys. Then the conventional Internet links would be used for the bulk data transfer.
People who don't have the cash for fiber optics would have to use lower tech means. One means would be have people generate a one time pad, and instead of PGP/gpg keysigning parties, people would trade chunks of random numbers with each other. Later on, people would go home and XOR the keyfile they got with the keyfile for a persistant key, and that would then be used with some other system (sha-512 hash of date/time + the keyfile) for a message based key. This way, a known plaintext attack wouldn't reveal the long term key (similar to a shared WPA2-PSK secret).
Where things would get hairy with no public key encryption are one to many transactions, such as communicating with a bank. This probably would end up getting solved by some type of smart card system where the bank's servers have a large amount of shared keys, while the customer would have a smart card that would handle the session key generation, but prevent the shared key from leaving the secure container.
What I find so ironic about MBA programs is that one of the required things they teach in the class lineup is management and employee morale. Employee morale isn't just liquid latex Fridays or coffee in the break room. It takes actual diplomacy and person to person interaction, so people don't just go to work for a paycheck, but actually feel valued.
Why is this important? A lot more work gets done at a company where salaried people are willing to work on something, just to make sure the company makes a sales goal, as opposed to people just wanting to "do their eight and out the gate." Don't forget that high morale makes the need for internal security less pressing because employees will be proactive in security issues.
The MBA degree isn't the issue as much as the people who get the degree tend to not heed what they are taught, and had to pass in order to receive that degree. So, a PHB who has an MBA who runs a company into the ground does know the consequences about bad company morale, and has no excuse about not knowing what would happen.
There are two problems with that statement: First, the app market is saturated, and not just the iPhone. Even Android's market is starting to bulge at the seams with fart apps and Tetris clones.
Second, a lot of IT people would form companies, but there are products which just can't be made in the backyard. They require some initial VC funding because it requires a machine shop, studio, crypt, or other place with specialized equipment, and money to invest in equipment.
For example, say I wanted to go into business selling some type of enterprise equipment. I'd need to have an office. I'd then need to have the machines and the raw material (studio and tapes, CNC machine and billets, etc.) Even before the first thing I wanted to sell rolled off the line, I'd have to have hundreds of thousands invested. And there isn't any way around this with a number of things. Maybe you could do a prototype on a shoestring, but you can't sell these to a customer unless you find someone ready, willing, and able to take a gamble with your product so it goes from a prototype and into customers' hands.
So, starting a business is a lot harder than you think. If your city has a SCORE, visit them with your ideas. It may hurt finding out that what you have isn't doable, but it is better to find it out there than after you sold your house and are hundreds of grand invested... and don't even have a single dollar in income yet.
What puts this in perspective is being asked by other people why I use a commercial E-mail service when Gmail/Hotmail/Yahoo/whatever is free. My response, of course, is "TANSTAAFL". What I pay for when I use a commercial provider is not just a TOS with solid privacy features (stored data being delivered on lawful court order as opposed to request), but the fact that the data stored is my data. It isn't going to be handed over to be sifted through for marketing or advertising, nor will it be used to sling ads at me.
I would add some more rules onto that after backups and encryption because cloud computing also covers networking, communications, and even virtual machines:
1: Don't create VM instances with sensitive data on machines you don't control. Yes, cloud functionality is awesome because you can create a VM you can ssh or RDP in that has a lot of CPU cycles. However, said VM is sitting on someone else's hardware, and has the possibility be shut down and imaged at any time, and the data given away. Even if one enables full disk encryption, the cloud computing provider has full access to the VM's RAM.
2: Use gpg or PGP, and consider a keysigning party or two [1]. gpg has the advantage of being able to be used as part of a MUA as an add-on, or used completely separate as a manual decryption mechanism. To a lesser extent S/MIME is good too, but it requires a dedicated MUA, and only Blackberries and Windows Mobile devices support it. Tell people to send confidential information encrypted. This way, should the mail spool get compromised, the blackhats won't be able to get any further than headers.
3: Offsite backup services like Mozy or others have the ability for the client to encrypt with a keyfile. For me, this is "good enough". For others with REALLY sensitive stuff, this is not acceptable at all, because one is letting someone else "pack your parachute" for you, with their encryption standard. Know your security needs. For me, this is an acceptable risk. If you are leery of this, put Mozy in a VM and share the directory with the TrueCrypt volume [2] that has the data you want backed up. This way, Mozy only sees the encrypted volume, no matter what it did inside the virtual machine.
4: If you use offsite storage, periodically log on to check your files still exist. I personally recommend gpg signing all files before you upload them just in case of corruption (or just sign/encrypt.) Don't forget to keep your gpg keys in a safe place [3].
5: Always remember if backing up to a cloud provider, cloud storage requires a good network connection. Backups are easy, but if you have a ton of data to recover, a restore may be a headache, or may require asking the cloud provider for media to be shipped via FedEx. Make sure to do backups to a local drive too. With utilities like Time Machine for the Mac, Acronis TrueImage or Retrospect for Windows, or bru for UNIX, this is an absolute no brainer to do.
[1]: I've made sure people's PGP/gpg keys were from whom they were by a number of means. If you can't do a keysigning party, sometimes you can ask the other person and set up a mutual passphrase where they can send you their public key, and you can send them your key. This way, the passphrase is only used for that exchange, and both parties can sign off on the keys as trusted.
[2]: On a Mac, you can get decent security through using the Disk Utility, and sparse bundles because the backup program would only have to copy the bands that were changed.
[3]: If you use the commercially licensed version of PGP, one idea is to generate multiple keys on a few smart cards, then have them all be ADKs and revocation agents for the cards. This way, if one card dies, you still have access to your protected stuff, as well can put out a revocation cert for the dead private key. To a lesser extent, you can copy the same keyfile to multiple cards in TrueCrypt, and store your private keys in a protected TrueCrypt volume that is only accessible by the keyfile on the smart cards.
The Web browser can be extremely secure. However, attackers are going after isn't the browser any more. They are gunning for the add-ons, both the big names and the small things. All it takes is a hole in even a relative obscure add-on, and an attacker now has code running in a security context of the add-on. As it stands now, the security context of an add-on is the same as the browser, which is usually the same as the user... and often times having root privs.
Even user nobody is somebody. You want a security context where if the buffer overflow bug in an image library gets used, the malicious software ends up with just the context of the library -- it can display something in a certain window, and no more. No access to intercept keystrokes. No filesystem access. No access to other threads, much less other processes.
For the best performance and security, the heavy lifting of a sandbox needs to be handled by the OS, while the Web browser specifies the hard and soft limits of what processes the add-ons it is about to spawn. A JPEG library needs only enough RAM and CPU to take a file, decompress it, and slap it on the space the browser specifies. A generic scripting language will need more than that, perhaps access to the keyboard if the window is in the foreground. In no case, should an add-on have a context equal to the user unless the Web browser is downloading a file at the user's behest, copying/pasting to other applications, and requesting a file to be uploaded at a user's behest.
The problem is that working from home does give you more hours to do better work, but because you are not in the office, you arn't visible. This can mean that the PHB who sees Joe Sixpack in his office, even though he plays WoW at work most of the time will put him ahead of the people who work at home when it comes time for the promotions.
Work at home people also end up madogiwazoku ("window seat worker") in a lot of businesses. This means at best they keep the position they have, but end up out of the chain of command because they are often essentially forgotten about.
If you do work at home, only do it for a couple days. Other than that, make sure people see you and make sure to have some type of presence in the office. This way, you are not invisible (and to a PHB, disposable).
Re:idiocy? Incompetence?
on
Y2.01K
·
· Score: 2, Insightful
Its neither. It's ROI and worrying about this quarter's earnings over anything else, pure and simple. Because there isn't any primary returns from finding date errors in the future, businesses just won't plunk down funds to fix them, and will reactively fix problems when they happen. I see this a lot in businesses, and not just the big boys. Plenty of SMBs also are not interested in hearing about anything they need to spend their money on, but stuff that has a positive return. They would rather forget about time issues. When zero hour happens, most feel that they can hire a ton of consultants to fix any problems that arise, even though it costs way more than if it was fixed before stuff failed.
Just the same with computer security because to a typical MBA++ PHB, security gives no financial gains. I've heard so many times, "I'm not worried. If I get hacked, I'll just call the Geek Squad guys and they will fix it."
Slashdot Mirror
Android already has sandboxing. Every app installs under its own user ID by default, and if it wants more permissions, it will ask the user on install, and the user can deny it.
Even if this app had no permissions whatsoever except to display on the screen and send info back to a server, it would be successful, as it made for social engineering, as opposed to having the primary function as being compromise of the Android device.
I'd say it is a change that is not going away post 30. I've seen people start texting when it came available and still do today, because it has become easier than a voice call in a number of situations, and that text messages almost always get through. Plus, it beats voice mail especially for a very short note such as "we arrived at the pub."
The main technology that was replaced by texting is the pager. A lot of pagers will miss the signal being set out by the broadcast station, especially in a server room. So one used to work in a data center, come out, then get your manager telling you about angry people in other departments who say they have been paging you for hours repeatedly because of something. Since most pagers were one-way, the paging service could only send out a single paging notification. Now, as soon as one steps out of the data center, a text message gets received. This way one can reply "call the helldesk because IT is not allowed to work on items without a trouble ticket. If you don't like that, please have your department manager call IT's so the proper time is credited. [1]" Of course, some two-way pagers would have services which would resend until the pager acknowledged that it got the page, but those were few and far between.
Before SMS, it also took some effort to send something more than just a phone number to a pager. You either had to have a terminal or two-way pager, or in some cases, call the paging service's operator and dictate a text.
Eventually cellphones got some sort of paging feature where you could leave a message, or hit "5" on the voice mail and leave a text page. This was good because the phone, being a two way device, would eventually pick up the notification.
Compared to the catch-as-catch-can system of one way pagers, and even two way pagers which required spending time calling voice mail, SMS is a lot nicer. It doesn't matter what network someone is on for cellphone service, you can reach them. And if more details are needed, one can just fire up a voice call. You also don't need to be paying for a paging service on top of your cellphone service (and paging services got expensive, easily $100-$200 a month if you have a two way pager that allowed you to reply.) Finally, with device convergence, one only needs a single device, perhaps two (home/work phones) on the belt. Gone are the days of a sysadmin having to have a Batman-esque belt with a pager, a PDA, and a cellphone at all times at work, and when on call.
Of course, MMS gives some advantages. If you don't have someone's E-mail, you can send them a copy of the Excel document they have been wanting to their phone.
[1]: In medium to large businesses, having everything documented on trouble tickets means the difference between getting additional admins to handle tasks come the next FY, versus losing headcount because of the perception that IT is not doing anything. If you don't have it documented on a trouble ticket, it didn't happen.
Good. This was changed from when the authenticators would require a fax of ID info before it would be removed on Blizzard's end. Now, I just wish Blizzard (technically Vasco) could make an Android app.
An app is just as good, provided the phone isn't compromised. As of now, malware on devices isn't a major issue, and most devices have a very solid privilige system to ensure that one app can't compromise another (Android's system is the best because each app is signed and has its own UID and unless it asks for the privs on install, it cannot access other app's data.)
Optimally, the best of all worlds would be an app that signs/decrypts a private key on the SIM card (key never leaves the card), and the iPhone, Android, or Java app is just a UI front end to that.
The best of all worlds would be having this type of authentication be present on a generic SIM card app. This way, one can replace their cellphone, or swap from the Blackberry used for work to a low-end "phone and SMS only" model for weekends, and still have the unique authentication sequence needed for banks and other things. Since SIM cards already have a PIN mechanism in place that blocks access after 3-10 attempts, this is a perfect place to store authentication credentials.
Of course, there are CDMA providers, but R-UIM cards should offer the same functionality. For CDMA providers that are not using R-UIM cards... well, we can always dream.
I also worked for companies that had this problem. What I did was buy a USB card that had an internal slot, and not just all external ports. I then plugged the dongle into that. This way, if someone wanted to take the licensing controller, they would have to take the machine off the rack (decently secure datacenter, locked rack enclosure, security screws [1],) and crack it open (padlocked and sealed [2] case, intrusion sensors) which would certainly be noticed. [3]
[1]: They are not secure against a determined attacker who would slot the screw with a Dremel tool, but it will slow someone down, and be obvious to the cameras present.
[2]: http://www.americancasting.com/info-padlock-seals-xpc-2.asp is what I use on the back of cases. I could use the plastic seals, but with these, there is no excuse of "accidently" snapping one off. Disclaimer: I am not affiliated in any way with either of these products, but these do the job for the security needs.
[3]: Musicians have a similar issue. People know that certain music products have license key dongles and that if it gets stolen, the software vender will not replace them, so thieves will prowl nightclubs to look for the dongles and yank them out of laptops. My solution to this with musicians who have rackmount equipment is a 2-3U locking drawer that has a USB hub in the back and the cable threaded in such a way that a strong pull only will detach the cable, and not bring along any goodies with it.
I am not a fan of anything mandatory, but I do like having it as an option for these reasons:
1: An account stolen can mean tens of thousands of dollars to a blackhat organization which can be used to make nastier keyloggers. Usually the account is then botted out with mining hacks until it trips a Blizzard sensor serverside and gets autobanned. Of course, said account has any goods that are on it stripped and the cash bounced from account to account in order to "launder it".
2: My account is an identity. There are some people whom I can only reach through WoW (people stationed overseas, for example.) So, in-game mail is usually the best way to keep in contact with them. Having that compromised wouldn't be good.
3: Passwords need to go the way of the dodo when it comes to public authentication. I'd love to see a standard replacement (not just openID, but something that can be used for authentication on standalone servers not dependant on anyone else's) where one can have the card communicate online to trade public keys, then do offline authentication from there on out, similar to how Bluetooth devices get paired up initially, then function securely when separated. Ultimately, client certificates on a smart card would be the best replacement, but this can be beaten by active malware which intercepts browser requests doing a MITM and displaying bogus info to the user.
I wouldn't mind a smart card attached to US driver's licenses worked as a US DoD CAC, or like the Finnish design.
Believe it or not, cards like this could make a whole privacy ecosystem. Picture if once the government CA certifies the card is yours, then all they have to do is stick a signed certificate that you are over 18 or 21 on it. Then, all you do is swipe the card at a bar, and the bar not just assured that they are not breaking laws, but they don't have to know your birthdate, name, or any other info.
Similar certificates can be used too. A college can sign someone's key saying they graduated with a B. S. in chainsaw fencing. The accreditation agency can sign the college's cert ensuring that at the time the degree passed standards. A police station could scan someone's criminal record and issue a SLC (short lived certificate) saying that for these 30 days, an application has been proven to have -no- criminal history.
This would improve privacy tremendously. Just have a certificate stating the critical piece of information, no more. Of course, giving the user the ability to show/hide certificates on a key would be good as well.
We already have this: Client certificates. These are a standard function of most Web browsers. Even mobile browsers (PIE for example) handle this without issue. What one does is store one's private client key in a smart card (I use Aladdin eTokens, there are other brands. Make sure you can find a driver and PKCS #11 compatibility for the OS in question.)
What does this give? If malware affects a machine, there is no way to copy the private key out of the smart card (the signing and decrypting are done on the smart card, not on the computer.)
Of course, this ups the malware attack level -- capture the user's PIN and silently use the device if plugged in, but this is a *lot* more intrusive and an active attack than just a passive keylogger which can compromise 99.99% of all site logins today.
You can add a PINpad onto the smart card, but again, how does one know if it was an authentic Web browser wanting access before logging in, versus malware wanting to insert itself in a MITM attack between the browser and the site (IBM's ZTIC is for defending against this.)
The trick is raising the security barrier. A program that does active MITM attacks is a lot easier to find and smash by an IDS than one that just hooks an interrupt and sits in the background spitting packets out every so often to the blackhat's site.
I have two issues with authenticators. First, what happens if the battery dies? On PayPal, you can have multiple authenticators to prevent having to send faxes and prove you are you, if one of them gives up the ghost. IIRC [1], Blizzard only allows one authenticator, and if that one decides to take a dirt nap, it is very difficult to regain control of an account.
Blizzard's authenticators are OK, they are rebranded VASCO DigiPass Go 6 models (PayPal uses DigiPass Go 3s.) For the money, they are a great buy.
My other issue is that the software authentication is for a number of phones and Java based, but none for Windows Mobile, nor Android. It would be nice to see an Android app that can do this functionality. Combine this with mobile authentication, and this would be a solid winner with some failsafe-ness built in. Of course, if someone loses their phone, that could be a problem, but that is why one would have software authentication as well as a device that gets tucked away somewhere safe.
Best of all worlds would be standard offline authenticator software (OATH compatible, etc) that is built into the iPhone OS, Android, and other phone operating systems. It would be seeded via a SMS handshake, then the user can just pull up the application, enter a PIN to unlock the app, copy the number showing on the screen either into a window asking for it, or append it to one's password, and have secure, standard offline access regardless of application.
[1]: I could be completely wrong, but I didn't find any documentation to state otherwise.
Don't forget that the computing time (big O) goes up by the cube of the size of the key when doing RSA. So something that takes 2 seconds at 1024 bits will take 8 seconds at 2048 bits.
Right now, RSA is still solid if you use at least 2048 bits for your key (which is the maximum size of a lot of smart cards). However, the key sizes that RSA needs are getting so large (some recommendations on keylength.com even go near 16384 bit keys), that it might be good to find another algorithm like ECC which only uses 200-300 bits for a secure key.
Hardware encrypted USB drives offer two things over software:
1: Can be made to be platform independent. The encryption can work just as well if you plug the drive on an AIX machine, just as if you plugged it onto Windows.
2: It does not require root or admin level privs, especially if one is using computers at a public computer lab which are locked down completely. Some universities lock down their computer labs, so having the AES encryption in hardware is the only way to ensure that private documents stay private.
Just like the filesystem problem, unfortunately, there is no one block encryption standard that allows mounting filesystems across all platforms. The closest is likely TrueCrypt because it supports Linux, Macs, and Windows. However other widely used platforms like AIX, Solaris, and HP-UX are left out.
There is one thing about your drives that is cool -- enterprise level administration. This way, should an employee leave a company (assuming they relenquish possession of the drive), the data is still recoverable.
Even without that, that type of encrypted drive is something I wish universities and colleges would give out to their professors who store their lesson plans and tests on removable flash media. This way, if someone rips off the drive from a faculty computing place, it won't reveal the answers to upcoming exams. Also, with the enterprise recovery, should someone lose a password, recovery is easy.
This is why some cryptosystems which still use 56 or 64 bit keys with AES use a method called key strengthening. If a 56 key is going to be used in a cryptosystem, it gets hashed a large number of times to delay CPU usage. This way, an attacker has to spend the CPU cycles on the 2^56 keyspace on each key before they can check to see if that is a valid guess or not.
TrueCrypt does this. It does a number of hashing iterations of the passphrase before it is attempted to be used as a key to open a volume.
This is why I like drives with proven security records like the IronKey, as well as smart cards. The controller doesn't just want a key for decryption, it will stop bad password guesses by either adding a longer and longer delay time before a password request ir processed, or just overtly erase stored keys after someone guesses wrong. Of course, I'm sure some well-heeled organization with an advanced chip fab can take a smart card apart to yank out a stored key, but an organization that rich likely will start with a rubber hose first (cue proper XKCD panel here.)
Instead of unlimited guesses, a proper security device limits the amount of brute force guesses to 3-20 or so before the curtain goes down.
If this was done knowingly, this is only going to bite the makers in the butt. There are already proven solid USB flash drives (IronKey) that have solid AES encryption and a very good authentication mechanism, and it will make those drives stand out for people who want solid security.
What will happen if hardware USB flash drives prove wanting is that more companies will resort to using software based encryption packages to ensure the contents are encrypted. BitLocker is part of the operating system (and in businesses, Windows 7 Enterprise is the only edition of Windows 7 which uses KMS-based activation so expect that to be the most common edition of Windows in businesses, and that edition has BitLocker.) PGP and other third party security companies also offer policies that can completely encrypt removable media before it is allowed to be written to.
So, unless hardware drive providers can provide us assurances of security, companies will take their cash to PointSec and PGP Incorporated and only buy the bare-bones models USB flash drives without the advanced security features, as the software provides both the security, as well as enterprise level assurance that if the media is removable, it will be encrypted.
What is funny is that in 1991, the NeXT had an implementation of ECC Fast Elliptic Encryption as part of the OS (think NeXTStep 2). However due to ITAR regs, it was removed from subsequent versions.
If symmetric key cryptography gets broken in general, what likely will happen is that the well heeled businesses would have a link between sites using quantum encryption. This link is extremely slow, so it would be used to set up session keys. Then the conventional Internet links would be used for the bulk data transfer.
People who don't have the cash for fiber optics would have to use lower tech means. One means would be have people generate a one time pad, and instead of PGP/gpg keysigning parties, people would trade chunks of random numbers with each other. Later on, people would go home and XOR the keyfile they got with the keyfile for a persistant key, and that would then be used with some other system (sha-512 hash of date/time + the keyfile) for a message based key. This way, a known plaintext attack wouldn't reveal the long term key (similar to a shared WPA2-PSK secret).
Where things would get hairy with no public key encryption are one to many transactions, such as communicating with a bank. This probably would end up getting solved by some type of smart card system where the bank's servers have a large amount of shared keys, while the customer would have a smart card that would handle the session key generation, but prevent the shared key from leaving the secure container.
What I find so ironic about MBA programs is that one of the required things they teach in the class lineup is management and employee morale. Employee morale isn't just liquid latex Fridays or coffee in the break room. It takes actual diplomacy and person to person interaction, so people don't just go to work for a paycheck, but actually feel valued.
Why is this important? A lot more work gets done at a company where salaried people are willing to work on something, just to make sure the company makes a sales goal, as opposed to people just wanting to "do their eight and out the gate." Don't forget that high morale makes the need for internal security less pressing because employees will be proactive in security issues.
The MBA degree isn't the issue as much as the people who get the degree tend to not heed what they are taught, and had to pass in order to receive that degree. So, a PHB who has an MBA who runs a company into the ground does know the consequences about bad company morale, and has no excuse about not knowing what would happen.
There are two problems with that statement: First, the app market is saturated, and not just the iPhone. Even Android's market is starting to bulge at the seams with fart apps and Tetris clones.
Second, a lot of IT people would form companies, but there are products which just can't be made in the backyard. They require some initial VC funding because it requires a machine shop, studio, crypt, or other place with specialized equipment, and money to invest in equipment.
For example, say I wanted to go into business selling some type of enterprise equipment. I'd need to have an office. I'd then need to have the machines and the raw material (studio and tapes, CNC machine and billets, etc.) Even before the first thing I wanted to sell rolled off the line, I'd have to have hundreds of thousands invested. And there isn't any way around this with a number of things. Maybe you could do a prototype on a shoestring, but you can't sell these to a customer unless you find someone ready, willing, and able to take a gamble with your product so it goes from a prototype and into customers' hands.
So, starting a business is a lot harder than you think. If your city has a SCORE, visit them with your ideas. It may hurt finding out that what you have isn't doable, but it is better to find it out there than after you sold your house and are hundreds of grand invested... and don't even have a single dollar in income yet.
What puts this in perspective is being asked by other people why I use a commercial E-mail service when Gmail/Hotmail/Yahoo/whatever is free. My response, of course, is "TANSTAAFL". What I pay for when I use a commercial provider is not just a TOS with solid privacy features (stored data being delivered on lawful court order as opposed to request), but the fact that the data stored is my data. It isn't going to be handed over to be sifted through for marketing or advertising, nor will it be used to sling ads at me.
I would add some more rules onto that after backups and encryption because cloud computing also covers networking, communications, and even virtual machines:
1: Don't create VM instances with sensitive data on machines you don't control. Yes, cloud functionality is awesome because you can create a VM you can ssh or RDP in that has a lot of CPU cycles. However, said VM is sitting on someone else's hardware, and has the possibility be shut down and imaged at any time, and the data given away. Even if one enables full disk encryption, the cloud computing provider has full access to the VM's RAM.
2: Use gpg or PGP, and consider a keysigning party or two [1]. gpg has the advantage of being able to be used as part of a MUA as an add-on, or used completely separate as a manual decryption mechanism. To a lesser extent S/MIME is good too, but it requires a dedicated MUA, and only Blackberries and Windows Mobile devices support it. Tell people to send confidential information encrypted. This way, should the mail spool get compromised, the blackhats won't be able to get any further than headers.
3: Offsite backup services like Mozy or others have the ability for the client to encrypt with a keyfile. For me, this is "good enough". For others with REALLY sensitive stuff, this is not acceptable at all, because one is letting someone else "pack your parachute" for you, with their encryption standard. Know your security needs. For me, this is an acceptable risk. If you are leery of this, put Mozy in a VM and share the directory with the TrueCrypt volume [2] that has the data you want backed up. This way, Mozy only sees the encrypted volume, no matter what it did inside the virtual machine.
4: If you use offsite storage, periodically log on to check your files still exist. I personally recommend gpg signing all files before you upload them just in case of corruption (or just sign/encrypt.) Don't forget to keep your gpg keys in a safe place [3].
5: Always remember if backing up to a cloud provider, cloud storage requires a good network connection. Backups are easy, but if you have a ton of data to recover, a restore may be a headache, or may require asking the cloud provider for media to be shipped via FedEx. Make sure to do backups to a local drive too. With utilities like Time Machine for the Mac, Acronis TrueImage or Retrospect for Windows, or bru for UNIX, this is an absolute no brainer to do.
[1]: I've made sure people's PGP/gpg keys were from whom they were by a number of means. If you can't do a keysigning party, sometimes you can ask the other person and set up a mutual passphrase where they can send you their public key, and you can send them your key. This way, the passphrase is only used for that exchange, and both parties can sign off on the keys as trusted.
[2]: On a Mac, you can get decent security through using the Disk Utility, and sparse bundles because the backup program would only have to copy the bands that were changed.
[3]: If you use the commercially licensed version of PGP, one idea is to generate multiple keys on a few smart cards, then have them all be ADKs and revocation agents for the cards. This way, if one card dies, you still have access to your protected stuff, as well can put out a revocation cert for the dead private key. To a lesser extent, you can copy the same keyfile to multiple cards in TrueCrypt, and store your private keys in a protected TrueCrypt volume that is only accessible by the keyfile on the smart cards.
The Web browser can be extremely secure. However, attackers are going after isn't the browser any more. They are gunning for the add-ons, both the big names and the small things. All it takes is a hole in even a relative obscure add-on, and an attacker now has code running in a security context of the add-on. As it stands now, the security context of an add-on is the same as the browser, which is usually the same as the user... and often times having root privs.
Even user nobody is somebody. You want a security context where if the buffer overflow bug in an image library gets used, the malicious software ends up with just the context of the library -- it can display something in a certain window, and no more. No access to intercept keystrokes. No filesystem access. No access to other threads, much less other processes.
For the best performance and security, the heavy lifting of a sandbox needs to be handled by the OS, while the Web browser specifies the hard and soft limits of what processes the add-ons it is about to spawn. A JPEG library needs only enough RAM and CPU to take a file, decompress it, and slap it on the space the browser specifies. A generic scripting language will need more than that, perhaps access to the keyboard if the window is in the foreground. In no case, should an add-on have a context equal to the user unless the Web browser is downloading a file at the user's behest, copying/pasting to other applications, and requesting a file to be uploaded at a user's behest.
The problem is that working from home does give you more hours to do better work, but because you are not in the office, you arn't visible. This can mean that the PHB who sees Joe Sixpack in his office, even though he plays WoW at work most of the time will put him ahead of the people who work at home when it comes time for the promotions.
Work at home people also end up madogiwazoku ("window seat worker") in a lot of businesses. This means at best they keep the position they have, but end up out of the chain of command because they are often essentially forgotten about.
If you do work at home, only do it for a couple days. Other than that, make sure people see you and make sure to have some type of presence in the office. This way, you are not invisible (and to a PHB, disposable).
Its neither. It's ROI and worrying about this quarter's earnings over anything else, pure and simple. Because there isn't any primary returns from finding date errors in the future, businesses just won't plunk down funds to fix them, and will reactively fix problems when they happen. I see this a lot in businesses, and not just the big boys. Plenty of SMBs also are not interested in hearing about anything they need to spend their money on, but stuff that has a positive return. They would rather forget about time issues. When zero hour happens, most feel that they can hire a ton of consultants to fix any problems that arise, even though it costs way more than if it was fixed before stuff failed.
Just the same with computer security because to a typical MBA++ PHB, security gives no financial gains. I've heard so many times, "I'm not worried. If I get hacked, I'll just call the Geek Squad guys and they will fix it."