Well, it is missing support for ChromeOS (which also requires running in the browser). :)

And I don't really see it as any more secure. Somebody can hack into Lastpass, and somebody can hack into Google. Both are likely fairly robust with their security. Apparently Lastpass is fairly up-front about intrusions.

And nothing prevents you from using a keyfile with lastpass. Just copy/paste it into the password prompt right after typing in your memorized portion of the password. :)

I'd say that keepass is at best equivalent to lastpass if you're able to access the passwords from multiple systems, and if you don't implement it well you could be worse off.

Strange. Had issues with my first post and managed to repost it in the wrong place, with the original apparently going up after all...

Apologies for the noise.

Infrastructure is incredibly vulnerable.

Some big problems:

1. It is distributed all over the place, often just hanging on poles or with little protection beyond a fence.
2. Cost-efficiency often results in minimal redundancy.
3. Cost-efficiency often results in minimal inventory of spares and capacity to make repairs.

Take out a couple of big transformers with a rifle and you could cut power over a very large area with a very lengthy repair time. Take out a fair number of them and you'll exhaust the supply of spares and now you could be talking months of problems (perhaps cannibalizing from other sites at reduced capacity across the grid, and if you take out enough you might just have to leave large areas blacked/browned-out).

Fiber is also difficult to repair. If you had a determined attack you could probably rapidly outpace the ability to locate and repair cuts.

Of course any kind of serious or sustained attack would draw attention and you'd find security improved. However, you could probably do a lot of damage before that happened.

