I agree that binary logs is not something that I fancy either. I do however understand why he went that way since he want's to enable meta-data to the logging and also I must say that the log search in RHEL7 is lightning fast compared with grep and that it's nice to issue a "journalctl " and get all the syslog aswell as all the stderr and stdout from combined in one place.

Actually that would have been a great thing considering how horrible the EventLog in Windows are. Something like Journald would be heaven in comparison. And the people who compares the two have obviously never programmed against either.

The thing is that they cannot beat it with facts because the vast majority of these people wouldn't know systemd even if it hit them on the head. I bet a large percentage of them also isn't even Linux-users to begin with.

+1

They would need that anyway since each new ip would add another row so it's probably more that they wrote a single image to all devices instead of autogenerating a new ssh key upon first boot.

They probably will but ssh will force you to manually remove the key from the known_hosts file if the key doesn't match, atleast openssh does that.

No they cannot, they can pretend to be the device to some user though without ssh complaining that the key is wrong. If they use the same ip and if they somehow can get between the user and his router.

You seam to talk about something complete different from what the article is about. This is about a web store storing end users passwords in clear text in their database, not your internal system for employees or what ever. For a web store there is no reason what so ever to use the customer provided password for anything other than authenticating the user for the web service, all other access deeper in the system should use credentials set up between these services.

And even for you set up there is no reason that some deep back end have to use the same password for user X than user X typed in when accessing the web service, if you must need per user passwords inside your system then let the system auto generated credentials upon account creation for b2b authentication.

Yes failing to properly validate that first warning is one really nasty way to open up for a MITM. Which is why when I built a competitor to Amazon EC2 I made the newly started instance to upload the ssh public key to the meta-server so customers could verify that the warning message matched what they could pull from the web service (always curious why Amazon never thought about that) since one doesn't have physical access to the server when running in "the cloud".

Didn't stop Snowden though :)

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.