Slashdot Mirror

1. I don't recall Microsoft ever detailing exactly what data is being collected.

MS revealed it a while back. Here's a link summarizing it.
http://www.windowsecurity.com/...

2. It's encrypted, so we can't examine it for ourselves.

It should be encrypted. Why would you have it any other way.

3. Microsoft has been deceptive and even telling outright lies since the beginning [arstechnica.com] of the Windows 10 rollout.

Unclear, not deceptive. They said it would be free and didn't know what direction the licensing would head. That's perfectly fine as fine as most are concerned.

See 2, above. No one can look and see what data Microsoft is collecting from their Windows 10 PC, so how is one to know whether or not they've been harmed? Your argument is the same one NSA uses to claim they can't be sued over warrantless wiretapping. "No one can prove they specifically were wiretapped, so no one has any standing to sue." I say bullshit to that argument.

That's your paranoia kicking in. Do you think you matter that much that you will be harmed by your data? If the government wants to take you out stop trying to find an out because you're already cooked.

Prove to me you care about your privacy by ditching your mobile device(s). Do that and I'll believe you truly care that much about your privacy.

XP is crap. Its driver model and security model are a total joke.

Please be more specific because the whole NT line shares the same driver model (the most significant changes were actually in win2k with the addition of PnP) and security model. And that includes windows 10... The addition of UAC dialogs instead of runas, isn't a security "model" change so much as a implementation detail. The virtualized HKLM aren't really "security model" changes either and are probably the single largest security change to newer windows that actually makes a difference over running as a restricted user in 2k,xp,2k3.

So, i'm curious what exactly you think is crap about the windows security model and what exactly changed that had a meaningful impact.. And no, simply changing the default user to a restricted one doesn't really count because anyone with 1/2 a brain did the same thing to older windows installs. Maybe the largest resulting change is that crap software now actually works consistently in such an environment without having to implement custom policies for busted applications. ASLR maybe? Because that is application specific and there are 3rd party utilities that provide it for XP. Same thing for driver signature enforcement, its possible to set a GPO to reject unsigned drivers. Something ACL related maybe? Because in microsoft's words "The fundamental structure of access control lists (ACLs) has not changed much for Windows Vista".

You should really read this article http://www.windowsecurity.com/... which is a pretty good introduction to the security features of the NT kernel, so that you can communicate effectively about what you think is wrong with windows security model before you start making blanket statements about it.

The article states "the encryption method used was devised in 1998 and is weak by today’s standards ... Microsoft has yet to release a patch to fix the Redirect to SMB vulnerability" as if Microsoft must remove the feature in order for Cylance to consider this resolved. Instead a number of improvements have been made to SMB since 1998 include support for HMAC-SHA256 (v2.0) and AES-CMAC (v3.0) hashing. http://www.windowsecurity.com/.... You are going need a little more than "$3000 worth of GPUs" to forward brute force the AES-CMAC hashed passwords.

As a MITM attacker, can't I just spoof the sender's domain here?

Granted, it does add a fairly decent layer of complexity to the MITM : http://www.windowsecurity.com/articles/understanding-man-in-the-middle-attacks-arp-part2.html

How User Account Control uses Virtualization to protect the system via "UAC Virtualization":

http://www.windowsecurity.com/articles/Protecting-System-Files-UAC-Virtualization-Part1.html

* You can do it via Taskmgr.exe, & selecting the column that sets it graphically (via VIEW menu, Select Columns submenu) & then right-click on the process to set it (just like setting CPU priority pretty much there)...

