Uh, half of the point of Chrome OS is security. It uses secure boot and full disk encryption, with different accounts encrypted separately.
My point is that I have a problem - I'd like to use lots of random passwords and sync them across all my devices. One of them runs Chrome OS. Keepass does not meet my requirements, and Lastpass does. That's why I use Lastpass.
I'm under no illusions that Lastpass is perfect - but it seems to be the best option I have. The alternative is to re-use passwords which seems to be a worse option.
If Keepass were available for Chrome I'd be pretty likely to use it.
At best that only protects you from somebody stealing their database. It does not protect you from somebody modifying the login page to just send the password to the server and logging it.
If we didn't bomb the middle east so often we wouldn't be allocating so much money to the military in the first place. We weren't doing it before we invaded Iraq. Sure, we still spent plenty, but not nearly as much.
Users are still trained to type their master password into the box, and not to inspect the page source 100% of the time to make sure that client-side javascript is going to not actually send it to them. If you hack their site, and change their login page, you'll get all the passwords you need to crack the keys.
And what happens when somebody cracks their webserver and modifies their site to remove all the fancy Javascript and just have the client send the password to them? The browser won't complain - the SSL cert still is correct and the current browser model trusts websites implicitly. Well, yes-and-no - there is the annoying pop-up the first time you submit form data to any website on some browsers that everybody just disables anyway. Plus, that pop-up would appear whether you submit hashed or clear password data.
Yup, at work everything is moving to sharepoint and we're still stuck on IE6. I click on tabs and literally wait 10-15 seconds for all the scripts to finish running. This is on a dual-core laptop - a few years old, but really. Granted, the full-disk encryption and McBloatee running all the time can't be helping either.
Linux isn't always better. The other day I noticed that my linux box was using 750MB of slab memory. Yikes! I'm not even running a tainted kernel any longer. I used to run my server with only 1GB of RAM...
Only to an extent. I always see this argument but it doesn't usually apply unless the cost applies to everybody. Taxes usually are passed on. Fines usually are not.
The reason is simple - competition. If Sony raises their rates, and Microsoft does not, then people deciding on a console will be more inclined to pick the MS one.
Sony charges every dime the market will bear, and so does Microsoft. They don't charge cost+n% - they charge teenager-monthly-allowance+begging%. What they can charge doesn't change, and begging% is likely to drop when the parents have to get a new credit card and change all their recurring bills that hit the old card. Sony would see the money come out of their profits.
They like to brag that "no PCI certified system has ever been breached" but that's because when you're breached they forensically figure where you violated PCI and retro-actively revoke your certification. It's worse than bullshit it's an expensive fig leaf of security theater.
Sounds like post-claim underwriting. Collect premiums from a customer up until they file a big claim. Then carefully examine history to find some violation, and deny claim. Be sure to refund premiums without interest to be nice. Of course, what they don't do is carefully check the histories of customers who DON'T file claims to see if they're paying for invalid insurance and should get refunds as well. Since the whole nature of insurance is that most people don't file big claims, you can make money hand over fist this way.
1. Get root on webserver. 2. Edit login page. New login page has the user enter their password into a box, and send the password in the clear to the server (fully protected by SSL of course). 3. Send copy of password to wherever. 4. Do whatever the previous secure implementation did with the users's password and pass that into the authentication routine so that the app works fine.
SSL/TLS only protects you against attacks to data in-transit. Now, SSL client certificates would completely prevent this attack, but nobody uses them.
Simple - the only repository that exists for Chrome OS is the Google Web Store. It only supports Chrome applications or extensions, and Keepass has not been implemented as a Chrome application or extension. You don't need to use the Web Store, but Chrome OS still only runs Chrome applications or extensions.
Lastpass is available as a Chrome extension, and works just fine.
Hint, it doesn't exist. At least, not to my knowledge. Chrome OS only supports running chrome-based applications and extensions, and Keepass is neither.
You could just impose a tax on original vehicle sales.
But, honestly, making electric vehicles cheaper will probably save more in the costs to bomb the middle east every few years than it loses in tax revenue.
LastPass is basically the exact same thing. It's encrypted locally and sent to them AFTER encryption. They don't store the plaintext passwords. The danger is the same either way if a user doesn't use a strong enough password.
The problem I have with their site is that they use the same password to encrypt your password database that you use to log into the site. So, if somebody puts the equivalent of a keylogger on their server they get everything.
They should have one password to authenticate to the server, and another password to encrypt the passwords that get uploaded to the site. In fact, you'd only need both when logging in from a client that doesn't use Lastpass, since the latter could safely store the former.
A human checker can always complete my transaction faster than I can unless they are new trainee or something.
Yeah, emphasis on the "or something" - like the checker has no motivation to live. I used to be a checker in high school and since you get paid the same to check out 5 customers or 500 there is really no motivation to keep things moving along. I did simply because psychologically I don't like having piles of work queued up, and I'm just competitive and all that (which is why I pursued an IT/science career and not life as a checker).
I almost always prefer the self-checkout lines unless I have a LOT of stuff. At the place I shop the self-checkouts use a bank teller queue system and not a queue-per-checker system. That means less negative impact from my usual luck of picking the line with the person who has 18 varieties of produce and a checker who takes 5 minutes to look each one up and then the customer pays with food stamps after requesting a tax exemption and has some vouchers from the oil-for-food program or whatever, then writes a check for the balance denominated in rubles. If I'm doing my own checking I at least know that the checker's primary motivation is getting me on my way.
I certainly agree that an even remotely competent checker will easily out-pace the self-checkout. It just seems that competence is not highly valued by the local mega-mart. The mom-and-pop place has the benefit of the owner walking around and seeing lazy employees eating directly into his pocketbook.
I'm sure 3 years ago they were doing everything they could to track this courier without being seen (remember, once he knows he is compromised the last place he will lead you is to OBL). It probably took a while to figure out where OBL was.
Then maybe a few months ago they think they're onto OBL, and they're working on a plan to get him.
Then the name of the courier goes public. While it took the CIA years to follow around that courier, it would only take OBL 15 minutes after somebody noticed that report to realize that the CIA was getting close, and go to ground.
Who knew for two years that the hideout was terrorist-associated? And the idea that Pakistan harbors terrorists is laughable - everybody knows they do (ever hear of Kashmir?). The question was whether they harbored OBL. They're not going to hit some random terrorist training camp in the middle of an allied nation.
I doubt that the US waited years after knowing where OBL was. I suspect that they took action as quickly as they could reasonably do so. The only reason I could see them deliberately holding off is if they thought they had him safely contained and they wanted to gather intel on his network. However, that location seemed anything but contained.
I doubt they were so much concerned about getting a civilian or two so much as bombing a house important to OBL while missing OBL himself. In doing so they'd drive him to ground since he'd know they were onto him.
Various articles suggest that the US was reluctant to even use drones for surveillance, for fear of tipping OBL off. That suggests to me that they were afraid the Pakistan government was complicit - a drone is essentially undetectable at altitude except by radar, but the Pakistani military would certainly notice one buzzing around in the middle of their country.
The news sites suggest that they really only found out about the place a few months ago, and then they wanted to understand what was going on before striking. I'm still surprised it took this long, but the site is clearly sensitive being in the middle of Pakistan. If it turned out that OBL was hiding in the middle of London the US would be just as reluctant to just bomb the place out without so much as a phone call to the Prime Minister. Of course, the US had much more reason to be skeptical of Pakistani intentions, but they're still going to be careful about mounting an attack.
In fact, according to articles the Pakistani military scrambled jets after the attack, and retreating helicopters aren't really much of a match for even 3rd world fighter jets (and it isn't like the US was going to blast a corridor through Pakistani air traffic and radar for them).
In any case, it is precisely the reasons you suggest that make me think that the US really did act relatively quickly based on the information they had.
RAM and CPU are DRAM and will lose data if not refreshed about every 64 ms or less. Once the power is off the refresh stops and the DRAM cells lose their charge (and their stored data) in less than a tenth of a second.
Really? I wasn't aware of any physical process that was capable of reducing the electrical potential between two objects to exactly zero. You can reduce the potential difference to any value arbitrarily close to zero by waiting longer and longer periods of time. Are you suggesting that after only 64ms there will be less than 1/10^10^100 volts of charge difference?
The best you can say is that the potential of the capacitors in the ram is too low to be measured with the equipment you're using to do it. Are you willing to bet that the NSA doesn't have better equipment?
And, I doubt that after a mere 64ms of time that the voltage drops to a level unmeasurable with even fairly accessible hardware.
The reason that RAM needs to be refreshed is so that you don't need some kind of crazy SQUID setup to read the contents of your RAM - not necessarily because it isn't possible to do so.
Yes, blackmailing suspected members of lethal terrorist organizations looks like a profitable and risk-free venture:)
Well, if you're the US government you're already on their target list already, and the fact that you're still alive means that they lack the means to do anything to you for the most part.
If you're Joe Citizen, then yes, unless you also happen to be Superman on the side I wouldn't recommend taking on the ISI or whatever.
The drive? How about your RAM chips and CPU? Those store data too, and there is no theoretical basis for assuming that the data is not retrievable after the device is powered down.
Slashdot Mirror
Uh, Chrome does not support X11 applications, so no. :)
You would need to re-write the code as a Chrome extension.
Uh, half of the point of Chrome OS is security. It uses secure boot and full disk encryption, with different accounts encrypted separately.
My point is that I have a problem - I'd like to use lots of random passwords and sync them across all my devices. One of them runs Chrome OS. Keepass does not meet my requirements, and Lastpass does. That's why I use Lastpass.
I'm under no illusions that Lastpass is perfect - but it seems to be the best option I have. The alternative is to re-use passwords which seems to be a worse option.
If Keepass were available for Chrome I'd be pretty likely to use it.
At best that only protects you from somebody stealing their database. It does not protect you from somebody modifying the login page to just send the password to the server and logging it.
If we didn't bomb the middle east so often we wouldn't be allocating so much money to the military in the first place. We weren't doing it before we invaded Iraq. Sure, we still spent plenty, but not nearly as much.
That would be because there isn't any source for a Chrome extension - you'd have to rewrite most of the application. Or, just use a different one.
Users are still trained to type their master password into the box, and not to inspect the page source 100% of the time to make sure that client-side javascript is going to not actually send it to them. If you hack their site, and change their login page, you'll get all the passwords you need to crack the keys.
And what happens when somebody cracks their webserver and modifies their site to remove all the fancy Javascript and just have the client send the password to them? The browser won't complain - the SSL cert still is correct and the current browser model trusts websites implicitly. Well, yes-and-no - there is the annoying pop-up the first time you submit form data to any website on some browsers that everybody just disables anyway. Plus, that pop-up would appear whether you submit hashed or clear password data.
Yup, at work everything is moving to sharepoint and we're still stuck on IE6. I click on tabs and literally wait 10-15 seconds for all the scripts to finish running. This is on a dual-core laptop - a few years old, but really. Granted, the full-disk encryption and McBloatee running all the time can't be helping either.
Linux isn't always better. The other day I noticed that my linux box was using 750MB of slab memory. Yikes! I'm not even running a tainted kernel any longer. I used to run my server with only 1GB of RAM...
He told you it was on the Internet. Come on, it is only 500 bytes of data on a 5 exabyte internet, you shouldn't have trouble finding it, right?
Only to an extent. I always see this argument but it doesn't usually apply unless the cost applies to everybody. Taxes usually are passed on. Fines usually are not.
The reason is simple - competition. If Sony raises their rates, and Microsoft does not, then people deciding on a console will be more inclined to pick the MS one.
Sony charges every dime the market will bear, and so does Microsoft. They don't charge cost+n% - they charge teenager-monthly-allowance+begging%. What they can charge doesn't change, and begging% is likely to drop when the parents have to get a new credit card and change all their recurring bills that hit the old card. Sony would see the money come out of their profits.
They like to brag that "no PCI certified system has ever been breached" but that's because when you're breached they forensically figure where you violated PCI and retro-actively revoke your certification. It's worse than bullshit it's an expensive fig leaf of security theater.
Sounds like post-claim underwriting. Collect premiums from a customer up until they file a big claim. Then carefully examine history to find some violation, and deny claim. Be sure to refund premiums without interest to be nice. Of course, what they don't do is carefully check the histories of customers who DON'T file claims to see if they're paying for invalid insurance and should get refunds as well. Since the whole nature of insurance is that most people don't file big claims, you can make money hand over fist this way.
Sure it does:
1. Get root on webserver.
2. Edit login page. New login page has the user enter their password into a box, and send the password in the clear to the server (fully protected by SSL of course).
3. Send copy of password to wherever.
4. Do whatever the previous secure implementation did with the users's password and pass that into the authentication routine so that the app works fine.
SSL/TLS only protects you against attacks to data in-transit. Now, SSL client certificates would completely prevent this attack, but nobody uses them.
Simple - the only repository that exists for Chrome OS is the Google Web Store. It only supports Chrome applications or extensions, and Keepass has not been implemented as a Chrome application or extension. You don't need to use the Web Store, but Chrome OS still only runs Chrome applications or extensions.
Lastpass is available as a Chrome extension, and works just fine.
Sure - just provide me a link.
Hint, it doesn't exist. At least, not to my knowledge. Chrome OS only supports running chrome-based applications and extensions, and Keepass is neither.
You could just impose a tax on original vehicle sales.
But, honestly, making electric vehicles cheaper will probably save more in the costs to bomb the middle east every few years than it loses in tax revenue.
LastPass is basically the exact same thing. It's encrypted locally and sent to them AFTER encryption. They don't store the plaintext passwords. The danger is the same either way if a user doesn't use a strong enough password.
The problem I have with their site is that they use the same password to encrypt your password database that you use to log into the site. So, if somebody puts the equivalent of a keylogger on their server they get everything.
They should have one password to authenticate to the server, and another password to encrypt the passwords that get uploaded to the site. In fact, you'd only need both when logging in from a client that doesn't use Lastpass, since the latter could safely store the former.
Really? I use Linux - the Chrome OS distro. Didn't notice it available for that...
A human checker can always complete my transaction faster than I can unless they are new trainee or something.
Yeah, emphasis on the "or something" - like the checker has no motivation to live. I used to be a checker in high school and since you get paid the same to check out 5 customers or 500 there is really no motivation to keep things moving along. I did simply because psychologically I don't like having piles of work queued up, and I'm just competitive and all that (which is why I pursued an IT/science career and not life as a checker).
I almost always prefer the self-checkout lines unless I have a LOT of stuff. At the place I shop the self-checkouts use a bank teller queue system and not a queue-per-checker system. That means less negative impact from my usual luck of picking the line with the person who has 18 varieties of produce and a checker who takes 5 minutes to look each one up and then the customer pays with food stamps after requesting a tax exemption and has some vouchers from the oil-for-food program or whatever, then writes a check for the balance denominated in rubles. If I'm doing my own checking I at least know that the checker's primary motivation is getting me on my way.
I certainly agree that an even remotely competent checker will easily out-pace the self-checkout. It just seems that competence is not highly valued by the local mega-mart. The mom-and-pop place has the benefit of the owner walking around and seeing lazy employees eating directly into his pocketbook.
Because it turns out that it was true.
I'm sure 3 years ago they were doing everything they could to track this courier without being seen (remember, once he knows he is compromised the last place he will lead you is to OBL). It probably took a while to figure out where OBL was.
Then maybe a few months ago they think they're onto OBL, and they're working on a plan to get him.
Then the name of the courier goes public. While it took the CIA years to follow around that courier, it would only take OBL 15 minutes after somebody noticed that report to realize that the CIA was getting close, and go to ground.
Information can be very asymmetric.
Who knew for two years that the hideout was terrorist-associated? And the idea that Pakistan harbors terrorists is laughable - everybody knows they do (ever hear of Kashmir?). The question was whether they harbored OBL. They're not going to hit some random terrorist training camp in the middle of an allied nation.
I doubt that the US waited years after knowing where OBL was. I suspect that they took action as quickly as they could reasonably do so. The only reason I could see them deliberately holding off is if they thought they had him safely contained and they wanted to gather intel on his network. However, that location seemed anything but contained.
I doubt they were so much concerned about getting a civilian or two so much as bombing a house important to OBL while missing OBL himself. In doing so they'd drive him to ground since he'd know they were onto him.
Various articles suggest that the US was reluctant to even use drones for surveillance, for fear of tipping OBL off. That suggests to me that they were afraid the Pakistan government was complicit - a drone is essentially undetectable at altitude except by radar, but the Pakistani military would certainly notice one buzzing around in the middle of their country.
The news sites suggest that they really only found out about the place a few months ago, and then they wanted to understand what was going on before striking. I'm still surprised it took this long, but the site is clearly sensitive being in the middle of Pakistan. If it turned out that OBL was hiding in the middle of London the US would be just as reluctant to just bomb the place out without so much as a phone call to the Prime Minister. Of course, the US had much more reason to be skeptical of Pakistani intentions, but they're still going to be careful about mounting an attack.
In fact, according to articles the Pakistani military scrambled jets after the attack, and retreating helicopters aren't really much of a match for even 3rd world fighter jets (and it isn't like the US was going to blast a corridor through Pakistani air traffic and radar for them).
In any case, it is precisely the reasons you suggest that make me think that the US really did act relatively quickly based on the information they had.
Interesting, where on an AT&T supplied Android phone is this check box that you speak of?
RAM and CPU are DRAM and will lose data if not refreshed about every 64 ms or less. Once the power is off the refresh stops and the DRAM cells lose their charge (and their stored data) in less than a tenth of a second.
Really? I wasn't aware of any physical process that was capable of reducing the electrical potential between two objects to exactly zero. You can reduce the potential difference to any value arbitrarily close to zero by waiting longer and longer periods of time. Are you suggesting that after only 64ms there will be less than 1/10^10^100 volts of charge difference?
The best you can say is that the potential of the capacitors in the ram is too low to be measured with the equipment you're using to do it. Are you willing to bet that the NSA doesn't have better equipment?
And, I doubt that after a mere 64ms of time that the voltage drops to a level unmeasurable with even fairly accessible hardware.
The reason that RAM needs to be refreshed is so that you don't need some kind of crazy SQUID setup to read the contents of your RAM - not necessarily because it isn't possible to do so.
Yes, blackmailing suspected members of lethal terrorist organizations looks like a profitable and risk-free venture :)
Well, if you're the US government you're already on their target list already, and the fact that you're still alive means that they lack the means to do anything to you for the most part.
If you're Joe Citizen, then yes, unless you also happen to be Superman on the side I wouldn't recommend taking on the ISI or whatever.
The drive? How about your RAM chips and CPU? Those store data too, and there is no theoretical basis for assuming that the data is not retrievable after the device is powered down.