Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by janrinok on Thursday April 10 2014, @09:45PM   Printer-friendly
from the security-is-important dept.

After reporting the problems with OpenSSL, which has been nicknamed 'HeartBleed', 2 contributors have forward articles on why you should change your passwords.

Heartbleed, and why you should change your password

I always believed Mojang would keep my details safe, now I realise they are not in control of their own data. Mojang/Minecraft passwords should be changed immediately

Heartbleed Bug: Change All Your Passwords

The fallout from the Heartbleed bug is hitting the mainstream. The BBC has an article headlined "Public urged to reset all passwords".

Bruce Schneier calls it "catastrophic", giving this advice to sysadmins: "After you patch your systems, you have to get a new public/private key pair, update your SSL certificate, and then change every password that could potentially be affected." He also links to a webpage that will let you test servers for the bug, and an article on Ars Technica discussing the bug.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Interesting) by jcross on Thursday April 10 2014, @10:53PM

    by jcross (4009) on Thursday April 10 2014, @10:53PM (#29753)

    Yeah, I've been dealing with the fallout all day, getting new certs pushed out to a whole bunch of servers. I think patching the flaw yesterday was actually the easier part, and I can imagine how hard it must be for bigger companies that are not so big as to have great server admin systems. Along the way I have definitely been underwhelmed with the quality of some of the software that we rely on for essential crypto and other services. I don't mean this as a slight against the openssl developers, but the kind of methods we use to develop complex UI-type applications surprisingly seem to be years, if not decades ahead of the methods used to develop software like openssl. The TLS heartbeat takes IIRC 2 or 3 pieces of user input, and I think anyone doing a decent job of test-driven development would have written some test cases with out-of-bounds values for those. Why are these crypto libraries not backed up with comprehensive test suites? It's not as if they're doing something like a GUI that's hard to write tests against.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   2  
  • (Score: 3, Interesting) by kevinl on Thursday April 10 2014, @11:16PM

    by kevinl (3951) on Thursday April 10 2014, @11:16PM (#29764)

    The D language makes it so easy to do unit tests that I am finding myself writing them all the time. It's a different mentality, but I have so much more confidence that my code is doing the right thing now. I actually ported some C code over to D, wrote the unit tests to cover the cases provided in the documentation (it was Kermit protocol), and found bugs in my C code I had never seen before. Now both codebases are in much better shape.

  • (Score: 4, Informative) by NCommander on Friday April 11 2014, @01:23AM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Friday April 11 2014, @01:23AM (#29793) Homepage Journal

    Not arguing against a strong test suite, but the design of OpenSSL's malloc() replacement is what prevented anything like StackProtector from finding and detecting the bug. Had OpenSSL been using normal malloc()/free() this would have been discovered eons ago (Ubuntu ships with -fstack-protector enabled by default, and glibc has a lot of detection code for things like this). In this case, the only way to have caught it is to manually have checked all the TLS output issued by hand and see if it was there.

    --
    Still always moving