The password is sent over the encrypted channel that ssh sets up so it's never sent in clear text as in say telnet. Then of course no one is using passwords since everyone should be using public keys instead anyways.
A fresh install of SSH will not just let anyone in, by default you would need a password which with SSH is never sent on the wire. Curious though who sets up something like SSH remotely, how do you connect to that machine before ssh is set up?
Not with SSH unless you set the machines password to something that is suspectible to online brute forcing instead of using public keys. And even then it's highliy unlikely that some one manages to brute force your stupid password and have time to add an entry in.ssh/authorized_keys before you had time to scp over the new keys and changed the ssh config to only allow public keys. AND if you for some strange reason do this over the Internet.
If so then you have a faulty implementation and need to change it. If you store user passwords in any other way than a salt+hash then your entire userdatabase will be made public if compromised. Services like Keepass is different since each account is secured with the users master password which is not stored in the database. Databas connections inside your infrastructure should not pass along the end users password, ever.
Yes a reset link via mail is also bad, but sendinging the passowrord via mail indicates that the site does not use hashing and is storing all customers password in clear text in their databases.
According to what we know about TAO they use zero day exploits so it doesn't look like hidden hack doors in closed source software/hardware. That PPTP is insecure has been known since at least 1998: https://www.schneier.com/pptp.... That Microsoft still promotes it is beyond me.
So you experienced both and measured your bone density after each and determined that the physical activity from farming gave you denser bones than hunting animals with say a spear. Ok it was my bad that I wrote "easier on the body" when I really meant that farming puts less strain on the body of the type that promotes bone density than the type of strain that you get from being a hunter/&gathered 12000 years ago. It has nothing to do with which is harder or easier.
You still don't get it. Nobody is saying that farming is not hard work or that it's even less hard work than the hunter/gatherer. Bone gets more dense from specific physical activity and not from all, for example running (which hunters do more than farmers) gives denser bone than walking (which farmers do more) and that is even if you walk for hours upon hours carrying heavy equipment vs running just a few hours.
What you also obviously miss completely is that it's a well established fact that the bones got less dense when man begun to farm those 12000 years ago, it's measured objective facts, not just logical deductions.
To make another analogy, if you weight train in a way that exposes your bones with compression power like squats and deadlifts then you also get denser bone than the pecs and biceps boy next to you that performed two bazillion sets to failure and thus exercises a hell of a lot more than you did.
What you fail to comprehend is that they are claiming that the farming was easier on the body than the lifestyle it replaced. It does not say that farming was easy, just that it was easier.
Since most orders are probably faxed or mailed in via some simple order sheet you have your simple protocol right there. If it's a complicated order then you could have a human operator manually enter it since that should be the rare exception.
A really secure air gap that would work with continous data streams should be built somewhat like this.
1. Define a simple protocol for the instructions. In the case of this steel mill it should be "produce x amount of class y steel". Thus there is limited ways of compromising the system via the protocol since there is no detailed instructions to fuck up the mill as in the article.
2. Air gap it by having the computer connected to the internet print out the order to paper. The the operator moves that paper to the production machine where it is scanned and ocr:ed
Yes it sais so and links straight to the ppapi code used in chrome which is fully open source: https://src.chromium.org/viewv... . Hell even the chrome repository for ppapi is full of examle code if you want to write your own plugins.
It's so secret that they have their own Google Code page for it over at https://code.google.com/p/ppap... with full source available for download including SDKs for plugin developers.
Here in Sweden we have different papers for each party, that is instead of crossing of a name you put a whole paper for party x into an envelope. Pro is that this makes the counting much easier and also is not complicated for the voter. Con is that it's very expensive for a new/small party to print and distribute papers to all voting places (if you get over 1% in an election then the state will pay and manage the distribution). You can also write the party name on a black piece of paper if you want to (or if the party you want to vote for doesn't have papers in your voting place) which of course negates the pro but it's rare enough to not make a real impact.
If there's a yes/no vote done then each such vote gets their own envelope and there is a yes or no paper to choose from, so no crossing their either.
Probably driven by the media since they want a result as quickly as possible so they can sell more tv-time. I have no idea how the presidential election works in the US but I assume here that the president elect doesn't take over directly, it probably takes some months before he/she can take office anyways so time should not be an issue for the election in it self. And also since the result is to last for four years, having a result in seconds seams quite useless.
No it doesnt. There is a "show the system log as a http service" daemon that is bundled with systemd, it's not running unless you manually enable it and it's not part of the systemd binary that handles init. So still not an example of a non Unix thing.
If all upstream packages already have sysvinit scripts then what is your problem with the GR? It's only about the situation where upstream only supplies a systemd unit file.
In which distant world is "tmpfiles-setup-dev" a nondescript name? Is really that hard to kind of understand that it creates temporary nodes in/dev ?
How to tell what is going to execute when my machine boots: "systemctl" or "systemctl list-unit-files" depending upon how you want to format that list.
Which once again shows that you do not know how systemd works. Why would it run ls, cat and grep as deamons and why once again do you think that systemd would "do them" when it would be separate binaries if the systemd developers decided to replace them. Are you also mad that GNU replaced them from the old Unix variants?
Changes to/etc/resolv.conf are usable directly regardless if you use resolvconf or not. If you are using the Ubuntu Desktop edition however this file will be overwritten by resolvconf on the next reboot, I however was under the impression that the parent where talking about the server edition and there this file survives a reboot unless you use dhcp.
Slashdot Mirror
The password is sent over the encrypted channel that ssh sets up so it's never sent in clear text as in say telnet. Then of course no one is using passwords since everyone should be using public keys instead anyways.
A fresh install of SSH will not just let anyone in, by default you would need a password which with SSH is never sent on the wire. Curious though who sets up something like SSH remotely, how do you connect to that machine before ssh is set up?
Not with SSH unless you set the machines password to something that is suspectible to online brute forcing instead of using public keys. And even then it's highliy unlikely that some one manages to brute force your stupid password and have time to add an entry in .ssh/authorized_keys before you had time to scp over the new keys and changed the ssh config to only allow public keys. AND if you for some strange reason do this over the Internet.
If so then you have a faulty implementation and need to change it. If you store user passwords in any other way than a salt+hash then your entire userdatabase will be made public if compromised. Services like Keepass is different since each account is secured with the users master password which is not stored in the database. Databas connections inside your infrastructure should not pass along the end users password, ever.
Yes a reset link via mail is also bad, but sendinging the passowrord via mail indicates that the site does not use hashing and is storing all customers password in clear text in their databases.
Doesn't sound like it though. There is no window of opportunity with SSH even with a new install.
According to what we know about TAO they use zero day exploits so it doesn't look like hidden hack doors in closed source software/hardware. That PPTP is insecure has been known since at least 1998: https://www.schneier.com/pptp.... That Microsoft still promotes it is beyond me.
So you experienced both and measured your bone density after each and determined that the physical activity from farming gave you denser bones than hunting animals with say a spear. Ok it was my bad that I wrote "easier on the body" when I really meant that farming puts less strain on the body of the type that promotes bone density than the type of strain that you get from being a hunter/&gathered 12000 years ago. It has nothing to do with which is harder or easier.
You still don't get it. Nobody is saying that farming is not hard work or that it's even less hard work than the hunter/gatherer. Bone gets more dense from specific physical activity and not from all, for example running (which hunters do more than farmers) gives denser bone than walking (which farmers do more) and that is even if you walk for hours upon hours carrying heavy equipment vs running just a few hours.
What you also obviously miss completely is that it's a well established fact that the bones got less dense when man begun to farm those 12000 years ago, it's measured objective facts, not just logical deductions.
To make another analogy, if you weight train in a way that exposes your bones with compression power like squats and deadlifts then you also get denser bone than the pecs and biceps boy next to you that performed two bazillion sets to failure and thus exercises a hell of a lot more than you did.
Kim is afaik found of Hollywood movies so he probably thought that section 121 sounded cool.
What you fail to comprehend is that they are claiming that the farming was easier on the body than the lifestyle it replaced. It does not say that farming was easy, just that it was easier.
Since most orders are probably faxed or mailed in via some simple order sheet you have your simple protocol right there. If it's a complicated order then you could have a human operator manually enter it since that should be the rare exception.
A really secure air gap that would work with continous data streams should be built somewhat like this. 1. Define a simple protocol for the instructions. In the case of this steel mill it should be "produce x amount of class y steel". Thus there is limited ways of compromising the system via the protocol since there is no detailed instructions to fuck up the mill as in the article. 2. Air gap it by having the computer connected to the internet print out the order to paper. The the operator moves that paper to the production machine where it is scanned and ocr:ed
Yes it sais so and links straight to the ppapi code used in chrome which is fully open source: https://src.chromium.org/viewv... . Hell even the chrome repository for ppapi is full of examle code if you want to write your own plugins.
It's so secret that they have their own Google Code page for it over at https://code.google.com/p/ppap... with full source available for download including SDKs for plugin developers.
Here in Sweden we have different papers for each party, that is instead of crossing of a name you put a whole paper for party x into an envelope. Pro is that this makes the counting much easier and also is not complicated for the voter. Con is that it's very expensive for a new/small party to print and distribute papers to all voting places (if you get over 1% in an election then the state will pay and manage the distribution). You can also write the party name on a black piece of paper if you want to (or if the party you want to vote for doesn't have papers in your voting place) which of course negates the pro but it's rare enough to not make a real impact.
If there's a yes/no vote done then each such vote gets their own envelope and there is a yes or no paper to choose from, so no crossing their either.
Probably driven by the media since they want a result as quickly as possible so they can sell more tv-time. I have no idea how the presidential election works in the US but I assume here that the president elect doesn't take over directly, it probably takes some months before he/she can take office anyways so time should not be an issue for the election in it self. And also since the result is to last for four years, having a result in seconds seams quite useless.
How, especially since systemd (the systemd) contains of a lot of separate binaries that actually does one thing?
In other words, you have no capability to answer it since you really don't know how systemd works or what the Unix way is.
No it doesnt. There is a "show the system log as a http service" daemon that is bundled with systemd, it's not running unless you manually enable it and it's not part of the systemd binary that handles init. So still not an example of a non Unix thing.
If all upstream packages already have sysvinit scripts then what is your problem with the GR? It's only about the situation where upstream only supplies a systemd unit file.
In which distant world is "tmpfiles-setup-dev" a nondescript name? Is really that hard to kind of understand that it creates temporary nodes in /dev ?
How to tell what is going to execute when my machine boots: "systemctl" or "systemctl list-unit-files" depending upon how you want to format that list.
Which once again shows that you do not know how systemd works. Why would it run ls, cat and grep as deamons and why once again do you think that systemd would "do them" when it would be separate binaries if the systemd developers decided to replace them. Are you also mad that GNU replaced them from the old Unix variants?
Changes to /etc/resolv.conf are usable directly regardless if you use resolvconf or not. If you are using the Ubuntu Desktop edition however this file will be overwritten by resolvconf on the next reboot, I however was under the impression that the parent where talking about the server edition and there this file survives a reboot unless you use dhcp.
Of course, but that is not misusing the API. That is not using the API at all!