(The article offers more "hardcore" (not, it's easy too, just more detail is all) ways to SET various apps to run that way, always... not just when YOU set them to manually as I showed above via taskmgr.exe!)

So, what's it DO for you? Ok:

It essentially ISOLATES apps to write only in their appdir, & isolates changes to THAT USER'S PROFILE ONLY (so it doesn't spread into other user profiles on that machine)...

APK

P.S.=> There's MORE you can do to "stall" bogus installation, & even make your Windows 7 PC more like a MacOS X rig, by making UAC more "stringent" switching to a "secure desktop" if ANYTHING tries to install + having to LOGON as a LOCAL ADMINISTRATOR group user to do it:

The settings to examine & change are as follows in gpedit.msc &/or regedit.exe:

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Admin Approval Mode for the Built-in Administrator account

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v FilterAdministratorToken

(Set as ENABLED)

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v ConsentPromptBehaviorAdmin

(Set as PROMPT FOR CREDENTIALS)

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Behavior of the elevation prompt for standard users

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v ConsentPromptBehaviorUser

(Set as Automatically deny elevation requests)

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Detect application installations and prompt for elevation

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableInstallerDetection

(Set as ENABLED)

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Only elevate UIAccess applications that are installed in secure locations

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableSecureUIAPaths

(Set as ENABLED)

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Run all administrators in Admin Approval Mode

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA

(Set as ENABLED)

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Switch to the secure desktop when prompting for elevation

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v PromptOnSecureDesktop

(Set as ENABLED)

---

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Virtualize file and registry write failures to per-user locations

OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableVirtualization

(Set as ENABLED)

---

Don't MS often complain that windows is only perceived as insecure because its ubiquitous and therefore commonly targeted, and that other systems only appear more secure because noone bothers to target a small marketshare...

Yes.

Surely then, the same applies to windows phone, it has a tiny marketshare and therefore very few people are interested in attacking it.

Yes.

The windows phone kernel is based on windows ce, which is inherently a single user os, im fairly sure that once you get down to it, the system is considerably less secure than android or ios, both of which are based on tried and tested multiuser kernels.

Not sure what single vs multiuser would have to do with overall device security since on the Android side none of the security issues we've seen have anything to do with the kernel. Why would you compare the kernel the Windows Phone platform with the userland of Android?

A quick search shows that Microsoft is not using the user model of security in Windows Phone 7 at all.

Protected Mode leverage's Windows Vista's UAC

You're right that its not running in a VM like VMware, but we're talking about the same thing. IE7's protected mode is just a UAC Virtualization applied to IE7. For more info on virtualized processes: http://www.windowsecurity.com/articles/Protecting-System-Files-UAC-Virtualization-Part1.html but it sounds like you are already familiar with it.

BTW, the link is for anybody else reading, it's apparent you are familiar w/ how UAC works. Cheers.

It's actually quite a bit easier to do than that. Just disable usbstor.sys with GPO. done. Keyboards still work. Mice still work. Just mass storage devices. And whoever said you can't prevent execute on windows systems is ignorant. You've been able to deny "Read & Execute" via NTFS permissions since NT 3. Note: Read is a seperate right. Since you have to be able to read it to exectute it, it's just included in the permission description. Semantics. Here's something that may help you understand it. It's not that complicated. In reading the doc it will talk about share permissions and individual permissions, group permissions, and NTFS permissions all seperately, and what wins in what scenario, and will talk about scenarios that no administrator that is worth his salt would ever implement. When done correctly it's actually very simple. However it does have the flexibility to be as complex as one needs it to be. http://www.windowsecurity.com/articles/Understanding-Windows-NTFS-Permissions.html So there.

5%, 25%, 50%? 90%? Are there estimates for the "rate never before seen" that users are having their personal information stolen?

And what personal information is it? To extend the old saying "If it is on the internet, it is public". Well, *all* information you store the computer that you access the internet suffers from this lack of security.

A truly secure user experience would be managing personal data on an unconnected system (or even a private network of systems) and then transferring data from there that needs to make it to the Internet via the Sneakernet. This is how the Department of Defense guarantees the security of Secure Facilities, and it is (unfortunately) the only way to guarantee the security of your own personal information.

But for systems that are on the 'Net, using an OS that doesn't hide/obfuscate fundamental security models is a plus. For example, it is easier for me to shutdown outgoing ports/services on Linux than on Windows.

As far as browser exploits... one can only hope that developers close off the attack vectors faster than they open new ones.

... and authenticating it!

Virtually undetectable for the casual user:
They don't show up in explorer and other file managers and task manager even shows the name of the host file.

One thing, though, he could have mentioned - various IP spoofing methods. Imagine you are on a DHCP network (on campus, for example.) You ask for an IP and you will get it, and this will be logged: "00:f0:3e:45:33:66, authorized as belonging to John Doe, asked for an IP and got 10.0.15.213 for 6 hours". Nice. However what if you want to misrepresent yourself? An enterprising student can use ping and arp (if not some better tools) to find out what IP and MAC addresses are online, and once some of those computers go to class (or to sleep, for example,) take over the MAC address and ask for a new DHCP lease ... done, and you have a new shiny IP address, perfectly logged as belonging to John Doe whereas you are someone else entirely.

This would clearly demonstrate that the DHCP has no authentication beyond the MAC address, and that can be easily changed on many cards. Any judge, however technically illiterate, can understand that if you can get any identity by just asking then it's pointless to hold the identity owner responsible.

This text, as seen here, would be relevant in the expert's refutation:

Unfortunately it's the very simplicity of DHCP that's actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.

And when, on Windows, you can combine console commands in a script file that, for example, looks for illegal access attempts on your Internet connection and, when they happen, not only emails you to tell you they are happening but also reconfigures your firewall to block those IP addresses for an hour, works out the DNS domain from the IP address and then automatically emails a complaint to "abuse@" that domain reporting the problem, then give me a shout.

Is it cheating to use cygwin? :)

