Much less someone who claims to be against eminent domain.

I'm pretty sure we already know the answer. The cat is dead. Curiosity killed it.

What does the American electricity-guzzling appliance do?

Spins up. It's not the running wattage that's the problem. It's the locked rotor current that will get you.

That's true. However, given that an earlier part of the post indicated that he/she spent 85% of his/her waking time in the office, it is clear that flexible time is not what was meant. That's approximately a 95-hour workweek. Even if you interpret it as 85% of your waking life during the five days that most people work, that's still a 68-hour workweek. Neither one is healthy, even for short periods of time, much less on an ongoing basis. A 40-hour workweek is about 36 percent of your waking life, and for jobs that involve serious thinking, studies have shown that even that is well above the point of diminishing returns.

When I'm here at 8 o'clock at night -- I would much prefer free soda (or a pizza) to an extra $100 in my bank account.

I wouldn't. I'd rather not be there at 8 o'clock at night. This is a sure sign of poor management.

A small 2.5 cubic foot office fridge draws 200-400 Watts. So if you have one of those, you could run it on many of the beefier inverters that you can buy off the shelf at Wal-Mart. A full-size fridge? You'll need something bigger—the better part of a kilowatt is a starting point for newer refrigerators. They go up from there. So yes, a generator is a good idea. A gun? Not really. If things degrade that far, I'd rather have a means to get the heck out of there and come back after the National Guard has come in and cleaned things up.

Now lets be clear that I'm not talking about a FPGA! In a FPGA if you "reload" the software you will change the machine because in essence the "software" for a FPGA is like the internal gear system, you can configure it in 1000 different ways to do different tasks. One day it can be a conveyor build and the next it will be a bottle cap remover. So before someone comes in here and blows a gasket at me, I fully accept the fact that a FPGA is very different then a Computer.

Ah, but an FPGA can be simulated in software. Therefore, if you reload the software in the simulator, you change the virtual machine. How is the fact that one is emulated and the other is physical relevant?

The way I look at it, software certainly adds a new state machine into the picture. Whether that qualifies as a machine for patent purposes is a separate question, and there are legitimate arguments on both sides, but whichever way you decide, an FPGA should play by the same rules as software.

Thanks for the explanation. My memory of the actual math involved was a little bit off.

Either way, though, the point remains that if the token is in software and the host is compromised, an attacker can obtain the current value of the key and can generate a new number transparently at any time, and it won't be detectable so long as the attacker updates the button press count on compromised device so that the server doesn't see the same button press count twice with different time stamps.

And cookies. But yes, you're right that they don't necessarily have to wait for the user to log in to Google unless that's the only site they care about and the user has not yet logged in to that site. (And apologies for my bad grammar for saying "log into" as well.)

If that were the case, then a single failed login (because of network congestion, for example) would prevent you from ever logging in again. Nobody destroys the shared key. They prevent using passwords twice by using an authentication server that marks the last successful login time and won't let you use a time-based authentication token generated on or before that time stamp (or some similar technique).

The way time-based auth usually works is that either the shared key is hashed with some sort of time stamp or the shared key is used as one of the inputs to a PRNG function whose other input is the number of 30 second periods since some arbitrary time in the past. Given the same key and the same time, the two endpoints can generate the same pair of values, and the authentication server can compare the received value with the expected value. In the latter case, it also typically compute one period before and one period after the current one, to allow for clock drift.

CryptoCard devices do the same basic thing, as I understand it, but the second input is the number of times the button has been pressed. On the server side, it computes the next n possible values after the last one successfully used (where IIRC n is configurable by the server administrator) and if any of them match, that becomes the last one successfully used going forward.

Either way, once that key is compromised (or in the case of CryptoCard, the key plus the number of times you've pushed the button), the system breaks down. This is why your IT department won't give you a copy of the private key associated with your dongle.... :-)

Here's how I know you don't know what you're talking about: All of the things I've talked about have happened already.

Really? Really? Just like that, compromises my cell phone, which is never out of my possession?

