"... a lot of money in the market looking for homes"
Yeah. That's what happens when interest rates are zero.
Well, that and the fact that everybody has a dream of spending half their life working overtime, and the other half of their life not working at all but living as if they had the same kind of income. Everybody wants investment growth and is investing a LOT of money, and that tends to create bubbles. I suspect that when all those people start trying to live off of all that saved money the results won't be pretty. Suddenly we move from labor surplus to labor shortage, but we still have that surplus of money lying around.
Just open up the terminal and rewire the display and keypad to go to a different computer, while not touching anything else. The POS terminal sends to the card reader the total bill of $1000. The MITM computer displays on the terminal screen a request to authorize a payment of $10.95, and passes the PIN input to the reader's computer. The reader dutifully passes along the PIN and transaction for $1000 to the credit card, which dutifully notices that the reader is completely valid and authorizes the transaction.
It is just the analog hole in another form. No matter how much you certify the hardware/etc in the end the part that interacts with the human being is just some contact switches and a screen that emits/reflects/whatever light. If you somehow stuck a CPU in the LCD display itself then you'd just bury the original display in the device and stick a new display on the front completely unconnected to the real display, and if for some reason you needed to know what was on the original display you could read it with a camera.
And those are attacks possible without actually messing with the fancier electronics in the reader. If you can attack the actual reader CPU you can do even more.
There is already a ton of logic on the chip card. It's a working computer with apps installed on it.
Sure, but the interface between the chip and its owner is completely MITM'ed by the reader. There is no way for the chip to know whether the transaction it is being asked to authorize by the reader is the one the account holder wants to authorize.
All the chip does is prove that it is present, or maybe accept a PIN number first.
And I won't argue that the US banks are worse than the rest of the world. I just think that chip-and-PIN alone is really far short of what could be done to secure cards.
Couple of things: first, disk never gets near full because of root reservation. Second - there is implicit trim when you overwrite a block with new data (think about it). So my point still stands.
He never claimed the drive got full. He said that the issue occurs when you've written a drive's worth of data. You can write a drive's worth of data without filling up even 1% of the drive, if you just overwrite one logical block in-place repeatedly.
Of course the drive erases a block when you overwrite it. The whole point of trim is that it improves performance when this is done. If you overwrite a 512-byte block that isn't trimmed the drive has to erase the surrounding 4K worth of blocks, and then rewrite the previous data back along with your 512-bytes worth of new data. Then if you write to the next 512-byte block 10min later it repeats the process. For wear-leveling it might move blocks around, but you still have the issue in some form.
You only can get away with the "implicit trim" strategy completely if you only write in multiples of the SSD erase block size, aligned to SSD erase block boundaries, and the drive actually is designed to let that happen.
Additionally it is confirmed experimentally - at some point I used a trashy usb stick as the only drive on a 24/7 microserver (with a lot of writes) for over a year with no problems.
Just what problems would you expect to see? Not using TRIM doesn't cause failures. It can result in premature wear, and lower performance. It doesn't make the drive magically fail long before it should, and unless you did some kind of comparative benchmark you might not notice the performance drop.
No idea in general, but I'd think that a log-based filesystem would be fairly immune to this kind of nonsense since it would only issue TRIMs very rarely, and then only for huge areas of the disk at a time. They don't overwrite random blocks in-place constantly.
There is are two easy solutions to Ext4 vs. SSD problems. The first is ReiserFS which is still eminently usable on Gentoo. The second is UFS which is available on the BSD's.
If the problem is that the drive doesn't follow the spec for TRIM, I'd rather just disable TRIM than try to keep using it with a different filesystem. That seems a bit like playing Russian Roulette. Are you really that sure that ReiserFS won't have the same problem (unless it just doesn't use TRIM anyway, in which case it is no better than ext4 without TRIM).
Lastpass is extremely convenient and I don't know of many practical alternatives that are any more secure against the same threat models.
Keepass with sync to a Google account. Gives you everything Lastpass Premium does for free, and it's more secure to boot. 2FA is free with Google accounts (no need to buy additional hardware), sync to mobile devices is free, and by not running in the browser and allowing you to use an optional keyfile as well as a master password it's more secure.
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.
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).
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).
... those that use identity as authorization. if someone knows your number then all they technically have is knowing who you are. if they use your number to incur a debt then the party that accepted it is the real perp.
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.
Buffer overruns exploits are virtually non-existant in Java, caused only by rare defects in the JVM itself.
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 only really worrisome one to me is the ATM card skimmers, because if you go to an unknown ATM, it's hard to know if it has a skimmer on top or not. Furthermore, it has increased dramatically over the past few years, up 300% from last year.
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.
And if your Lastpass account is ever hacked you'll lose access to all those accounts.
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.
Better to come up with a simple algorithm to generate your password based on the site you're using. No need to store anything. One less 3rd party knowing all the sites you care about. One hack required per account. Automated hacking and data mining tools aren't going to understand your algorithm.
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.
This: rezial.com I admit that I never tried LastPass, so I'm not claiming this is better/more convenient.. I use it, and I'm happy with it.
but now I also want to try LastPass:)
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.
The notion that security is expensive is largely a product of hiring people that don't have the training to do it properly.
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.
What this means is that in matters of security, the CIO must be able to overrule the CEO.
You're basically just giving the CEO the job title of CIO - it doesn't really change anything.
Personal relationships are also important. People need to understand "oh, that's right, Jeff will fucking make an ass of me if I submit this code. What did he show me the other day? Oh that's right, if I code it this way it will not be bypass the encryption if he pokes the program with a stick."
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.
Here you might say "but some companies don't need that much security"... doesn't really matter. The security itself is cheap. You just limit the operation of the system to what you need to do and then encourage employees to BYOD for personal shit. The BYOD stuff will not connect to company machines. It isn't expensive.
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.
I'm the submitter. I'm a LastPass user and I'll stay that way. If you actually read the article you'll see that things are under control.
This is the second time LastPass has reported an attack that I can remember, and because of the client-side encryption and so on it's not a huge deal. Bravo to them for their proactive stance and sound methods.
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.
Your argument is now that "well people in charge don't agree with you so you must be wrong."
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.
Obviously air-gapping would help a lot here. However, I hear a lot of talk of encryption, and I don't really see how that would help.
Encryption really only protects data at rest. Encrypting your backup tapes before mailing them to a repository prevents their loss in transit, which is a significant risk.
On the other hand, if I encrypt my hard drive that isn't going to do me any good at all if somebody hacks into the system while that drive is mounted. Personnel records seem at least reasonably likely to be accessed regularly.
You have NO WAY of knowing whether China are doing this, officially or not.
Not sure who you meant by "you." If you mean the average slashdotter, then obviously you're right. If you're talking about the CIA/FBI/etc, it is hard to say what they could reliably know. Obviously merely knowing that the attack from China doesn't help much, other than to make the argument that the Chinese need to crack down on online crime more. However, for all we know the US has some agents at high levels in the Chinese government, etc.
But, the US isn't making any official accusations. Random politicians grandstanding is as likely to be gossip as leaking intelligence.
I do suspect that at some point countries are going to get tired of these kinds of attacks regardless of the source. If some rockets were launched from Canada onto a border town it isn't like the US would launch a full scale retaliatory invasion. However, if it happened with any regularity you could imagine that people would get tried of it. If I hacked into the Chinese military from my house, I'm pretty sure the FBI wouldn't just sit idly by when the Chinese complained about it. They may very well do something underhanded like try to recruit me, but they're not going to just tolerate random individuals committing crimes and creating diplomatic incidents.
Most background information is not self-volunteered, it is gathered by FBI agents, etc., at their own discretion.
Simply looking at trends around this would be very useful in sneaking moles into government jobs, since it tells you what the FBI typically investigates.
Instead of keeping those records in distributed and isolated/compartmentalized silos(where the scope of any individual security failure would be non-catastrophic) where the cost-to-benefit ratio of data ex-filtration was much less attractive: they consolidated all of this data in one place where a single chink in the armor would allow an adversary to acquire the sum total knowledge in existence of their entire classified documents workforce...
Never underestimate the power of cost-cutting. Having data in one place also increases its utility, if for example there is a need to mine this data for some pattern (trying to find a mole based on disclosed past associations or whatever). An obvious use for having access to all of this data would be to match up the disclosed relationships/etc to every Facebook friend pairing and phone call on the planet and seeing what was left out.
At work we do all kinds of stupid stuff over quests to save $50 here or there.
Slashdot Mirror
"... a lot of money in the market looking for homes"
Yeah. That's what happens when interest rates are zero.
Well, that and the fact that everybody has a dream of spending half their life working overtime, and the other half of their life not working at all but living as if they had the same kind of income. Everybody wants investment growth and is investing a LOT of money, and that tends to create bubbles. I suspect that when all those people start trying to live off of all that saved money the results won't be pretty. Suddenly we move from labor surplus to labor shortage, but we still have that surplus of money lying around.
Just open up the terminal and rewire the display and keypad to go to a different computer, while not touching anything else. The POS terminal sends to the card reader the total bill of $1000. The MITM computer displays on the terminal screen a request to authorize a payment of $10.95, and passes the PIN input to the reader's computer. The reader dutifully passes along the PIN and transaction for $1000 to the credit card, which dutifully notices that the reader is completely valid and authorizes the transaction.
It is just the analog hole in another form. No matter how much you certify the hardware/etc in the end the part that interacts with the human being is just some contact switches and a screen that emits/reflects/whatever light. If you somehow stuck a CPU in the LCD display itself then you'd just bury the original display in the device and stick a new display on the front completely unconnected to the real display, and if for some reason you needed to know what was on the original display you could read it with a camera.
And those are attacks possible without actually messing with the fancier electronics in the reader. If you can attack the actual reader CPU you can do even more.
There is already a ton of logic on the chip card. It's a working computer with apps installed on it.
Sure, but the interface between the chip and its owner is completely MITM'ed by the reader. There is no way for the chip to know whether the transaction it is being asked to authorize by the reader is the one the account holder wants to authorize.
All the chip does is prove that it is present, or maybe accept a PIN number first.
And I won't argue that the US banks are worse than the rest of the world. I just think that chip-and-PIN alone is really far short of what could be done to secure cards.
Couple of things: first, disk never gets near full because of root reservation. Second - there is implicit trim when you overwrite a block with new data (think about it). So my point still stands.
He never claimed the drive got full. He said that the issue occurs when you've written a drive's worth of data. You can write a drive's worth of data without filling up even 1% of the drive, if you just overwrite one logical block in-place repeatedly.
Of course the drive erases a block when you overwrite it. The whole point of trim is that it improves performance when this is done. If you overwrite a 512-byte block that isn't trimmed the drive has to erase the surrounding 4K worth of blocks, and then rewrite the previous data back along with your 512-bytes worth of new data. Then if you write to the next 512-byte block 10min later it repeats the process. For wear-leveling it might move blocks around, but you still have the issue in some form.
You only can get away with the "implicit trim" strategy completely if you only write in multiples of the SSD erase block size, aligned to SSD erase block boundaries, and the drive actually is designed to let that happen.
Additionally it is confirmed experimentally - at some point I used a trashy usb stick as the only drive on a 24/7 microserver (with a lot of writes) for over a year with no problems.
Just what problems would you expect to see? Not using TRIM doesn't cause failures. It can result in premature wear, and lower performance. It doesn't make the drive magically fail long before it should, and unless you did some kind of comparative benchmark you might not notice the performance drop.
how is f2fs now-a-days?
No idea in general, but I'd think that a log-based filesystem would be fairly immune to this kind of nonsense since it would only issue TRIMs very rarely, and then only for huge areas of the disk at a time. They don't overwrite random blocks in-place constantly.
There is are two easy solutions to Ext4 vs. SSD problems. The first is ReiserFS which is still eminently usable on Gentoo. The second is UFS which is available on the BSD's.
If the problem is that the drive doesn't follow the spec for TRIM, I'd rather just disable TRIM than try to keep using it with a different filesystem. That seems a bit like playing Russian Roulette. Are you really that sure that ReiserFS won't have the same problem (unless it just doesn't use TRIM anyway, in which case it is no better than ext4 without TRIM).
Lastpass is extremely convenient and I don't know of many practical alternatives that are any more secure against the same threat models.
Keepass with sync to a Google account. Gives you everything Lastpass Premium does for free, and it's more secure to boot. 2FA is free with Google accounts (no need to buy additional hardware), sync to mobile devices is free, and by not running in the browser and allowing you to use an optional keyfile as well as a master password it's more secure.
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).
... those that use identity as authorization. if someone knows your number then all they technically have is knowing who you are. if they use your number to incur a debt then the party that accepted it is the real perp.
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.
Buffer overruns exploits are virtually non-existant in Java, caused only by rare defects in the JVM itself.
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 only really worrisome one to me is the ATM card skimmers, because if you go to an unknown ATM, it's hard to know if it has a skimmer on top or not. Furthermore, it has increased dramatically over the past few years, up 300% from last year.
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).
There's always this: http://www.passwordcard.org/en
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.
And if your Lastpass account is ever hacked you'll lose access to all those accounts.
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.
Better to come up with a simple algorithm to generate your password based on the site you're using. No need to store anything. One less 3rd party knowing all the sites you care about. One hack required per account. Automated hacking and data mining tools aren't going to understand your algorithm.
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.
This: rezial.com
I admit that I never tried LastPass, so I'm not claiming this is better/more convenient.. I use it, and I'm happy with it.
but now I also want to try LastPass :)
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.
The notion that security is expensive is largely a product of hiring people that don't have the training to do it properly.
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.
What this means is that in matters of security, the CIO must be able to overrule the CEO.
You're basically just giving the CEO the job title of CIO - it doesn't really change anything.
Personal relationships are also important. People need to understand "oh, that's right, Jeff will fucking make an ass of me if I submit this code. What did he show me the other day? Oh that's right, if I code it this way it will not be bypass the encryption if he pokes the program with a stick."
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.
Here you might say "but some companies don't need that much security"... doesn't really matter. The security itself is cheap. You just limit the operation of the system to what you need to do and then encourage employees to BYOD for personal shit. The BYOD stuff will not connect to company machines. It isn't expensive.
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.
I'm the submitter. I'm a LastPass user and I'll stay that way. If you actually read the article you'll see that things are under control.
This is the second time LastPass has reported an attack that I can remember, and because of the client-side encryption and so on it's not a huge deal. Bravo to them for their proactive stance and sound methods.
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.
Your argument is now that "well people in charge don't agree with you so you must be wrong."
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.
Your risk assumptions are flawed.
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.
Obviously air-gapping would help a lot here. However, I hear a lot of talk of encryption, and I don't really see how that would help.
Encryption really only protects data at rest. Encrypting your backup tapes before mailing them to a repository prevents their loss in transit, which is a significant risk.
On the other hand, if I encrypt my hard drive that isn't going to do me any good at all if somebody hacks into the system while that drive is mounted. Personnel records seem at least reasonably likely to be accessed regularly.
You have NO WAY of knowing whether China are doing this, officially or not.
Not sure who you meant by "you." If you mean the average slashdotter, then obviously you're right. If you're talking about the CIA/FBI/etc, it is hard to say what they could reliably know. Obviously merely knowing that the attack from China doesn't help much, other than to make the argument that the Chinese need to crack down on online crime more. However, for all we know the US has some agents at high levels in the Chinese government, etc.
But, the US isn't making any official accusations. Random politicians grandstanding is as likely to be gossip as leaking intelligence.
I do suspect that at some point countries are going to get tired of these kinds of attacks regardless of the source. If some rockets were launched from Canada onto a border town it isn't like the US would launch a full scale retaliatory invasion. However, if it happened with any regularity you could imagine that people would get tried of it. If I hacked into the Chinese military from my house, I'm pretty sure the FBI wouldn't just sit idly by when the Chinese complained about it. They may very well do something underhanded like try to recruit me, but they're not going to just tolerate random individuals committing crimes and creating diplomatic incidents.
Most background information is not self-volunteered, it is gathered by FBI agents, etc., at their own discretion.
Simply looking at trends around this would be very useful in sneaking moles into government jobs, since it tells you what the FBI typically investigates.
Instead of keeping those records in distributed and isolated/compartmentalized silos(where the scope of any individual security failure would be non-catastrophic) where the cost-to-benefit ratio of data ex-filtration was much less attractive: they consolidated all of this data in one place where a single chink in the armor would allow an adversary to acquire the sum total knowledge in existence of their entire classified documents workforce...
Never underestimate the power of cost-cutting. Having data in one place also increases its utility, if for example there is a need to mine this data for some pattern (trying to find a mole based on disclosed past associations or whatever). An obvious use for having access to all of this data would be to match up the disclosed relationships/etc to every Facebook friend pairing and phone call on the planet and seeing what was left out.
At work we do all kinds of stupid stuff over quests to save $50 here or there.