The problem is that there is an conflict between a password suitable enough for protection (i.e. 20+ characters), and something quick enough to access in a short time.

mSecure addresses this in an interesting way -- they cache the extra long sync password used for the cloud. The password that is used to encrypt the synchronized database that sits in iCloud or DropBox is different from the app's passphrase. Since most phones have decent innate protection, it is not impossible, but very difficult to dump the data on a locked device [1], so one can have a fairly easy to type in PIN on the device, but the synchronized backend file is protected with a much longer (and more secure) passphrase.

[1]: iOS on the iPhone 4 and up always encrypts. Android since 3.x has the option of using md-crypt and encrypting the /data partition, then using another tool to separate the password asked on boot to decrypt that partition from the screen locker password.

Done right, storing passwords on the web can be decently secure, especially if there is some part of the decryption key (be it a public key, a secondary authenticator, or a keyfile) that is not available to the attacker, in combination with the master passphrase.

I'd say the best implementation of this would be a utility that piggybacked on the cloud provider of choice, so one isn't limited to GDrive, Dropbox, Box, Skydrive, iCloud, or others. The utility would ask for permission just for its own directory (if possible), and would store its main DB file, as well as some backups in that directory. That way, the password program author or company doesn't have to maintain a cloud infrastructure.

Hate responding to my own posts, but adding another idea... Each endpoint device has its own private key... so the data that is stored on the backend cloud provider would be conventionally encrypted, but would be unlockable by any key in the access list, similar to a PGP attachment that lists multiple public keys. That way, one can add and remove devices by using their key, and no common file needs to be shared.

I'd probably say KeePass is as secure as things get, since it doesn't use the Web in any way, shape, or form.

What I'd like to see with password apps that use a cloud provider for backend storage, (be it 1Password, mSecure, or so on), would be a keyfile that is manually transferred between devices, and never is put on the cloud backend. This way, if/when the cloud provider is hacked, the password file is not just protected by the passphrase, but by a keyfile that an attacker would have to compromise a physical device to get.

There is also the fact that some failure modes will take both sides down. I've seen disk controllers overwrite shared LUNs, hosing both sides of the HA cluster (which is why I try to at least quiesce the DB or application so RTO/RPO in case of that failure mode is acceptable.)

HA can also be located on different points on the stack. For example, an Oracle DB server. It can be clustered on the Oracle application level (active/active or active/passive), or it can be sitting in a VMWare instance, clustered using vSphere HA, where the DB itself thinks it is a single instance, but in reality, it is sitting active/passive on two boxes.

Even if the backup stays up, failing back can be an issue. I've seen HA systems where it will happily drop to the backup node... but failing back to the primary can require a lot of downtime. For active/active setups, it can require a performance hit for resyncing.

Even on fairly simple things (yum updates from mirrors, AIX PTFs, Solaris patches, or Windows patches released from WSUS), I like babysitting the job.

There is a lot that can happen. A backup can fail, then the update can fail. Something relatively simple can go ka-boom. A kernel update doesn't "take" and the box falls back to the wrong kernel.

Even something stupid as having a bootable CD in the drive and the server deciding it wants to run the OS from that rather than from the FCA or onboard drives. Being physically there so one can rectify that mistake is a lot easier when planned as opposed to having to get up and drive to work at a moment's notice... and by that time, someone else likely has discovered it and is sending scathing E-mails to you, CC:5 tiers of management.

For gaming, things have been "good enough" going on almost a decade.

For true studio work, I've not checked recently, but I think M Audio has a PCI interface card for a few C-Notes. I think things have shifted to AI (audio interface) cards anyway, as opposed to discrete sound cards like SoundBlaster successors.

However, I wouldn't say SBs are pointless... for retro gaming, some games have better sounding music coming from the "primitive" FM synthesis at that time.

I also went to CFLs because of the energy savings. However, I'd get a few years life out of them.

However, I switched to LED bulbs virtually everywhere. Their energy savings is not that much better than CFLs... but there is far less of a mess when a LED bulb hits the floor than an unprotected CFL. So far, I've not had any of my LED bulbs burn out, even with daily use, some on dimmer switches.

I know there is a cost premium, but between the longer life (barring an overvoltage, which will fry LEDs quickly) and the fact that physical damage won't result in a mini Superfund site, they seem to be worth the cost.