A smartphone? You bet. There have been at least two jailbreaks (read "root compromises) for iOS that were triggered by simply going to a web page. In those particular cases, the user knew that he/she was going to a website that did this, but it could just as easily be done surreptitiously.

Nobody bothers to root Android that way because there are generally easier ways to do it, but that doesn't mean it is impossible or even more difficult than it was for iOS. Nor is there any reason to believe that identity thieves do not already have such techniques in their arsenal.

And waits for the user to log into google Again, Really? Do you even have a clue how Google authenticator works? You don't log into google with the authenticator. You log in with some other computer over a ssl connection.

First, that's not necessarily true. Most users do use their phones as browsers, too, which means the device is often the same piece of physical hardware.

Second, even when you do have a proper physical separation between the authenticator and the browser, the only thing it changes is which attacks are relevant:

• If the computer is the compromised device, attacks 1, 2, and 3 are possible.
• If the mobile phone is the compromised device, attack 4 is possible.

In short, the separation is mostly a security no-op.

Even if you had a pre-compromised computer and an elaborate SSL spoofing setup in place ahead of time

Once the endpoint of an SSL/TLS link is compromised, you don't need any spoofing. You can drop an extra self-signed anchor cert into the appropriate trusted anchors list, and you're trusted. There's nothing elaborate about it. It's downright trivial. I can throw together a proof of concept in about three minutes.

For that matter, once the endpoint is compromised, you can just tweak it to display the little lock icon while sending data in the clear. SSL and TLS are worthless if the endpoint is compromised. Completely worthless.

But wait, that wouldn't work either because google already detects this.

Correction. Chrome detects this, but only if the user is running Chrome and that copy has not been modified by the attacker. Once the computer is compromised, you cannot rely on that, either. Any attacker capable of compromising the computer is also capable of compiling a copy of Chrome with those checks disabled. Besides, even if those checks could magically be made impossible to remove, they would still only effectively guard against attack #2, which still means the security hole is wide enough to drive an Abrams tank through it.

It is not possible to detect a man-in-the-middle attack where one of the endpoints is compromised. Period. You're trying to argue against one of the most fundamental tenets of computer security here. There is exactly one way to guarantee that a transaction is secure, and that requires either cryptographic signing or some other form of cryptographic authentication between two trusted endpoints.

Assuming the servers are secure (which isn't 100% certain, but it's sort of an unavoidable assumption), the remaining piece is a hardware device that is not field programmable, that has a screen to show information about a transaction, buttons to authorize or cancel that transaction, and a simple communication protocol, with code that has been proven to be bug free using formal verification techniques. Anything less than that is at best only trivially more secure than passwords.

You owe me a new keyboard.

What needs to be done, as a minimum, is something like Password Hasher (the firefox plugin) needs to be built into each browser.

That protects against what is probably the least interesting situation—when the user's password to one site is silently compromised by attacking that site, and the user used that same password on another site. First, it assumes that the user's password is weak enough to be readily cracked by someone hammering on the password database (which if it is salted properly, is unlikely). Second, it ignores the reality that most passwords are not compromised by server-side security holes; they're compromised by client-side security holes—keyloggers, etc.

To use a car analogy, this is like putting an un-pickable lock on a car to protect your expensive radio, but leaving the factory glass windows untouched.

I think that Google Authenticator tries to prevent mitm attacks by having any given token usable exactly once in addition to having a very short lifespan.

Here's why that doesn't work. The attack is very, very, very simple, and once you see it explained, you'll never trust those sorts of services again. A basic attack looks like this:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker captures the response to the authentication request and forwards it to their own server.
3. Attacker's server connects to Google's system and obtains credentials.
4. Attacker displays a network error message to the user. The user logs in again to the real Google server, unaware that the first attempt was successful, just for somebody else.

Elapsed time: tens of milliseconds after the user logs in. A slightly more sophisticated attack looks like this:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker captures the response to the authentication request and forwards it to their own server.
3. Attacker's server connects to Google's system and obtains credentials.
4. Attacker masquerades as a forwarder for Google's server so that the user is completely oblivious.

Elapsed time: tens of milliseconds after the user logs in. And if the service you're logging into works the way most services do, an even simpler attack looks like this:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker steals the cookies that Google stores on the user's system and uses them on another machine.

Elapsed time: zero milliseconds after the user logs in. But the best one of all is this:

1. Attacker compromises the device and steals the private key used to generate the authentication token.
2. Attacker logs in at will. From anywhere. At any time. Forever and ever.

Elapsed time: zero milliseconds after the device is first compromised or GA is first installed.

All four techniques are 100% transparent and are 100% effective attacks against software-generated time-based authentication schemes. The first two are 100% effective against hardware tokens used for time-based authentication, too. In fact, even if Google upped the ante and made the authenticator be interactive, where the Google servers sent a unique nonce that had to be encoded along with the time stamp, this scheme would still not be significantly stronger. The only change required to the first two schemes would be adding one additional step—telling the attacker's server to issue a request to Google and pass that request nonce to the compromised client. And the third and fourth schemes would continue working as-is. This is why time-based authentication is basically worthless unless the endpoint is trusted (and at this point, I'm growing more and more convinced that users should assume that their endpoints are not trusted).

The reality of the matter is that time-based authentication schemes are an anachronism. When they were first conceived by RSA in the mid-1980s, they were not intended for general users. They were intended to protect against precisely one threat—an attacker with a very specific target watching a user type in his or her password from a distance. They work well for that purpose. They can be compromised once by any attacker who gains control over the system where the authentication token is being entered, even if hardware tokens are involved, and they are permanently compromised by any attacker who gains control over the system where the secret key is stored. The reason there haven't been very many new implementations of time-based authentication since the 1990s is that such schemes just aren't particularly useful against modern attacks. They give the illusion of security without actually adding any. Well, unless you're worried about your roommate seeing you enter your password.

Put another way, creating a secure authentication scheme where the endpoint is compromised is fundamentally impossible for precisely the same reason that perfect DRM is fundamentally impossible. Alice is also Eve and Mallory. Food for thought.