Of course, said drug wouldn't just be used on criminals... I'm sure it will be used as another means to extract confessions, or help a country's propaganda campaigns when they suddenly get a bunch of people confessing to being spies and turning in their families and friends.
I remember that as well. Yes, it is easier to just double-click a program and have it flash a BIOS... but it is nice to have security not just relying on 1-2 crypto signatures which might be compromised.
If not a hardware jumper, perhaps a dedicated mode in firmware where the machine needs rebooted to. Then a UEFI application can be run for the actual BIOS upgrade where it would display the would-be firmware's cryptographic hash (preferably both SHA-3 and MD5), check and display signatures, then either have two sections for BIOS, or perform the flash as a transaction (either it completes 100%, or it backs out completely), then calls it done.
Of course, a lot of enterprises have a need for being able to flash machines without someone physically present at the console, so there will need to be a mechanism to handle this securely (in a way separated from the BIOS signatures.)
On some machines, they have out of band management features, even dedicated NICs for this purpose. Get full access to a BIOS, and the machine can easily have a functioning IP stack and be at the control of an attacker even if the machine has no OS present.
Another item would be a flashable BIOS like a security issue with some Apple keyboards. Nothing beats using the keyboard controller itself for a keylogger.
Agreed, HTML5 is not perfect, but it is better than addons, and those are oftentimes the items that malware uses to gain control of the Web browser (and thus a foothold of at least a user context, if not full run of a machine.)
Of course, the irony is that you can use Flash Professional to make HTML5 content.
One reason that Apple may not allow downgrades is the fact that some people who downgrade might later on get stung by security issues... then blame, perhaps sue Apple for deliberately putting a downgrade mechanism that puts them back in harm's way in a backlevel iOS version.
There are eSATA flash drives, and a number of laptops (Dell comes to mind) have ports that are both USB and eSATA (eSATAp.) That might be a wise idea as well.
When a local startup went out of business, one of the things the failed startup had at their bankruptcy auction was an electric motor that would spin a crankshaft/flywheel... only for a generator head on the other end to turn the motion back into electricity. I wondered why they had something that inefficient until I found that it was a "power firewall"... i.e. to mitigate attacks via the mains power.
For offsite control, I've wondered about using a humble POTS line and a 28.8 modem that dials back. After the initial handshake and some form of two factor authentication, the hard part after that would be an encryption protocol (PPP then SSH for example) and then run from there. The downside is that bandwidth will be extremely limited, especially with the encryption overhead, but it will be fairly difficult for an attacker to exploit due to being on a different medium (i.e. not just an IP connection away.)
The problem with what I've seen for data diodes is that they tend to be black boxes. With a serial cable that only has one transmitting wire, it is physically obvious that there is no hanky panky going on. However, when people have information that starts getting past a couple thousand BPS, a data diode is a must because serial just can't keep up, so black box or no, it is a necessary evil at some point.
As a compromise, one can always do something similar to this:
1: Get two machines with a RS232 port. One will be the source, one the destination.
2: Cut the wire on the serial port cable so the destination machine has no ability to communicate with the source.
3: Have the source machine push data through the port, destination machine constantly monitor it and log it to a file.
4: Have a program on the destination machine parse the log and do the paging, etc. if a parameter goes out of bounds.
This won't work for high data rates, but it will sufficiently isolate the inner subsystem from the Internet while providing a way for data to get out in real time. Definitely not immune to physical attack, but it will go a long ways to stopping remote attacks, since there is no connections that can be made into the source machine's subnet.
BitCoin exchanges are where banks were, pre-Great Depression. They go under, you lose your savings, period. It was only under FDR that bank losses were covered by the US government under FSLIC/FDIC/NCUA insurance.
The BitCoin protocol has not had any attacks. It has been exchanges that were poorly run or attacks on the computers/endpoints storing BitCoin wallets. The BitCoin core protocol has proven to be secure, although there is always concern about one single party reaching the magic 51% mark.
If Paris only does this once or twice, it can work. However, if this is done often, then people will buy vehicles just to have both types of plates.
Another way that this can be handled is to have the digit on the license plate be different each time for a ban. So, some cars might differ with the last digit, but the second digit may be the same, which would accomplish the objective.
Not saying the objective is helpful, but Paris is different from Mexico City because they tend to have more modes of transportation (streetcar, train, tram, Puppeteer teleport pads) than in America [1], so someone might be inconvenienced, but it won't be a show-stopper.
[1]: America as in the continent, not the United States.
There is this constant push for H-1Bs, why not offer the Russian scientists asylum here? History has shown this to work in the past when Germany was a very hostile place to live in the 1800s, so the artisans, engineers, and tradespeople moved to the US.
Nail, head, hit. We have enough issues with software that is just poorly programmed, much less stuff that has to back doors put in by law.
I'm reminded of the Clipper chip. Yes, the LEAF key escrow system would make it easy for LEOs to get access. However, what would happen if the bad guys got ahold of the backdoor [1]? It would be a catastrophe of compromised that would make last year's leaks of information look tiny in comparison.
[1]: Trust me, if all the eggs are in one basket, the keys are obtainable, even if it means physically kidnapping IT people or their family and demanding access. Sometimes good security is being distributed, forcing an attacker to go after many targets which spreads their efforts out and multiples their chances of detection.
Cloud storage is another type of media with distinct advantages/disadvantages. Yes, that 1TB HDD is about $75, but items stored on a cloud service can be accessed anywhere, and there is less chance of a single drive failure taking your stuff with it. Of course, cloud drives are vulnerable to malware doing a delete (which likely can't be restored), so long term archival media is always needed, preferably offline items, or perhaps something like Amazon Glacier.
Part of this can be attributed to stagnation. So many companies assume they can make money on ad revenue and selling user data that they focus on that exclusively.
The problem is that how long until there is a saturation. Once companies start logging every single click and character typed that a subscriber (i.e. their product) sends their site and selling that info, there is nothing else they can do other than demanding subscribers run adware on their local machines for access. Once this point is reached, there will be a bust for the Web 2.0 (FB, Twitter, services that do not charge their users for revenue.)
What might happen is that governments step in and desire social networks for their citizens, so companies will focus on trying to sell to countries as the main customer instead of advertisers.
I'm hoping the pendulum will swing in the direction back to paid services so the subscriber is the customer and not the product. However, it is harder to get a ton of people to pay a subscription a month than it is to just hand their data over to various third parties for a guaranteed purchase order every financial period.
I've wondered about having part of a cryptocurrency be a way to have a mechanism for insurance. That way, if/when coins are stolen, there is a way to obtain new ones. Of course, this would have to be carefully made/watched due to fraud ("gee, I had those coins all along in a backup wallet...")
The biggest issue with cryptocurrencies is the fact that they cannot rely on a single trusted third party or parties. This is the new ground. Conventional systems like PayPal, Amazon Wallet, etc. have a "trusted" party, either the core company doing the exchanges, a bank, the bank's insurance underwriter, or a government. With cryptocurrencies, being forced to trust a third party cannot be used as an easy way out.
Take a fifth of that and put it into battery research to create a storage cell that is within 1/10 of the energy density by volume of gasoline, and that would completely change the transportation industry. Electric motors don't have a good chunk of their energy get blown out the tailpipe.
On a large scale, this would make solar better able to handle not just peak load, but core electrical power generation.
Even with bandwidth, there are caps and fees here in the US. Try moving 1TB of data via LTE, and the telco will likely hand the person a five digit bill next month. Do it on some cable company plans, and you will be greeted by a $300 bill. So, large data via the Internet isn't going to happen.
There are a number of solutions for this problem:
1: One of the better ones is a server with decent backup software and a LTO tape drive. Then eight tapes will save the 20 TB. Expensive, but the job is done right.
2: One can always have a 20TB RAID, then plug in removable HDDs and use them with WinRAR or another utility as volumes. I'd buy 5-6 4TB removable drives, use WinRAR to make segments, and have at least one recovery volume so that data can be recovered if a HDD fails.
3: One can always buy a an external RAID enclosure, add drives, and use that as a large volume. Then use multiple enclosures that were swapped around as volumes (with an offsite rotation), so a failure or loss of everything at the site wouldn't mean everything is gone.
4: Buy a RDX drive and media, and use 2TB disks. The drive costs $600, the 2TB disk cartridges around $360. However, this just needs a USB connection, no fast box, no SAS interface required.
If I wanted to do the job "right", I'd buy a dedicated server with its own RAID array, use a decent backup utility, and dump the data to multiple sets of tapes, one set being stored offsite. If the server and where it sits gets destroyed, it can be re-bought. LTO-4 and newer have built in AES-256 tape encryption so just set a long passphrase that you can remember and call it done.
You need to specialize in something so that you have a skill not the average person coming from the degree mills possesses.
BUT you also have to not specialize so much that if/when that skill becomes not needed, one is hosed, be it COBOL, C++ programming, Java clientside applets, etc.
For example, certifications. It is good to have some in several different items because I've found that in previous jobs I've had, auditors will go through the server room, demand certification IDs from staff, and if they are expired (or don't exist), said worker is fired on the spot for "failing to have the authority to operate the device."
This is a tough balance. Error on the jack of all trades, your resume gets tossed. Too far the other way, you end up too specialized and if your specialty goes out the door, you are hosed until you can retool (on your own dime).
Android uses dm-crypt, which has been in the Linux kernel for a while now. The downside is that newer releases only encrypt/data.
Motorola devices used to have their own mechanism for loopback encryption, and they used a version of CFS/EncFS for SD cards, which means the SD card can be pulled and file sizes looked at, but the contents and the file names hidden.
The downside of the iPhone's encryption is that the chip that guards the key is easily openable by Apple. LUKS/dm-crypt is all software based without any obvious backdoors (there can always be ones that are hidden.)
There is one Blackberry/RIM feature I wish was in Android. If the device doesn't get a "ping" from the master server in a certain amount of time, the device wipes itself.
Yes, this can be dangerous, but if someone yanks the SIM, or even worse, tosses the device into Airplane mode, eventually the phone will erase itself.
Malicious apps that gain root are rare. If an app is trying to get root, it is usually an exploit tool for a user to get a "#" prompt on their device, as opposed to malicious software. It usually takes some work with ADB and some user intervention to get it working for most of those. To boot, in Android 4.4, SELinux is turned on, so an app that does manage to carve itself a process at UID 0 will not be able to do much. Of course, the main door to root, the su app is well guarded. Modern su utilities require an app to have a permission on download (ACCESS_SUPERUSER.) (su.chainfire.eu has more details on this.) Even with this, the user is prompted before the app gets access.
I do agree that Blackberry's security model is better with the prompting for permissions. However, Android is a lot more usable for a UNIX platform, even though busybox does not come near a full fledged userland. Android also is decently secure. I trust its disk encryption more than iOS's black box chip that holds keys, with Apple definitely having a master key.
Even better, perhaps a standard of crypto token that works with USB? Right now, there is one for cards, but for USB tokens, I need special drivers for every maker (be it Safenet, Gemalto, or whomever.)
That way, the private ssh key can be used on the device, but never leaves it unless one is doing a backup of it to another device, or to other media where it is stored (encrypted with a passphrase) for safekeeping.
For two factor authentication, things like the Google Authenticator is good enough. The only improvement I can see with that would be going to a public/private key system or having a hardened authentication server that used Kerberos. We really do not need more hardware dongles that are not really a standard. Having standardized hardware key protection for SSH private keys would be nice, but oftentimes, the perfect is the enemy of the good... if we can go with SSH keys/certificates and/or a standardized OTP, that is 95% of the battle right there... an attacker would then have to start attacking individual endpoints.
1: Unlock the bootloader, flash a CM or custom ROM that doesn't sport crapware.
2: Encrypt the device with a screen locker PIN 4+ digits. I personally use six for this, just for ease of typing.
3: Use "su -c vdc cryptfs changepw foobar" to change the passphrase. This separates the passphrase Android asks for at boot versus the screen unlocker PIN. Of course, if you change the screen password, the cryptfs password will change, so you will need to use root and change it again, or use an app for this.
The advantage of this method is that the boot password can be very secure, while the password to get past the screen locker can be easy to type in.
4: Relock the bootloader. This forces someone to have to erase the data partition if they want to reflash.
5: Install a third party security app like Cerberus or Lookout that can locate and remotely erase the device, or just sound a siren until the holder trashes it. Some utilities can go into/system and persist against wipes as well.
6: If the device has a SD card, consider using an EncFS app to mount and store files under. This way, anything written is immediately encrypted.
7: Use Titanium Backup Pro with encryption and saving to a remote cloud provider. TB's encryption is remarkably sane (it uses private/public key, so the passphrase is only needed on a restore), and storing copies of backups remotely means that data is still obtainable even if the phone is lost. It does require root though.
8: Unless directly in use, keep USB and ADB completely off until needed.
9: Use a utility that demands a PIN before various apps can launch, especially preferences and an app that pops up a console/shell window.
10: Use a TRIM utility that runs in the background. This way, if the data isn't encrypted, it is not existing.
These will help protect data on a phone. If stolen, the attacker would have a few guesses on the PIN before the device locks them out. A reboot will force the attacker against the full passphrase. A data wipe will still mean Cerebus or a security program is still in/system, forcing the thief to completely reflash the phone to a factory image (ensuring all is gone.)
Of course, there is the physical hardware loss, which insurance might cover (Asurion for example), and stored data can be recovered via Titanium Backup. However, done right, an Android phone can be made decently resistant to theft or physical attacks.
The reason why one should use a utility to PIN protect apps and app groups is that if the phone is swiped before the screen locker comes on (for example, out of the user's hands directly). That way, assuming preferences and other settings are secure, a thief has limited run on what is available on the phone.
Slashdot Mirror
Of course, said drug wouldn't just be used on criminals... I'm sure it will be used as another means to extract confessions, or help a country's propaganda campaigns when they suddenly get a bunch of people confessing to being spies and turning in their families and friends.
I remember that as well. Yes, it is easier to just double-click a program and have it flash a BIOS... but it is nice to have security not just relying on 1-2 crypto signatures which might be compromised.
If not a hardware jumper, perhaps a dedicated mode in firmware where the machine needs rebooted to. Then a UEFI application can be run for the actual BIOS upgrade where it would display the would-be firmware's cryptographic hash (preferably both SHA-3 and MD5), check and display signatures, then either have two sections for BIOS, or perform the flash as a transaction (either it completes 100%, or it backs out completely), then calls it done.
Of course, a lot of enterprises have a need for being able to flash machines without someone physically present at the console, so there will need to be a mechanism to handle this securely (in a way separated from the BIOS signatures.)
On some machines, they have out of band management features, even dedicated NICs for this purpose. Get full access to a BIOS, and the machine can easily have a functioning IP stack and be at the control of an attacker even if the machine has no OS present.
Another item would be a flashable BIOS like a security issue with some Apple keyboards. Nothing beats using the keyboard controller itself for a keylogger.
Agreed, HTML5 is not perfect, but it is better than addons, and those are oftentimes the items that malware uses to gain control of the Web browser (and thus a foothold of at least a user context, if not full run of a machine.)
Of course, the irony is that you can use Flash Professional to make HTML5 content.
Devil's advocate here:
One reason that Apple may not allow downgrades is the fact that some people who downgrade might later on get stung by security issues... then blame, perhaps sue Apple for deliberately putting a downgrade mechanism that puts them back in harm's way in a backlevel iOS version.
There are eSATA flash drives, and a number of laptops (Dell comes to mind) have ports that are both USB and eSATA (eSATAp.) That might be a wise idea as well.
When a local startup went out of business, one of the things the failed startup had at their bankruptcy auction was an electric motor that would spin a crankshaft/flywheel... only for a generator head on the other end to turn the motion back into electricity. I wondered why they had something that inefficient until I found that it was a "power firewall"... i.e. to mitigate attacks via the mains power.
I remember in the early 2000s, people playing a MMO via modem on a dedicated POTS line used as a heartbeat monitor between two IBM HA systems.
Airgaps are one tool in the security toolbox, but nothing is 100%. Iran's centrifuges are a testament to that.
For offsite control, I've wondered about using a humble POTS line and a 28.8 modem that dials back. After the initial handshake and some form of two factor authentication, the hard part after that would be an encryption protocol (PPP then SSH for example) and then run from there. The downside is that bandwidth will be extremely limited, especially with the encryption overhead, but it will be fairly difficult for an attacker to exploit due to being on a different medium (i.e. not just an IP connection away.)
The problem with what I've seen for data diodes is that they tend to be black boxes. With a serial cable that only has one transmitting wire, it is physically obvious that there is no hanky panky going on. However, when people have information that starts getting past a couple thousand BPS, a data diode is a must because serial just can't keep up, so black box or no, it is a necessary evil at some point.
As a compromise, one can always do something similar to this:
1: Get two machines with a RS232 port. One will be the source, one the destination.
2: Cut the wire on the serial port cable so the destination machine has no ability to communicate with the source.
3: Have the source machine push data through the port, destination machine constantly monitor it and log it to a file.
4: Have a program on the destination machine parse the log and do the paging, etc. if a parameter goes out of bounds.
This won't work for high data rates, but it will sufficiently isolate the inner subsystem from the Internet while providing a way for data to get out in real time. Definitely not immune to physical attack, but it will go a long ways to stopping remote attacks, since there is no connections that can be made into the source machine's subnet.
BitCoin exchanges are where banks were, pre-Great Depression. They go under, you lose your savings, period. It was only under FDR that bank losses were covered by the US government under FSLIC/FDIC/NCUA insurance.
The BitCoin protocol has not had any attacks. It has been exchanges that were poorly run or attacks on the computers/endpoints storing BitCoin wallets. The BitCoin core protocol has proven to be secure, although there is always concern about one single party reaching the magic 51% mark.
If Paris only does this once or twice, it can work. However, if this is done often, then people will buy vehicles just to have both types of plates.
Another way that this can be handled is to have the digit on the license plate be different each time for a ban. So, some cars might differ with the last digit, but the second digit may be the same, which would accomplish the objective.
Not saying the objective is helpful, but Paris is different from Mexico City because they tend to have more modes of transportation (streetcar, train, tram, Puppeteer teleport pads) than in America [1], so someone might be inconvenienced, but it won't be a show-stopper.
[1]: America as in the continent, not the United States.
There is this constant push for H-1Bs, why not offer the Russian scientists asylum here? History has shown this to work in the past when Germany was a very hostile place to live in the 1800s, so the artisans, engineers, and tradespeople moved to the US.
Nail, head, hit. We have enough issues with software that is just poorly programmed, much less stuff that has to back doors put in by law.
I'm reminded of the Clipper chip. Yes, the LEAF key escrow system would make it easy for LEOs to get access. However, what would happen if the bad guys got ahold of the backdoor [1]? It would be a catastrophe of compromised that would make last year's leaks of information look tiny in comparison.
[1]: Trust me, if all the eggs are in one basket, the keys are obtainable, even if it means physically kidnapping IT people or their family and demanding access. Sometimes good security is being distributed, forcing an attacker to go after many targets which spreads their efforts out and multiples their chances of detection.
Cloud storage is another type of media with distinct advantages/disadvantages. Yes, that 1TB HDD is about $75, but items stored on a cloud service can be accessed anywhere, and there is less chance of a single drive failure taking your stuff with it. Of course, cloud drives are vulnerable to malware doing a delete (which likely can't be restored), so long term archival media is always needed, preferably offline items, or perhaps something like Amazon Glacier.
Part of this can be attributed to stagnation. So many companies assume they can make money on ad revenue and selling user data that they focus on that exclusively.
The problem is that how long until there is a saturation. Once companies start logging every single click and character typed that a subscriber (i.e. their product) sends their site and selling that info, there is nothing else they can do other than demanding subscribers run adware on their local machines for access. Once this point is reached, there will be a bust for the Web 2.0 (FB, Twitter, services that do not charge their users for revenue.)
What might happen is that governments step in and desire social networks for their citizens, so companies will focus on trying to sell to countries as the main customer instead of advertisers.
I'm hoping the pendulum will swing in the direction back to paid services so the subscriber is the customer and not the product. However, it is harder to get a ton of people to pay a subscription a month than it is to just hand their data over to various third parties for a guaranteed purchase order every financial period.
I've wondered about having part of a cryptocurrency be a way to have a mechanism for insurance. That way, if/when coins are stolen, there is a way to obtain new ones. Of course, this would have to be carefully made/watched due to fraud ("gee, I had those coins all along in a backup wallet...")
The biggest issue with cryptocurrencies is the fact that they cannot rely on a single trusted third party or parties. This is the new ground. Conventional systems like PayPal, Amazon Wallet, etc. have a "trusted" party, either the core company doing the exchanges, a bank, the bank's insurance underwriter, or a government. With cryptocurrencies, being forced to trust a third party cannot be used as an easy way out.
Take a fifth of that and put it into battery research to create a storage cell that is within 1/10 of the energy density by volume of gasoline, and that would completely change the transportation industry. Electric motors don't have a good chunk of their energy get blown out the tailpipe.
On a large scale, this would make solar better able to handle not just peak load, but core electrical power generation.
Even with bandwidth, there are caps and fees here in the US. Try moving 1TB of data via LTE, and the telco will likely hand the person a five digit bill next month. Do it on some cable company plans, and you will be greeted by a $300 bill. So, large data via the Internet isn't going to happen.
There are a number of solutions for this problem:
1: One of the better ones is a server with decent backup software and a LTO tape drive. Then eight tapes will save the 20 TB. Expensive, but the job is done right.
2: One can always have a 20TB RAID, then plug in removable HDDs and use them with WinRAR or another utility as volumes. I'd buy 5-6 4TB removable drives, use WinRAR to make segments, and have at least one recovery volume so that data can be recovered if a HDD fails.
3: One can always buy a an external RAID enclosure, add drives, and use that as a large volume. Then use multiple enclosures that were swapped around as volumes (with an offsite rotation), so a failure or loss of everything at the site wouldn't mean everything is gone.
4: Buy a RDX drive and media, and use 2TB disks. The drive costs $600, the 2TB disk cartridges around $360. However, this just needs a USB connection, no fast box, no SAS interface required.
If I wanted to do the job "right", I'd buy a dedicated server with its own RAID array, use a decent backup utility, and dump the data to multiple sets of tapes, one set being stored offsite. If the server and where it sits gets destroyed, it can be re-bought. LTO-4 and newer have built in AES-256 tape encryption so just set a long passphrase that you can remember and call it done.
CS/IT is about an oxymoron:
You need to specialize in something so that you have a skill not the average person coming from the degree mills possesses.
BUT you also have to not specialize so much that if/when that skill becomes not needed, one is hosed, be it COBOL, C++ programming, Java clientside applets, etc.
For example, certifications. It is good to have some in several different items because I've found that in previous jobs I've had, auditors will go through the server room, demand certification IDs from staff, and if they are expired (or don't exist), said worker is fired on the spot for "failing to have the authority to operate the device."
This is a tough balance. Error on the jack of all trades, your resume gets tossed. Too far the other way, you end up too specialized and if your specialty goes out the door, you are hosed until you can retool (on your own dime).
Android uses dm-crypt, which has been in the Linux kernel for a while now. The downside is that newer releases only encrypt /data.
Motorola devices used to have their own mechanism for loopback encryption, and they used a version of CFS/EncFS for SD cards, which means the SD card can be pulled and file sizes looked at, but the contents and the file names hidden.
The downside of the iPhone's encryption is that the chip that guards the key is easily openable by Apple. LUKS/dm-crypt is all software based without any obvious backdoors (there can always be ones that are hidden.)
There is one Blackberry/RIM feature I wish was in Android. If the device doesn't get a "ping" from the master server in a certain amount of time, the device wipes itself.
Yes, this can be dangerous, but if someone yanks the SIM, or even worse, tosses the device into Airplane mode, eventually the phone will erase itself.
Malicious apps that gain root are rare. If an app is trying to get root, it is usually an exploit tool for a user to get a "#" prompt on their device, as opposed to malicious software. It usually takes some work with ADB and some user intervention to get it working for most of those. To boot, in Android 4.4, SELinux is turned on, so an app that does manage to carve itself a process at UID 0 will not be able to do much. Of course, the main door to root, the su app is well guarded. Modern su utilities require an app to have a permission on download (ACCESS_SUPERUSER.) (su.chainfire.eu has more details on this.) Even with this, the user is prompted before the app gets access.
I do agree that Blackberry's security model is better with the prompting for permissions. However, Android is a lot more usable for a UNIX platform, even though busybox does not come near a full fledged userland. Android also is decently secure. I trust its disk encryption more than iOS's black box chip that holds keys, with Apple definitely having a master key.
Even better, perhaps a standard of crypto token that works with USB? Right now, there is one for cards, but for USB tokens, I need special drivers for every maker (be it Safenet, Gemalto, or whomever.)
That way, the private ssh key can be used on the device, but never leaves it unless one is doing a backup of it to another device, or to other media where it is stored (encrypted with a passphrase) for safekeeping.
For two factor authentication, things like the Google Authenticator is good enough. The only improvement I can see with that would be going to a public/private key system or having a hardened authentication server that used Kerberos. We really do not need more hardware dongles that are not really a standard. Having standardized hardware key protection for SSH private keys would be nice, but oftentimes, the perfect is the enemy of the good... if we can go with SSH keys/certificates and/or a standardized OTP, that is 95% of the battle right there... an attacker would then have to start attacking individual endpoints.
Here is what I do to secure my Android device:
1: Unlock the bootloader, flash a CM or custom ROM that doesn't sport crapware.
2: Encrypt the device with a screen locker PIN 4+ digits. I personally use six for this, just for ease of typing.
3: Use "su -c vdc cryptfs changepw foobar" to change the passphrase. This separates the passphrase Android asks for at boot versus the screen unlocker PIN. Of course, if you change the screen password, the cryptfs password will change, so you will need to use root and change it again, or use an app for this.
The advantage of this method is that the boot password can be very secure, while the password to get past the screen locker can be easy to type in.
4: Relock the bootloader. This forces someone to have to erase the data partition if they want to reflash.
5: Install a third party security app like Cerberus or Lookout that can locate and remotely erase the device, or just sound a siren until the holder trashes it. Some utilities can go into /system and persist against wipes as well.
6: If the device has a SD card, consider using an EncFS app to mount and store files under. This way, anything written is immediately encrypted.
7: Use Titanium Backup Pro with encryption and saving to a remote cloud provider. TB's encryption is remarkably sane (it uses private/public key, so the passphrase is only needed on a restore), and storing copies of backups remotely means that data is still obtainable even if the phone is lost. It does require root though.
8: Unless directly in use, keep USB and ADB completely off until needed.
9: Use a utility that demands a PIN before various apps can launch, especially preferences and an app that pops up a console/shell window.
10: Use a TRIM utility that runs in the background. This way, if the data isn't encrypted, it is not existing.
These will help protect data on a phone. If stolen, the attacker would have a few guesses on the PIN before the device locks them out. A reboot will force the attacker against the full passphrase. A data wipe will still mean Cerebus or a security program is still in /system, forcing the thief to completely reflash the phone to a factory image (ensuring all is gone.)
Of course, there is the physical hardware loss, which insurance might cover (Asurion for example), and stored data can be recovered via Titanium Backup. However, done right, an Android phone can be made decently resistant to theft or physical attacks.
The reason why one should use a utility to PIN protect apps and app groups is that if the phone is swiped before the screen locker comes on (for example, out of the user's hands directly). That way, assuming preferences and other settings are secure, a thief has limited run on what is available on the phone.