> incredibly dumb on the part of the malware authors. > All they really needed to do was have a known unencrypted blob that they could compare against after decrypting and completely avoid storing any hash
In this case, it's the same thing. Both are Salsa based.
In the general case, you can afford to use a stronger algorithm for a short plaintext (the hash) and a faster (weaker) algorithm for the main encryption, so using the hash is MORE secure than misusing the main encryption routine as if it were a hash.
Typically, a hash is consists of an encryption primitive repeated many times, 64 times in the case of SHA256 and MD5. So the hash should be stronger (and much slower) than a similar encryption.
My demonstration hash algorithm was intended to be:
For key X, Hash = (square root of X) + X
As mentioned above, that's easily reversible, so it's a bad hash function. Good hash functions are much more complicated and should require at least a thousand years of CPU time to reverse.
I've been doing security for 20 years, so most of my explanation is based on reading between the lines. I think it was the last link in the article mentioned the crack starts with getting the "verification hash" from the disk, or similar wording. The rest is knowing what hashes are used for and how encryption an crypto malware works in general.
If the key were infinitely long, there would be infinitely many keys that match the hash. Since the key is approximately the same length as the hash, there is approximately ONE key that matches the hash. In computer forensics, you ALWAYS work on an image of the drive, never the original, so trying a wrong key won't hurt, if there happen to be two keys which match the hash. As you mentioned, you can also test whether or not a candidate key produces reasonable output.
I just read the spec. It might be more accurate to say this API allows USB devices to offer data of their choosing to whitelisted web scripts. The USB device decides what data it gives to whom; web sites can't do anything with random USB devices that don't explicitly offer web endpoints. At the end of the day, it actually doesn't effect security in a fundamental way at all - USB devices can ALREADY send arbitrary data to web pages, just in an ad-hoc way rather than a well-defined , standardized way.
In a way, it's a lot like first- party cookies , with the data on the usb device rather than on the hard drive.
No other web site can get anything from the USB device, and the whitelisted URL can only request the specified data item.
Security considerations are of course important. At the same time, JavaScript can ALREADY read your most important USB devices - it can see your keyboard presses and mouse movements. If a USB device wants to send data to a web page, it can already declare itself to be a keyboard and start sending keypresses. (Credit card readers have done exactly this for decades, pretending to be keyboards.) This API defines a standardized way for the USB device to send data in a more secure way than by pretending to be a keyboard.
Yes, one should consider security. With this, primary the security of the USB device- it's one other way for a malicious USB device to do bad things. But USB devices can ALREADY pretend to be a keyboard, use a hotkey sequence to fire up cmd.exe, and run any commands they want. Malicious USB devices are really bad with or without this new API, so the API doesn't increase risk by much.
If you're familiar with an MD5 hash, that's what's stored on the drive. Except it's a slightly different version than MD5.
If you're NOT familiar with MD5, I'll try to explain it a bit. The malware author wanted to handle the key being entered incorrectly, to have an error message saying "that's not the correct key". Without that error message, a typo while entering the key would result in decrypting the drive incorrectly, permanently destroying the data. So the malware needed a way to determine if the key is correct or not. To determine whether or not a key (or password) is correct without storing it, programmers use something called a hash.
Here's a really bad hash algorithm, just to demo the concept: Where X is the key (a number): (square root of X) = 110
So we store the hash, 110. Someone enters 9 as the key. The malware does the math: (square root of 9) + 9 = 12 Since the hash doesn't match 110, that's the wrong key and it throws an error.
The hash function I just used is bad because based on the result, 110, you can easily figure out that the key must be 100. The malware used a better hash function, one based on something called "salsa20". However, the hash function they used wasn't very secure. You only have to try maybe a million keys before you find the right one. With CPUs that can try a million keys in just a few seconds, it's easy to find the key which matches the stored hash.
> When you have the country that describes itself as the beacon of freedom and democracy in the world...
That reminds me, I wonder if any of Obama's aides ever took him aside and explained to him that what you just said is called "American Exceptionalism". If they told him that when he denies American Exceptionalism, that terms means he's denying that the US has a responsibility to act consistent with justice and liberty, because the country was founded explicitly to advance those ideals.
I'm sure he wouldn't have denied it had he known what the term means.
There is a kernel of truth in what you say - the US should live up to a HIGHER standard. Our founding documents say this country exists for the purpose of justice, freedom, and liberty.
That said, are you thinking that Al Quaeda was following the laws of war until after 9/11, that hijacking civilian airliners and crashing them into skyscrapers is okay? To claim that Al Quaeda won't follow the laws of war because the US may not have is of course a bit silly.
Google Fiber offers free service to "affordable housing" developments, which is a government defined term, and "public housing", which means housing which subsidized by the taxpayers. Greenwich Connecticut has both.
I didn't know that the NaCl verifier had been verified. That's very interesting, thanks. In fact I still can't find a reference for that, probably just because Google searches with the word "verified" turn up so many results talking about code verified BY the verifier.
We know that C strcpy can result in overflow, as can the Caddition operator with it's own special version of overflow. But copying a string in Java or Flash can't result in overflow, right? Prove it. The specification for each is simple and clear.
You don't need to prove all of the application software, much can be gained by proving that the language or library is safe from user error (where user means application programmer). Where you DO want to prove some part of the application software to some degree, proving the library, compiler, or interpreter is a precondition.
Here's a hard problem that's very much in demand right now, that's 100% comp sci. Given that day-to-day programmers are in fact not perfect, it would be awesome for them to have provably secure libraries. Library functions that CAN'T result in a buffer overflow or underflow, for example.
You want a grander problem? How about a provably secure sandbox? We've seen how "engineered" sandboxes such as Flash, Java, and Android have worked out. Designing a sandbox that provides/emulates a basic CPU while PROVABLY not allowing access to any resource outside of the sandbox would be a comp sci project that could advance security in a huge way.
Absolutely computational theory is a different beast than most programming. HOWEVER, CS graduates don't generally work as theorists. They very often end up working as programmers, systems architects, etc. They come reasonably prepared- CS is certainly better preparation than my last two bosses had - one major in architecture and the other in electrical engineering. If we're going to teach them the fundamentals of programming and information engineering, we might include an awareness of security as part of those fundamentals.
Also, there's a lot of work to be done on the more theoretical side of security. Because programmers aren't perfect, wouldn't it be nice to have a provable sandbox, to know, based on mathematical proof, that no program run in some context X can possibly access a resource in some other context Y? How about proving that a set of library functions can't have buffer overflows, regardless of their input? Cryptology is of course all about theoretical, mathematical, "prove the computational complexity" type of thinking. It would be awesome to have an implementation of key exchange that's PROVEN correct.
>>> Define "network operating system" [six paragraphs explaining network operating systems to you.]
> To make that claim you first need to show why the entire OS built on a network stack improves the environment for a server. > Accessing a local printer via a network socket? Who gives a shit. > Instead why not compare the CUPS performance for locally attached networks when exported over a network.
Because we're not talking "performance operating system", we're defining "network operating system". A network operating system is one that's based on the network, as a precondition. When the storage is at 10.0.2.3, the CPU is 10.0.2.6, and the console is 76.212.34.11, that's probably a network system. It's probably a good match for a network operating system.
When the console is connected via USB and DVI, the drive via SATA, and it's sitting on a desk, that's probably a desktop system. A desktop operating system makes sense.
When the 4" console is glued on top of the CPU and the storage is a soldered-on 2GB chip, that's probably a mobile system. A mobile operating system would be a good match.
Paragraph four, which basically defines network operating systems (as I'm using the term), was murdered by a few typos. It should read:
Network operating systems are designed with network access being a basic assumption. They don't have network software added on in some version. They start with the assumption that most users will be accessing the system over the network. The local console may be extremely limited, because most users won't be using the local keyboard and monitor. That's because the whole point of developing network operating systems, starting with MULTICS in 1964, was that they are multi-user, with several concurrent users using them over the network. Often, primary storage and other important components are accessed over the network. With the CPU in one place, the disk somewhere else on the network, and the keyboard somewhere else, the system can't really even come into being unless the network is up and working. Network operating systems are designed for that type of system as their natural environment. Another example is that I routinely install Linux on machines thousands of miles away, without using a KVM. Networked access is the norm, of course you can easily install the OS over the network.
It's funny to me that some people delight in pointing out that Linux isn't a wonderful desktop personal computer operating system, but then get all uncomfortable with the idea that Windows IS a desktop PC OS . Personal computers revolutionized the world, and PC desktop operating systems are hugely important.
> Define Network OS
It's part definition and part heritage. I'll try to cover both, but first I'll go for a short-form, example. Unixes won't boot without their network stack. The graphical windows on the screen are a bolt-on afterthought, delivered through a SOCKET. If you want to configure printers on a Unix, you access 127.0.0.1:931 - you constantly use the network to access the local machine.
Definition wise, before defining network operating system, we should make one point about the definition of operating system, and operating system families generally. The family to which an operating system belongs isn't determined by one or two userland applications. Installing a graphical web browser on an instance of a network OS doesn't turn it into a personal computer desktop OS. (In fact, a browser is a graphical tool for accessing the NETWORK, being a network client using network applications). Likewise, deleting the browser, or the desktop calculator, from a desktop (PC) OS doesn't make the OS stop being a desktop OS. Windows is an operating system. Windows 7 Home and Windows 7 Ultimate are two PRICES, mostly for userland applications, not two operating systems.
Network are designed with network access being a basic assumption. They don't have network DLLs added in some version, they start with the assumption that most users will be accessing the system over the network. The local console may be extremely limited, because they the local keyboard and monitor isn't the standard way of using them. That's because the whole point of developing network operating systems, starting with MULTICS in 1964, was that they are multi-user, with several concurrent users using them over the network. Often, primary storage and other important components are accessed over the network.
On the other hand, PC (personal computer) operating systems generally assume a local user is the typical use case. A network isn't required or assumed, local storage is the norm.
On MULTICS it was also common to remove half of the components each night and assemble them into a second system. At night, half of the CPUs, half the storage, half the RAM, etc would be removed, a devel/test system assembled, then in the morning all of the parts would be combined again into one large computer. The computer wasn't shut down during this process - programs continued to run as CPUs were added and removed. That's one defining characteristic of an OS family related to NOS - the server operating system.
From MULTICS came UNIX, and from UNIX sprang BSD and Linux. (Linux of course re-implemented Unix, rather than copying source code files). This OS family has been based on multiple concurrent users, over the network since it began in 1965, 50 years ago. Of course with multiple concurrent users comes the need for securing one user's file and processes from access or interference from another user, so that was always built in to this OS family. Computers cost hundreds of thousands of dollars each, so multiple concurrent users was a bit important.
Teen years later, electronics had advanced enough that for just a few thousand dollars you could build an electronic word processor with 4KB of RAM and a 1 Mhz CPU. Obviously UNIX wouldn't run, with user software, in 4KB of RAM. Hell just the networking code alone was 4KB. So a couple of really smart people had a great idea. They could build a PERSONAL computer, for one user at a time, by putting together a tiny OS that would run on word processor hardware. It wouldn't need anything multiuser - no networking, no security, etc. With just one home user at a time, it didn't need enterprise grade reliability. It DID need to fit into 4KB of RAM, and boot a from a 140KB st
>I have Windows Servers up for much longer than that.
Two words: patch Tuesday. Server systems aren't systems designed to need rebooting two or three times just because it's Tuesday.
>> server OS can handle hotswap hardware. I swap drives regularly, and we've even hotswapped a CPU
> The only thing most people need to hotswap in a server are disks
As long as nothing ever goes wrong, no hardware ever fails, the system won't crash. That's typical desktop. Systems built for server use stay up as you hotswap failed parts or parts throwing warnings.
>> A server OS has mandatory access control.
> Windows has this.
No, Windows is based on discretionary access control, DAC, not MAC. DAC is the 1960s approach. Nobody uses it,but Windows also has a silly little system they call MIC. It's an even more limited version of DAC in that it's based on levels. Any program run by any higher-level user can do anything to any file.
With mandatory access control, access is predefined saying which program has which kind of access to which objects, in which contexts. Linux has a couple of options for MAC; SELinux is the default for most distributions.
I don't know what happened there. It appeared that my browser deletee what I had typed, so I typed it again. Somehow it ended up posting both copies. I'll blame it on many mobile OS.
> Yeah we could all run Windows 2008 Server and call it a desktop,
Windows IS a desktop OS, not a network OS. Notice it's not usable except by clicking desktop icons? You can certainly argue that it's a poor desktop because not many applications are been installed by default , but the operating system is desktop through and through. A server OS doesn't require rebooting every week or every month. Average uptime for my servers is probably about three years, because I physically moved them a few years ago. A server OS can handle hotswap hardware. I swap drives regularly, and we've even hotswapped a CPU. You don't reboot a server three times when > Yeah we could all run Windows 2008 Server and call it a desktop,
Windows IS a desktop OS, not a network OS. Notice it's not usable except by clicking desktop icons? You can certainly argue that it's a poor desktop because not many applications are been installed by default , but the operating system is desktop through and through.
You don't reboot a server every week or every month. A server OS can support server hardware, which includes hotswap. You damn sure don't reboot a server just because you swap out the backup drive - hotswap SAS and SATA are a bare minimum for a server OS. We've even hotswapped a CPU on a server. The server OS (Linux) didn't skip a beat, because servers support hotswap. That's hotswap PCIe, not sometimes USB works if you properly eject it first.
A server OS doesn't implement "security" by HIDING files in the GUI. A server OS has mandatory access control.
I could go on and list a dozen more things, but the bottom line is that Windows is a very successful desktop operating system. One originally developed as a user-friendly shell for Disk Operating System, so named to distinguish it from all of the others at the time, which were network operating systems.
I use 10.0.2.0/24 as my physical LAN. Which means any OTHER network gets routed to the default gateway, which is the modem.
Most people use 192.168.1.0 on the LAN side. The cable modem isn't on that network either, it's on 192.168.100.1. So the bone-stock default is the same - the modem, on the WAN side, is a different network from the LAN side. What network you use on the LAN doesn't matter, unless you were to also use 192.168.100 on the LAN.
Ps, like 3ware support, Red Hat provides actual techs. They won't read a script asking you to reboot three times, then tell you to re-install from scratch, losing all of your data.
For those unfamiliar, the previous poster may be referring to Red Hat. They provide ten-year support. Their tech support phone number is 1-888-733-4281 .
In 1998, a security- conscious person would sanitize input, and blacklist certain characters. strip_slashes(), quote_meta() and friends were best practice.
Today, there are so many well-known ways around that using different encodings and such, it's virtually impossible to do securely. Instead, today we recognize that user input is potentially malicious and treat it that way - forever. It's NEVER considered sanitized , because it never can be. That means when storing data to a database, we use bound parameters, never interpolated strings. User input can't be used for sql injection because the input isn't part of the query, it's a data parameter that the query carries. On output, encode.
In other words, the user agent SHOULD be stored as-is in the database, because it can't possibly be made clean. Just remember that and don't echo it straight to the html output. Encode it first because it's binary data of unknown origin.
Slashdot Mirror
> incredibly dumb on the part of the malware authors.
> All they really needed to do was have a known unencrypted blob that they could compare against after decrypting and completely avoid storing any hash
In this case, it's the same thing. Both are Salsa based.
In the general case, you can afford to use a stronger algorithm for a short plaintext (the hash) and a faster (weaker) algorithm for the main encryption, so using the hash is MORE secure than misusing the main encryption routine as if it were a hash.
Typically, a hash is consists of an encryption primitive repeated many times, 64 times in the case of SHA256 and MD5. So the hash should be stronger (and much slower) than a similar encryption.
> JavaScript can't be used to implement a logger.
It can already log anything to a remote server via:
XMLHttpRequest.send(logmsg)
It can already store logs locally:
Document.Cookie('logline1', logmsg);
Now, if and only if a USB device offers to store the log, JavaScript can provide for storage there.
My demonstration hash algorithm was intended to be:
For key X,
Hash = (square root of X) + X
As mentioned above, that's easily reversible, so it's a bad hash function. Good hash functions are much more complicated and should require at least a thousand years of CPU time to reverse.
I've been doing security for 20 years, so most of my explanation is based on reading between the lines. I think it was the last link in the article mentioned the crack starts with getting the "verification hash" from the disk, or similar wording. The rest is knowing what hashes are used for and how encryption an crypto malware works in general.
If the key were infinitely long, there would be infinitely many keys that match the hash. Since the key is approximately the same length as the hash, there is approximately ONE key that matches the hash. In computer forensics, you ALWAYS work on an image of the drive, never the original, so trying a wrong key won't hurt, if there happen to be two keys which match the hash. As you mentioned, you can also test whether or not a candidate key produces reasonable output.
I just read the spec. It might be more accurate to say this API allows USB devices to offer data of their choosing to whitelisted web scripts. The USB device decides what data it gives to whom; web sites can't do anything with random USB devices that don't explicitly offer web endpoints. At the end of the day, it actually doesn't effect security in a fundamental way at all - USB devices can ALREADY send arbitrary data to web pages, just in an ad-hoc way rather than a well-defined , standardized way.
In a way, it's a lot like first- party cookies , with the data on the usb device rather than on the hard drive.
The USB device defines:
https://login.ebay.com/ may ask me for "username".
No other web site can get anything from the USB device, and the whitelisted URL can only request the specified data item.
Security considerations are of course important. At the same time, JavaScript can ALREADY read your most important USB devices - it can see your keyboard presses and mouse movements. If a USB device wants to send data to a web page, it can already declare itself to be a keyboard and start sending keypresses. (Credit card readers have done exactly this for decades, pretending to be keyboards .) This API defines a standardized way for the USB device to send data in a more secure way than by pretending to be a keyboard.
Yes, one should consider security. With this, primary the security of the USB device- it's one other way for a malicious USB device to do bad things. But USB devices can ALREADY pretend to be a keyboard, use a hotkey sequence to fire up cmd.exe, and run any commands they want. Malicious USB devices are really bad with or without this new API, so the API doesn't increase risk by much.
If you're familiar with an MD5 hash, that's what's stored on the drive. Except it's a slightly different version than MD5.
If you're NOT familiar with MD5, I'll try to explain it a bit. The malware author wanted to handle the key being entered incorrectly, to have an error message saying "that's not the correct key". Without that error message, a typo while entering the key would result in decrypting the drive incorrectly, permanently destroying the data. So the malware needed a way to determine if the key is correct or not. To determine whether or not a key (or password) is correct without storing it, programmers use something called a hash.
Here's a really bad hash algorithm, just to demo the concept:
Where X is the key (a number):
(square root of X) = 110
So we store the hash, 110. Someone enters 9 as the key. The malware does the math:
(square root of 9) + 9 = 12
Since the hash doesn't match 110, that's the wrong key and it throws an error.
The hash function I just used is bad because based on the result, 110, you can easily figure out that the key must be 100. The malware used a better hash function, one based on something called "salsa20". However, the hash function they used wasn't very secure. You only have to try maybe a million keys before you find the right one. With CPUs that can try a million keys in just a few seconds, it's easy to find the key which matches the stored hash.
> When you have the country that describes itself as the beacon of freedom and democracy in the world ...
That reminds me, I wonder if any of Obama's aides ever took him aside and explained to him that what you just said is called "American Exceptionalism". If they told him that when he denies American Exceptionalism, that terms means he's denying that the US has a responsibility to act consistent with justice and liberty, because the country was founded explicitly to advance those ideals.
I'm sure he wouldn't have denied it had he known what the term means.
> What about single-family homes?
Both categories include single-family homes. "Affordable housing" more so than "public housing".
> My neighborhood has a significant number of old people with paid-off houses
Regarding the old people, Prodigy and AL don't offer similar free service, as far as I know. :)
There is a kernel of truth in what you say - the US should live up to a HIGHER standard. Our founding documents say this country exists for the purpose of justice, freedom, and liberty.
That said, are you thinking that Al Quaeda was following the laws of war until after 9/11, that hijacking civilian airliners and crashing them into skyscrapers is okay? To claim that Al Quaeda won't follow the laws of war because the US may not have is of course a bit silly.
Google Fiber offers free service to "affordable housing" developments, which is a government defined term, and "public housing", which means housing which subsidized by the taxpayers. Greenwich Connecticut has both.
I didn't know that the NaCl verifier had been verified. That's very interesting, thanks. In fact I still can't find a reference for that, probably just because Google searches with the word "verified" turn up so many results talking about code verified BY the verifier.
We know that C strcpy can result in overflow, as can the Caddition operator with it's own special version of overflow. But copying a string in Java or Flash can't result in overflow, right? Prove it. The specification for each is simple and clear.
You don't need to prove all of the application software, much can be gained by proving that the language or library is safe from user error (where user means application programmer). Where you DO want to prove some part of the application software to some degree, proving the library, compiler, or interpreter is a precondition.
Here's a hard problem that's very much in demand right now, that's 100% comp sci. Given that day-to-day programmers are in fact not perfect, it would be awesome for them to have provably secure libraries. Library functions that CAN'T result in a buffer overflow or underflow, for example.
You want a grander problem? How about a provably secure sandbox? We've seen how "engineered" sandboxes such as Flash, Java, and Android have worked out. Designing a sandbox that provides /emulates a basic CPU while PROVABLY not allowing access to any resource outside of the sandbox would be a comp sci project that could advance security in a huge way.
Absolutely computational theory is a different beast than most programming. HOWEVER, CS graduates don't generally work as theorists. They very often end up working as programmers, systems architects, etc. They come reasonably prepared- CS is certainly better preparation than my last two bosses had - one major in architecture and the other in electrical engineering. If we're going to teach them the fundamentals of programming and information engineering, we might include an awareness of security as part of those fundamentals.
Also, there's a lot of work to be done on the more theoretical side of security. Because programmers aren't perfect, wouldn't it be nice to have a provable sandbox, to know, based on mathematical proof, that no program run in some context X can possibly access a resource in some other context Y? How about proving that a set of library functions can't have buffer overflows, regardless of their input? Cryptology is of course all about theoretical, mathematical, "prove the computational complexity" type of thinking. It would be awesome to have an implementation of key exchange that's PROVEN correct.
>>> Define "network operating system"
[six paragraphs explaining network operating systems to you.]
> To make that claim you first need to show why the entire OS built on a network stack improves the environment for a server.
> Accessing a local printer via a network socket? Who gives a shit.
> Instead why not compare the CUPS performance for locally attached networks when exported over a network.
Because we're not talking "performance operating system", we're defining "network operating system". A network operating system is one that's based on the network, as a precondition. When the storage is at 10.0.2.3, the CPU is 10.0.2.6, and the console is 76.212.34.11, that's probably a network system. It's probably a good match for a network operating system.
When the console is connected via USB and DVI, the drive via SATA, and it's sitting on a desk, that's probably a desktop system. A desktop operating system makes sense.
When the 4" console is glued on top of the CPU and the storage is a soldered-on 2GB chip, that's probably a mobile system. A mobile operating system would be a good match.
Paragraph four, which basically defines network operating systems (as I'm using the term), was murdered by a few typos. It should read:
Network operating systems are designed with network access being a basic assumption. They don't have network software added on in some version. They start with the assumption that most users will be accessing the system over the network. The local console may be extremely limited, because most users won't be using the local keyboard and monitor. That's because the whole point of developing network operating systems, starting with MULTICS in 1964, was that they are multi-user, with several concurrent users using them over the network. Often, primary storage and other important components are accessed over the network. With the CPU in one place, the disk somewhere else on the network, and the keyboard somewhere else, the system can't really even come into being unless the network is up and working. Network operating systems are designed for that type of system as their natural environment. Another example is that I routinely install Linux on machines thousands of miles away, without using a KVM. Networked access is the norm, of course you can easily install the OS over the network.
It's funny to me that some people delight in pointing out that Linux isn't a wonderful desktop personal computer operating system, but then get all uncomfortable with the idea that Windows IS a desktop PC OS . Personal computers revolutionized the world, and PC desktop operating systems are hugely important.
> Define Network OS
It's part definition and part heritage. I'll try to cover both, but first I'll go for a short-form, example. Unixes won't boot without their network stack. The graphical windows on the screen are a bolt-on afterthought, delivered through a SOCKET. If you want to configure printers on a Unix, you access 127.0.0.1:931 - you constantly use the network to access the local machine.
Definition wise, before defining network operating system, we should make one point about the definition of operating system, and operating system families generally. The family to which an operating system belongs isn't determined by one or two userland applications. Installing a graphical web browser on an instance of a network OS doesn't turn it into a personal computer desktop OS. (In fact, a browser is a graphical tool for accessing the NETWORK, being a network client using network applications). Likewise, deleting the browser, or the desktop calculator, from a desktop (PC) OS doesn't make the OS stop being a desktop OS. Windows is an operating system. Windows 7 Home and Windows 7 Ultimate are two PRICES, mostly for userland applications, not two operating systems.
Network are designed with network access being a basic assumption. They don't have network DLLs added in some version, they start with the assumption that most users will be accessing the system over the network. The local console may be extremely limited, because they the local keyboard and monitor isn't the standard way of using them. That's because the whole point of developing network operating systems, starting with MULTICS in 1964, was that they are multi-user, with several concurrent users using them over the network. Often, primary storage and other important components are accessed over the network.
On the other hand, PC (personal computer) operating systems generally assume a local user is the typical use case. A network isn't required or assumed, local storage is the norm.
On MULTICS it was also common to remove half of the components each night and assemble them into a second system. At night, half of the CPUs, half the storage, half the RAM, etc would be removed, a devel/test system assembled, then in the morning all of the parts would be combined again into one large computer. The computer wasn't shut down during this process - programs continued to run as CPUs were added and removed. That's one defining characteristic of an OS family related to NOS - the server operating system.
From MULTICS came UNIX, and from UNIX sprang BSD and Linux. (Linux of course re-implemented Unix, rather than copying source code files). This OS family has been based on multiple concurrent users, over the network since it began in 1965, 50 years ago. Of course with multiple concurrent users comes the need for securing one user's file and processes from access or interference from another user, so that was always built in to this OS family. Computers cost hundreds of thousands of dollars each, so multiple concurrent users was a bit important.
Teen years later, electronics had advanced enough that for just a few thousand dollars you could build an electronic word processor with 4KB of RAM and a 1 Mhz CPU. Obviously UNIX wouldn't run, with user software, in 4KB of RAM. Hell just the networking code alone was 4KB. So a couple of really smart people had a great idea. They could build a PERSONAL computer, for one user at a time, by putting together a tiny OS that would run on word processor hardware. It wouldn't need anything multiuser - no networking, no security, etc. With just one home user at a time, it didn't need enterprise grade reliability. It DID need to fit into 4KB of RAM, and boot a from a 140KB st
>I have Windows Servers up for much longer than that.
Two words: patch Tuesday. Server systems aren't systems designed to need rebooting two or three times just because it's Tuesday.
>> server OS can handle hotswap hardware. I swap drives regularly, and we've even hotswapped a CPU
> The only thing most people need to hotswap in a server are disks
As long as nothing ever goes wrong, no hardware ever fails, the system won't crash. That's typical desktop. Systems built for server use stay up as you hotswap failed parts or parts throwing warnings.
>> A server OS has mandatory access control.
> Windows has this.
No, Windows is based on discretionary access control, DAC, not MAC. DAC is the 1960s approach. Nobody uses it ,but Windows also has a silly little system they call MIC. It's an even more limited version of DAC in that it's based on levels. Any program run by any higher-level user can do anything to any file.
With mandatory access control, access is predefined saying which program has which kind of access to which objects, in which contexts. Linux has a couple of options for MAC; SELinux is the default for most distributions.
I don't know what happened there. It appeared that my browser deletee what I had typed, so I typed it again. Somehow it ended up posting both copies. I'll blame it on many mobile OS.
> Yeah we could all run Windows 2008 Server and call it a desktop,
Windows IS a desktop OS, not a network OS. Notice it's not usable except by clicking desktop icons? You can certainly argue that it's a poor desktop because not many applications are been installed by default , but the operating system is desktop through and through. A server OS doesn't require rebooting every week or every month. Average uptime for my servers is probably about three years, because I physically moved them a few years ago. A server OS can handle hotswap hardware. I swap drives regularly, and we've even hotswapped a CPU. You don't reboot a server three times when > Yeah we could all run Windows 2008 Server and call it a desktop,
Windows IS a desktop OS, not a network OS. Notice it's not usable except by clicking desktop icons? You can certainly argue that it's a poor desktop because not many applications are been installed by default , but the operating system is desktop through and through.
You don't reboot a server every week or every month. A server OS can support server hardware, which includes hotswap. You damn sure don't reboot a server just because you swap out the backup drive - hotswap SAS and SATA are a bare minimum for a server OS. We've even hotswapped a CPU on a server. The server OS (Linux) didn't skip a beat, because servers support hotswap. That's hotswap PCIe, not sometimes USB works if you properly eject it first.
A server OS doesn't implement "security" by HIDING files in the GUI. A server OS has mandatory access control.
I could go on and list a dozen more things, but the bottom line is that Windows is a very successful desktop operating system. One originally developed as a user-friendly shell for Disk Operating System, so named to distinguish it from all of the others at the time, which were network operating systems.
I use 10.0.2.0/24 as my physical LAN. Which means any OTHER network gets routed to the default gateway, which is the modem.
Most people use 192.168.1.0 on the LAN side. The cable modem isn't on that network either, it's on 192.168.100.1. So the bone-stock default is the same - the modem, on the WAN side, is a different network from the LAN side. What network you use on the LAN doesn't matter, unless you were to also use 192.168.100 on the LAN.
Ps, like 3ware support, Red Hat provides actual techs. They won't read a script asking you to reboot three times, then tell you to re-install from scratch, losing all of your data.
For those unfamiliar, the previous poster may be referring to Red Hat. They provide ten-year support. Their tech support phone number is 1-888-733-4281 .
If she's going off into UFOs and magic pyramids now, I'd LOVE to hear her debate Ron Paul, perhaps in Haight Ashbury.
In 1998, a security- conscious person would sanitize input, and blacklist certain characters. strip_slashes(), quote_meta() and friends were best practice.
Today, there are so many well-known ways around that using different encodings and such, it's virtually impossible to do securely. Instead, today we recognize that user input is potentially malicious and treat it that way - forever. It's NEVER considered sanitized , because it never can be. That means when storing data to a database, we use bound parameters, never interpolated strings. User input can't be used for sql injection because the input isn't part of the query, it's a data parameter that the query carries. On output, encode.
In other words, the user agent SHOULD be stored as-is in the database, because it can't possibly be made clean. Just remember that and don't echo it straight to the html output. Encode it first because it's binary data of unknown origin.