Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:New version! (Score 1) 261

by F.Ultra (#49114743) Attached to: Linux Kernel Switching To Linux v4.0, Coming With Many New Addons

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.

Comment: Re:This is not a SSL matter (Score 1) 141

by F.Ultra (#48708837) Attached to: Ask Slashdot: Dealing With Companies With Poor SSL Practices?

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.

Comment: Re:Anyone can intercept SSH some of the time (Score 1) 278

by F.Ultra (#48693185) Attached to: Snowden Documents Show How Well NSA Codebreakers Can Pry
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".

Comment: Re:Anyone can intercept SSH some of the time (Score 1) 278

by F.Ultra (#48688155) Attached to: Snowden Documents Show How Well NSA Codebreakers Can Pry
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.

Thus spake the master programmer: "Time for you to leave." -- Geoffrey James, "The Tao of Programming"

Working...