I think the best solution is to build more redundancy into infrastructure, and more capacity for repair. That also makes infrastructure more robust against other kinds of failure. It does cost money, and when you have privatization it requires some kind of way to pay those costs. The government could just buy capacity that it can make available in the event of a disaster. Of course, that would need to be real capacity, and not something that just gets oversubscribed (government buys 1GW of power but doesn't use it, utility just under-provisions by 1GW and sends the government the bill).

Infrastructure is incredibly vulnerable.

Some big problems:

1. It is distributed all over the place, often just hanging on poles or with little protection beyond a fence.
2. Cost-efficiency often results in minimal redundancy.
3. Cost-efficiency often results in minimal inventory of spares and capacity to make repairs.

Take out a couple of big transformers with a rifle and you could cut power over a very large area with a very lengthy repair time. Take out a fair number of them and you'll exhaust the supply of spares and now you could be talking months of problems (perhaps cannibalizing from other sites at reduced capacity across the grid, and if you take out enough you might just have to leave large areas blacked/browned-out).

Fiber is also difficult to repair. If you had a determined attack you could probably rapidly outpace the ability to locate and repair cuts.

Of course any kind of serious or sustained attack would draw attention and you'd find security improved. However, you could probably do a lot of damage before that happened.

I think the best solution is to build more redundancy into infrastructure, and more capacity for repair. That also makes infrastructure more robust against other kinds of failure. It does cost money, and when you have privatization it requires some kind of way to pay those costs. The government could just buy capacity that it can make available in the event of a disaster. Of course, that would need to be real capacity, and not something that just gets oversubscribed (government buys 1GW of power but doesn't use it, utility just under-provisions by 1GW and sends the government the bill).

Bingo. The problem is the use of a shared secret that you end up sharing with half the planet.

I should be able to post a PDF of every government document I've ever gotten online and there should be no risk of impersonation. The only exception should be things like initial-password assignment emails/letters up until the time that the password was initially set.

The problem is that JVM vulnerabilities historically haven't been all that rare. And keeping your JVM up-to-date has always been a hassle. On linux distros there were a lot of licensing problems in the past (I'm not sure how much better that has gotten) - and that made packaging/etc tricky. On other platforms I've found the Sun updaters/etc REALLY annoying. Besides wanting to install malware at every opportunity, it seems like it keeps old versions around and I'm never sure if my system is vulnerable or not.

On a decent linux distro the package manager is going to address the security issues in the JVM, and much of this is exposing problems with other OSes and their lack of package management. However, Sun hasn't really done itself any favors with having such a lousy update experience in general. It seems like it has gotten better, though largely after everybody seems to have moved away from Java everywhere but the enterprise.

The problem is just in the fundamentals of how we design credit/debit/etc cards. We put all the logic in the reader and often the cards themselves are easy to duplicate. Most cards with chips also keep all the logic in the reader but at least the chip makes the card impossible to copy. With just a chip in the card you can still tamper with the transaction details or create transactions as long as the card is present if you subvert the reader.

What we really should move to is a model where all the authorization logic moves to the card. You would carry a hardened device that might only be a bit larger than a traditional credit card (and you could store multiple accounts on it). That card would have an HSM/TPU/etc of some kind, a small display, and a small keypad. The reader would create transactions and transmit them to the card. The card would authorize transactions. The reader would then transmit the authorization to the bank and complete the transaction. To authorize a transaction the card would display the relevant details on-screen (amount, who is getting paid), and would require the entry of a PIN on the card itself. Then it would sign the transaction.

With such a system subverting the terminal doesn't get you very far. You can't tamper with critical transaction details as the card will display the tampered values and the cardholder would decline the transaction. You can't do replay attacks or create multiple transactions, since that requires multiple authorizations on the card, which you don't control. You can't mess with timestamps/etc since the card has its own clock and the bank is of course going to be screening for any nonsense before accepting transactions.

The card would need to have a variety of interfaces, including something like NFC/wireless, some way to interface it with a PC for online transactions, and some way to interact over the phone (acoustic modem?). You could also have alternate modes where the card talks to a proxy (a bank/etc) which might work well for things like phone/in-person when you can't directly connect a card to a reader (reader talks to bank, card talks to bank, reader talks to bank).

As mentioned, writing down your passwords (which this is just a fancy version of) makes them harder to crack online, but opens you up to a different set of attacks, especially any that involve physically overpowering you.

Well, you can keep backups but obviously if they brute force your encryption key then they can log into all your accounts and change your passwords on you.

That has a few challenges:

1. The algorithm needs to be secure. That likely means you can't do it in your head. It probably also means that you'll want to use a standardized tool which is secure.
2. You need to be able to run the algorithm from any device you want to access a website from.
3. If you want auto-fill of password forms (a major timesaver with lastpass) then you need to write a fairly robust application for multiple platforms, which means you'll probably use the same program to run your algorithm everybody else uses.
4. Your algorithm needs to take into account that a single domain could have multiple passwords, and multiple domains could use a shared password. Again, sounds like a robust tool is needed.
5. Using standardized tools means that automated brute-forcing becomes a possibility.
6. Depending on the algorithm, obtaining the password for one site might allow an offline brute-force attack on the algorithm which could yield your other passwords.

I will agree that one advantage of this sort of approach is that there is no cache of passwords to crack, which means that you have to attack the individual websites which generally means an online attack (throttled, limited attempts, etc). However, see #6 above.

Will that auto-fill password forms? Also, how is it any more secure? You're still encrypting your password list and storing it on somebody else's server - if somebody obtains the encrypted list they can attempt to brute-force it.

People who can do it properly are more expensive to hire than people who cannot. There aren't really that many of them compared to the number of people who really need to understand security to make this sort of thing work.

You're basically just giving the CEO the job title of CIO - it doesn't really change anything.

Ah, so employees will be afraid to screw up. I've seen that kind of culture in action. You're right that rules don't get broken. Granted, little that is productive gets done either. Companies don't just want employees who are afraid of getting in trouble. They want to outperform the competition.

So, first of all I know plenty of people in the kinds of industries you've mentioned (healthcare, medical devices, aircraft, banks, etc) and for the most part they don't block the kind of activity on their networks that you advocate blocking. For the most part the data integrity of the products they make doesn't depend on whether or not you can access google from a company PC.

Second, unless you move to a pure whitelisting strategy attempts to enumerate badness are bound to fail. You can't just block every webmail provider on the planet. If you do want to whitelist then you run into the problem where there are new websites that people need to access all the time, and dealing with that is expensive (both in terms of admin overhead and lost productivity while people wait). And if you make the system super-onerous then people will just work around it (using personal addresses/etc to conduct business and the like). Also, most big companies are sending so much data to so many third parties your efforts aren't worth much unless you get them to secure all their networks in the same way. I've seen plenty of consultants who use gmail.

Not only that, but even if the encrypted vault were compromised along with the hashes/etc (allowing somebody to start brute-forcing them), I could easily use lastpass to identify all my accounts and the last change date for each. Since almost all my accounts use random passwords changing them all is a bit of a pain, but not too big a deal. I'm just replacing one random string of values with another. I could change all my accounts in a weekend and all the new passwords are synced across my devices.

Lastpass is extremely convenient and I don't know of many practical alternatives that are any more secure against the same threat models. Maybe a piece of paper in my pocket would be more secure against the remote attacks, but I don't really see that as a step up.

Somewhat. I do get your argument, and I don't wholeheartedly disagree.

The problem is competition. Spending on security costs money. If you do it, and your competitors don't, then they're investing in something that you're not. Unless your competitors actually suffer a serious loss as a result of their choice, then you're going to be at a disadvantage.

Hacking attacks aren't so common yet that security investment provides protection in the marketplace.

Think of it this way. You have 10 competitors. You spend more on security and you're guaranteed to not be taken out by a hacker (for the sake of argument). Your competitors don't make that investment, and they outpace you in other areas. Then along comes a big hacking attack and 3 of them go out of business. That leaves 7 competitors who are still eating your lunch because they went cheap on security. Unless you can last long enough that they're all taken down by hackers, your investment won't pay off.

That said, I do think that things will probably get worse before they get better. If things really got to the point where companies simply couldn't operate without decent security you'd see it prioritized.

For the most part I get paid to deliver software. I'd rather do it right than do it cheap. The problem is that I'm rarely given the time to do things as well as I'd like to, and the mantra is "good enough." In order for "good enough" to include robust security, there needs to be a major culture shift in boardrooms.

The other issue is Schneier's Law. A lot of IT folks can't conceive of how their software could be vulnerable. A lot of stuff gets sold with buzzwords like "encryption" with huge conceptual issues that make it useless in practice. For the most part executives just want plausible deniability. Schneier's Law rather conveniently gives them that.

I don't know the details. I do think that Ultra was more of a UK thing, and Magic was more of a US thing. However, I'm sure there was a fair bit of knowledge sharing going on.

An opinion that most big corporations do not seem to share, judging by their actions.

Recently my corporation bought out a competitor and we ended up utilizing many of their IT systems, since they had received substantially more investment. Some suggested that it was evidence that our IT strategy was wrong, but you could just as easily argue that it was spot-on since we were the ones buying them out. All that money spent on improved IT is money not spent on other things.