Worst case, replace the keyboard with something like the Optimus Maximus keyboard with the keys changing characters every time a password is asked.

What really is needed are what we had before everything got linked to the Internet. We need separate networks. Examples of this would be SIPRnet, NIPRNet, and GRU's equivalents.

Yes, this network can be hacked, but it adds an additional barrier -- one has to hack the network (which likely will be designed with this in mind from the ground up), forge access as a trusted machine (tough, due to machines having their own public keys), then try to attack the targets themselves.

I wonder why this isn't done. I would think a "BIPRNet" would be obvious since it gets sensitive traffic and things like wide-open SCADA systems completely off the Internet, but still allows remote access and management.

Another problem with electronic voting is the complexity. Paper ballots are simple. A mark or a hole punched through some wood pulp.

With electronic voting, there are so many vulnerabilities. From voting machines that will change one's vote to Kodos before it even gets registered on the machine, to votes being switched in transit, there are no real ways to actually protect that info from a determined, well-heeled intruder. Paper trails are still forgable, but we have had thousands of years dealing with paper, and it requires a definite physical presence to alter results.

This isn't to say it cannot be done, but it would require a cryptographic infrastructure from a dedicated smart card that the voter has, to cryptography at every link (so votes added/subtracted from a county would be detected)... and all this assuming the hardware maker didn't add their backdoors.

Maybe NYC is right... time to go back to mechanical voting machines or at least pen and pencil.

Supercap technology is one of those that addresses it. Yes, it takes a lot of amperes, but instead of feeding a battery a constant voltage/amperage and nursing it along with its chemical reactions, while watching its SoC and temperature level, a supercap can be charged quite quickly, since the charge is a physical process (electrons stashed at one end of the dielectric.)

Of course, the problem is that batteries have such a relatively low energy density per volume. Get battery energy within an order of magnitude of diesel or gasoline, and this revolutionizes things. Ineffecient diesel and gasoline engines that have a sizable chunk of their energy spat out the tailpipe now get replaced by vastly more efficient electric motors. Noxious fuels get replaced by whatever electrical source is usable in a region, be it geothermal, wind, solar, or others. Petroleum can be used for its most important use -- making plastics, rather than just turned into carbon dioxide.

I have a machine of a similar vintage running an age-old copy of RHEL. I keep it, but the chances of me firing it up are slim to none, because I can fire up VMWare Workstation with an older OS release. Plus, even if the hardware is rock stable, it uses more energy than a modern computer and OS. Running a VM from a SATA SSD consumes a lot less power than an older 3.5" IDE HDD which might have at most 128 or so gigs.

It is fun to fire up old hardware, but other than having the right stuff to play a game (DOSBox is good, but some older MS-DOS games won't work correctly unless they are on bare metal, and don't sound "right" unless they are played on an antediluvian FM-synthesis sound card), there isn't much of a point to it.

Of course, said code module can change, so even if your deps are right now... it might be that the black box code library that does some essential functions might not work the same after it gets updated. In some ways, this is easy to find (if you do a library upgrade and things break, with no other changes.) However, if there are other confounding variables, this might be a fairly difficult task.

When in CS, I had a prof that had one rule that for release (not beta/alpha/dev) code, if the code had even a single warning, it was unshippable unless there was an extremely good reason (which would be part of the README) of why it happened. Yes, this was a PITA, but he was trying to teach something that seems to have been lost.

It verges on astounding. I've read for years that Germany has ceded sovereign control of its land to Russia for natural gas, and that German citizens would freeze by the tens of thousands if Putin turned off the taps. However, Germany is still going strong and doesn't have brownouts or rolling blackouts as naysayers have been saying would be a certainty.

This doesn't mean nuclear power is bad. The ideal would be to work on the latest generation plants, maybe even thorium plants. However, due to NIMBY syndrome and fearmongering, any advances in nuclear power are swept under the rug, while anything that might happen bad with 50-60 year old plants that (by moratoriums in place) cannot be upgraded/replaced will be blasted on the front pages of any periodical or website.

I do agree about storage. I'm hoping Germany is a frontline player when it comes to higher energy density per volume and weight when it comes to batteries. If a battery is made that even comes within an order of magnitude of gasoline or diesel's energy by volume, this would fundamentally change transportation as we know it.