Actually, you could probably accomplish much of that using WSH, with which you could use any WSH-enabled language. You can certainly accomplish it with perl. Read up on the netsh firewall functionality...

In what way does this prevent FairUse4WM?

This is a good thing to prevent viruses, without affecting anything else. Buffer overflow attacks need to rely on a known location in memory to jump to, typically kernel32!LoadLibrary/GetProcAddress, which will allow them to dynamically access the rest of the functions they need. Read more here: http://www.windowsecurity.com/articles/Analysis_of _Buffer_Overflow_Attacks.html

This is 100% completely unrelated to DRM bypass programs, which can actually link to the correct functions. Anyone who mods the parent up has no idea about how windows security or programming works.

It sounds like the parent might (just trying to be generous here) be confusing FairUse4WM with the Apple Fairplay hack tool, which does rely on known offsets within the fairplay module's memory layout. However, even that wouldn't be affacted by this, since an actual properly linked program can still determine the base address it needs.

"Recently, a coworker tried to assert that encrypting a file twice with a 64 bit algorithm is equivalent to encrypting it once with a 128 bit algorithm. I know enough about encryption to know that isn't true, but I am having difficulties explaining why and how. Doesn't each pass of the encryption create a separate file header which makes this assertion untrue? Can anyone point me to references that would better help me explain this?"

First of all, what is a '64-bit encryption algorithm'? Is this a symmetric or asymmetric algorithm? Is it a block or stream cipher? Are you talking about block or key sizes? What specific algorithm are you referring to?

We can't analyze anything if all we're given are vague generalizations like "a 64-bit algorithm" and "a 128-bit algorithm". Some symmetric ciphers gain security under functional composition. We know that DES is one such cipher, since it has been shown that DES is not a group. However, it is not true in general that symmetric ciphers gain security under composition. For example, no matter how many times you encrypt something using a Caesar cipher (a generalization of ROT-13), there will always be a single key that decodes the resulting ciphertext. Ask your coworker to show that the specific algorithm you're discussing is not a group. If he can't, then what reason do you have to believe that you gain any security through what he proposes?

The second problem here is that your coworker seems to think that the onus is on you to prove that a given system is insecure. Every time an expert invents a new cryptosystem, there is a good chance that the system will be insecure; It is a near-certainty that any cryptosystem your coworker comes up with will be insecure. Bruce Schneier brought up this topic again in this month's Crypto-Gram :

Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

Thirdly, even if your coworker's new cipher design---and that's what it is---miraculously has the security properties that he thinks it does, is that enough? If you're using 128-bit keys in a symmetric cipher, you're only getting 64 bits of security, thanks to the "Birthday Paradox". If you want an attacker to have to perform 2^128 steps to brute-force your key, then you should be using 256-bit keys anyway. Justin Troutman explains this in more detail in his two-part series, "Ideal-to-Realized Security Assurance In Cryptographic Keys".

Finally, all this talk about composing cipher primitives might well be irrelevant. What is this cipher being used for? Disk-based encryption, for example, has vastly different requirements than a typical secure channel. (See New Methods in Hard Disk Encryption for a discussion of some of the issues associated with hard disk encryption.) What mode of operation are you using? What are you using for authentication? How much information does your cryptosystem leak? How are you negotiating what protocol you're using? To what extent is your protocol switch vulnerable to a chosen protocol attack? What about implementation issues?

