davis_m

I was referring to calling it unauthorized access. If I do this to my own machines, which is how I wrote and tested this code, then it is entirely authorized.

I would agree that collecting session ids on systems that you do not own or have legitimate access to is almost certainly illegal.

Do you have the same feelings about the Rapid7 team? What about the guys at Tenable? Heck, the Offensive Security guys are making an entire Linux distro that is nothing more than "evil hacker tools". Surely there are countless crimes committed with their software. Do you believe that all of them are in the wrong.

I am not an exceptionally gifted programmer. This is a trivial change to the original PoC to point out an additional attack vector. Pointing out that there is more to this attack than leaked private keys is very important.

Many people have commented on the legality of using this software. I didn't think it needed pointing out that using this on servers you do not own is strictly against the law. My only reasons for writing this is to show exactly what can be done with the vulnerability and how scary it really is.

Many people have a vague understanding of how bad it is to lose a private key that is used to sign SSL traffic, but showing that one is able to hijack sessions en masse makes this vulnerability much easier to wrap our heads around.

Don't be idiots out there.

Which only applies if you were to do it to systems that you aren't authorized to use it against. Simply creating and testing the code on your own servers is far from unauthorized access. If it were anyone who had posted any PoC code would have been liable for anything that happened with their code.

I am literally just parsing the output of the original PoC.

If this were true, the Rapid7 guys would have been in jail long ago. This doesn't do anything more than the original PoC, but shows another reason for administrators to update their machines.

Seems more like "The customers we don't have want what we don't have"

The former model still had SATA cards that the backplanes connected to. I think the biggest win for them is the fact that the backplanes were one of the more error prone pieces in the box.

On a side note, each of the new SATA cards can support up to 40 drives, but there are only 45 drives in the pod, so one failing would presumably take out 22-23 drives instead of 40. Still worse than losing 5 drives though.

I'm sure that the move to direct wire was done purely because of the former backplanes being error prone, but the fact that they realize finding the parts is difficult for others and mentioning it in the blog post shows that the guys at Backblaze care about more than just making money.

Is there any trick to getting a beta to try this out?

It is very easy to only allow others to pull your repository. It then functions much the same way as an open source project where pull requests are required to get code into the main repo.

The web client is a horrible experience on the Mac. The design decisions of the group that put it together are horrible. Why in the world did they think that sticking the app to the corner of my screen is okay? Why does it follow me across every workspace? Why do they insist on interacting with the application in a different way than every other application on my machine?

If you want to make a webapp, fine, make a webapp and leave it in my browser like every other webapp. If you want to make a native client, make a native client. Don't do this half-assed crap that does nothing well.

The email I received from Cloudant:

"Hello-- Today is an exciting day for Cloudant as a business: We have agreed to be acquired by IBM [press release].

What does that mean for you as a customer? Not too much changes, actually.

The key elements of Cloudant that have helped make us successful will not change. Our team will remain intact and will continue to focus on delivering innovative products backed by our world-class operations, services and support teams. Cloudant’s product strategy and roadmap will continue as before, only with faster innovation. By tapping into IBM’s global resources, we can rapidly scale our service and introduce new products that will benefit customers.

Our position of providing a cloud-agnostic data layer will not change and remains an important differentiator for our business. We know that customers need options to prevent vendor lock-in as the cloud industry consolidates. Cloudant and IBM are the latest example of this trend, yes, but with some important distinctions.

We have a clear agreement in place to continue developing and promoting Cloudant as an open platform. Widely accepted standards like JSON and REST APIs will remain, so customers can quickly migrate onto and off of Cloudant as needs change. Cloudant’s participation in the open source community will continue, and at an accelerated pace. IBM has a track record of funding and promoting open technologies, like Linux. Over time, we’ll work toward a similar model with the open source communities close to Cloudant.

Thank you for your continued support of our business. And look for more good things from Cloudant and IBM, coming soon.

Sincerely,

Derek Schoettle CEO, Cloudant"

I still don't understand why they allow people to edit other people's comments in the first place.

Backblaze's data shows that the number of errors is largely related to the age of the drive. Because the older drives are from before Hitachi was acquired by WD, it is going to take a few more years for the brands to equalize if they do combine the manufacturing of both lines.

I would find this very useful for downloading TV episodes of currently running shows. You could have a single torrent for a TV show, and all new episodes would download automatically.

My current method involves some hacked together RSS feeds and regexs that are less than ideal.

If a user is willing to press the button, a PIN isn't going to stop them. Your app is decreasing security in favor of usability, which is not something look for when they are looking to implement two factor auth.

I think anyone who would blindly use your proprietary two factor solution that makes it easier for end users to authorize other people to log in would be silly.

A PIN would do nothing to keep a user from being tricked into authorizing an attacker's login.

In this model, all you have to do is time the authorization request appropriately. If an attacker can time their authorization at the same time that the user is logging in, a large number of users are simply going to authorize both requests thinking that it is some sort of glitch.

With the standard OTP model, a user physically can not enter their code for another user.

From your home website, it looks like you are relying on users deciding if they should authorize a request based on OS, web browser, ip address, and location.

Users are going to essentially ignore ip address. OS, web browser, and location are easy to spoof. If a half competent attacker makes a request, how is the user to know if they should authorize a request.

I understand that using OTP codes can be annoying to some users, but it is MUCH harder for a user to hand that code over to someone in order to login.

What methods are you using to make sure that an authorization comes from an authorized phone?

Are you concerned that it is a lot easier to trick users into clicking a button to authorize the login?

The same thing that prevents the merchant from charging the same card multiple times, or charging more than was agreed upon. Nothing.

Using pam_abl to disallow logging into an account that is being hit sounds like a easy way to DoS a box.

Only if the browser supports HSTS. Many do not, especially mobile browsers.

That statistic of 50% professors being adjunct is not cited, and from searching online appears to come from the SEIU, which is a group who's goal is to unionize adjunct faculty. The report it self is not available, and it has been quoted in articles as "part-time faculty held 50 percent of teaching jobs at colleges" [1] and "adjuncts held 50 percent of teaching jobs at colleges" [2]

Neither of those statements are the same as "Adjuncts now make up well over 50 percent of the faculty at colleges and universities." as stated in the article.

[1]http://www.boston.com/yourcampus/news/bentley/2013/06/as_ben...

[2] http://www.boston.com/yourcampus/news/tufts/2013/07/adjunct_...

I am unable to actually find an sort of source for the statistic that "Adjuncts now make up well over 50 percent of the faculty at colleges and universities."

It seems to go back to the SEIU, a group that is attempting to unionize adjunct positions. I have seen it quoted in a number of ways, including "50% of part time faculty at universities are adjunct." and "50% of teaching positions at universities are adjunct."

I would like to see some sort of actual report that shows the source of that. My (very limited, anecdotal) experience seems to indicate much fewer than 50% of professors are adjunct. It all depends on how you count these things.

No, I am saying there are professors receiving $200k with perks. An adjunct position isn't supposed to be a full-time long term position, so why should it be paid as such?

I feel for Ms. Vojtko's family, but I don't feel like complaining about adjunct professor salaries is being fair.

These positions are short term contract (6 months-1 year) and are not meant as long term employment. These positions are meant for people from industry to come in a teach a class on a specific topic they are experienced in. These positions are not research positions, or anything of the sort.

Many of the people in adjunct positions have a completely separate full-time jobs, or perhaps are retired. Offering them health-care seems silly, because a large number of them already receive health care.

So parading one lady who treated the position as some kind of career path as proof that professors at college's need to get paid more is silly. I understand that my professors are going to be higher paid than most (Software/Computer Engineering) but earning upwards of $200k with a great deal of perks is fairly common.

Yeah, when testing with short stings, the difference is great, but strings at the 4096 limit only vary by a couple of percent.