I suggest that your coworker read the first two chapters

"Recently, a coworker tried to assert that encrypting a file twice with a 64 bit algorithm is equivalent to encrypting it once with a 128 bit algorithm. I know enough about encryption to know that isn't true, but I am having difficulties explaining why and how. Doesn't each pass of the encryption create a separate file header which makes this assertion untrue? Can anyone point me to references that would better help me explain this?"

First of all, what is a '64-bit encryption algorithm'? Is this a symmetric or asymmetric algorithm? Is it a block or stream cipher? Are you talking about block or key sizes? What specific algorithm are you referring to?

We can't analyze anything if all we're given are vague generalizations like "a 64-bit algorithm" and "a 128-bit algorithm". Some symmetric ciphers gain security under functional composition. We know that DES is one such cipher, since it has been shown that DES is not a group. However, it is not true in general that symmetric ciphers gain security under composition. For example, no matter how many times you encrypt something using a Caesar cipher (a generalization of ROT-13), there will always be a single key that decodes the resulting ciphertext. Ask your coworker to show that the specific algorithm you're discussing is not a group. If he can't, then what reason do you have to believe that you gain any security through what he proposes?

The second problem here is that your coworker seems to think that the onus is on you to prove that a given system is insecure. Every time an expert invents a new cryptosystem, there is a good chance that the system will be insecure; It is a near-certainty that any cryptosystem your coworker comes up with will be insecure. Bruce Schneier brought up this topic again in this month's Crypto-Gram :

Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

Thirdly, even if your coworker's new cipher design---and that's what it is---miraculously has the security properties that he thinks it does, is that enough? If you're using 128-bit keys in a symmetric cipher, you're only getting 64 bits of security, thanks to the "Birthday Paradox". If you want an attacker to have to perform 2^128 steps to brute-force your key, then you should be using 256-bit keys anyway. Justin Troutman explains this in more detail in his two-part series, "Ideal-to-Realized Security Assurance In Cryptographic Keys".

Finally, all this talk about composing cipher primitives might well be irrelevant. What is this cipher being used for? Disk-based encryption, for example, has vastly different requirements than a typical secure channel. (See New Methods in Hard Disk Encryption for a discussion of some of the issues associated with hard disk encryption.) What mode of operation are you using? What are you using for authentication? How much information does your cryptosystem leak? How are you negotiating what protocol you're using? To what extent is your protocol switch vulnerable to a chosen protocol attack? What about implementation issues?

I suggest that your coworker read the first two chapters

[Please mod my previous reply down. It's botched.]

There is some information about the algorithms they're using here. That page says that they're using 1024-bit DH to negotiate a 128-bit AES key, then they XOR the output of the AES algorithm with the voice data.

Frankly, I don't trust it.

First of all, neither 1024-bit DH nor 128-bit AES actually give you 128-bit security (i.e. 2^128 complexity). For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about Diffie-Hellman, but it's similar in structure to RSA, and experts have been recommending at least 2048-bit keys for new designs using RSA for years, and that's not even to get a 128-bit security level. For a true 128-bit security level, you need something like 6100 bits (if I remember correctly), which most people don't use because it's very slow to do in software.

The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single repeating AES ciphertext block with the entire plaintext datastream, which would be trivially insecure. We really have no way of knowing.

As for authentication, which is often more important than confidentiality (and which may be required for confidentiality)? This is all I could find:

Additional security and integrity is ensured by a calculated HASH checksum that is indicated on the display.

There is no mention of what hash function is being used, nor of what is being hashed. Furthermore, people who talk about "HASH" -- in all-caps, as if HASH is an algorithm itself -- clearly don't know what they're doing. It might just be Vecrotel's marketing department messing things up. Or, it could be a more fundamental lack of expertise within the company. Who knows?

Have a look at the Vecrotel FAQ:

VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.

...

KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS SOURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.

Totally unacceptable.

If those really are "frequently-asked questions", those responses are simply arrogant. The company has clearly adopted a "trust us" mentality. If I was willing to blindly trust other companies, I wouldn't be looking for a secure phone!

Crypto products are like voting machines. If their operation is not independently verifiable, then they simply cannot be trusted.

As an interesting side note, I don't see any FIPS certifications.

I smell snake oil.

[Please mod my previous reply down. It's botched.]

There is some information about the algorithms they're using here. That page says that they're using 1024-bit DH to negotiate a 128-bit AES key, then they XOR the output of the AES algorithm with the voice data.

Frankly, I don't trust it.

First of all, neither 1024-bit DH nor 128-bit AES actually give you 128-bit security (i.e. 2^128 complexity). For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about Diffie-Hellman, but it's similar in structure to RSA, and experts have been recommending at least 2048-bit keys for new designs using RSA for years, and that's not even to get a 128-bit security level. For a true 128-bit security level, you need something like 6100 bits (if I remember correctly), which most people don't use because it's very slow to do in software.

The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single repeating AES ciphertext block with the entire plaintext datastream, which would be trivially insecure. We really have no way of knowing.

As for authentication, which is often more important than confidentiality (and which may be required for confidentiality)? This is all I could find:

Additional security and integrity is ensured by a calculated HASH checksum that is indicated on the display.

There is no mention of what hash function is being used, nor of what is being hashed. Furthermore, people who talk about "HASH" -- in all-caps, as if HASH is an algorithm itself -- clearly don't know what they're doing. It might just be Vecrotel's marketing department messing things up. Or, it could be a more fundamental lack of expertise within the company. Who knows?

Have a look at the Vecrotel FAQ:

VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.

...

KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS SOURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.

Totally unacceptable.

If those really are "frequently-asked questions", those responses are simply arrogant. The company has clearly adopted a "trust us" mentality. If I was willing to blindly trust other companies, I wouldn't be looking for a secure phone!

Crypto products are like voting machines. If their operation is not independently verifiable, then they simply cannot be trusted.

As an interesting side note, I don't see any FIPS certifications.

I smell snake oil.

Frankly, I don't trust it.

First of all, neither 1024-bit DH nor 128-bit AES actually give you 2^128 complexity. For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about diffie-hellman, but it's very similar in structure to RSA, and experts have been recommending at least 2048-bit keys for RSA for years now.

The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single AES ciphertext block with the entire plaintext datastream. We really have no way of knowing.

Have a look at the Vecrotel FAQ:

VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.

... KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS OURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.

Totally unacceptable.

If those really are "frequently-asked questions", those responses are simply arrogant. The has clearly adopted a "trust us" mentality, which just doesn't work with people who want strong security. I also don't see any FIPS certifications anywhere.

I smell snake oil.

Even better, the invulnerableit version (Nov 2005) and windowsecurity version (May 2006) actually have the tables and diagrams referred to in the text.

You do have to wonder, though. I picked up a wireless router in summer 2004, and WPA was a standard, off-the-shelf option for security. All the material I read in preparation to set up the network indicated that WPA was a better choice than WEP. The references for this article include one dated December 2004 -- several months after I did my own research. Given that WPA was already known to be more secure than WEP (which they spent quite a bit of time on), and was a standard option in consumer wireless routers, how on Earth did they miss it?

Article didn't seem to have the pictures and diagrams that the text referred to. http://www.windowsecurity.com/whitepapers/Wireless -Security-Attacks-Defenses.html is a version of the article with those pictures

As for Windows NT and 98... NT server? They are no longer supported, whether or not a firewall is running on the workstations should be less of a concern then running NT in the enviroment.

My point exactly. Many of the companies have bigger problems than worrying about personal firewalls. Ditto for Win98.

Why would running (at least 2k) servers matter with group policy? You can easiliy install the managing ADM files for managing windows firewall etc, even though they don't exist in the default Windows 2k installation.

Easily? Not really. God help you if you manage the GPO from an XP SP2 workstation, then try to get to it from a Win2K server.

"This means that if you want to use Windows 2000 and update XP systems with it, you must edit the GPO on a Windows XP system. The question does come up, what if I make a GPO on an XP machine and a GPO on a 2000 machine... how will it affect a container with mixed systems? That means an OU with mixed XP and 2000 clients, how would that work? Well, if you make the GPO on XP and apply it, the 2000 clients will ignore any of the XP-specific settings." -- http://www.windowsecurity.com/articles/Windows-XP- Group-Policy-Windows-2000-Domain-Part1.html

Yes, it seems like it is trivial -- until you actually do it and then spend the next half-hour fixing it.

Mixed environments like this are a pain and there is more work involved than "just click here".

As for Novell, I've never had to handle it myself and just go by what customers tell me. They all love NDS (and its successor) but all say the same thing "it never works 100% with a mixed Windows environment" and there is always something you have to double-check. It is, however, better than the Windows tools for managing GPO, according to everyone I've talked to.

This is brilliant. You should be working at Microsoft.

It would almost certainly break legacy applications though, which would likely mean these applications would have to be run as root / Administrator. But this simple change you proposed would destroy 90% of malware's ability to hijack other programs.

As I remember from my MCSE courses from way back (offered through a high school so they were comparatively much cheaper, so I don't regret them), Win2K did attempt a sort of registry-level security, but left it as a task to the Administrator to actually secure it. Perhaps in the future they will make a secure configuration default, but again, you have the problem of legacy applications accessing areas they shouldn't by design.

I guess we'll have to see what they do in Vista, or (more likely in my case) finally switch over to a Linux distribution for true security.

Email headers are not hard to spoof. I have several times sent myself spam about things which I would have expected myself to have known that I didn't want to buy...

So pissed I didn't check my links.

Server logs: 1, 2, 3

ISP logs: 1, 2, 3 related directly to P2P apps

System logs: A textbook on the subject you might like to read, Explanation of how to read a system log

No I don't listen to Art Bell. And there are logs on ISP servers, I know because I use them all the time to track down people trying to use my websites as spambots.

. I mean, if there ARE logs on all the ISPs then why AREN'T they being used to catch the criminals using them?

Logs are being used to catch criminals all the time, it's just a little difficult to do it over borders and shit like that. Plus there's a lttle thing called the Constitution getting in the way here in America. And it's really hard to convict someone of a crime on circumstantial evidence, which is what a server log is considered in a court of law.

. And also, what would these phantom logs contain? Every bit that has ever been downloaded?

Your ISP doesn't have to log everybit that you moved, but it does log what requests you sent where. Then you take that info and go to the IP that you requested data from and check it's logs. Guess what, a list of every request ever made by YOUR IP, pointing DIRECTLY to the material. These logs are text files, which are really really small. I have logs of every request going back to 2002 on my webservers at work. I know where they were made from and who refered them.

I can also delete these logs on anytime I want, which is how we save space. After seven years, much like tax records, we assume the log is safe to delete.

Now you think about it, if there were no such thing as a server log, how did the RIAA succefully sue people who downloaded and uploaded copyrighted files? How did they prove it? It most have been my "phantom logs". Jesus man, you have no fucking idea what your talking about, do you?

The whole point is moot anyways as this whole ignorant rant from you is in response to me proving to you the legal difference between downloading and recording a TV show. You got stuffed on that subject by everyone in here and had to argue something so you could "be right." I tried explaining it to you like an adult, and you still don't get it. I use these damn things every fucking day and yet you tell me they don't exist. I work with people who use these things in a forensic capacity yet you say they can't do it. You are a fucking idiot. And here is your proof:

Server logs: 1, 2, 3

ISP logs: 1, 2, 3 related directly to P2P apps

System logs: A textbook on the subject you might like to read, Explanation of how to read a system log

Don't bother responding, cause I'm going to ignore the shit out of your ignorant ass anyways. Douchebag.

According to an article I remember reading on WindowsSecurity.com, only 0.1% of companies are spending the appropriate budget on Intrusion Detection Systems.

According to an article I remember reading on WindowsSecurity.com, only 0.1% of companies are spending the appropriate budget on Intrusion Detection Systems.

I knew this link would come in handy someday.

Actually, a really good suggestion. I am learning stuff here. http://www.windowsecurity.com/articles/Securing_th e_Windows_2000_Registry.html

I believe the AES implementation they are using actually does encrypt the ethernet (MAC) address, unlike WEP. (See Tying It All Together in this article for corroboration of that.)

WPA2 with AES is the real deal.

I'd never buy a wooden computer.

I'd never even accept one if it was given to me.

Reminds me too much of Greeks Bearing Gifts.

(clue for the philestines: I think we have enough trouble with TROJANS already)

"...For one thing, there's no permission control"
Actually, you can set permissions for registry keys.
see here