Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Submission + - Preventing the next Heartbleed (

An anonymous reader writes: Developers are now devising techniques to prevent attacks like Heartbleed which expolit unrestricted access to private key in memory. Using these techniques will prevent buffer overflows and other coding mistakes result in similar catastrophies.

One stunnel-like server is already employing this technique. It remains to be seen when Apache, OpenSSH, and other important server software will follow.

Comment Re:Native apps == insecure (Score 1) 86

Exactly. And the people commenting that "you should never have a hacked browser" don't get that it's referring to native apps which embed a browser to mislead you rather than, say, a spyware-infested version of firefox. Of course you shouldn't have the latter, but for the former, anyone can make an app that imitates anything.

Comment Re:totally secure == powered off (Score 1) 86

True that's exactly what it is but with a lot of cruft surrounding it as well. It requires a web browser to facilitate the connection, rather than the user just copying a password to wherever it's needed, it requires that the third-party application which wants to authenticate needs its own domain and its own server, instead of just being able to be a standalone application which can authenticate directly. Because of this, it's just a mess of a system. What the author is suggesting is to leave the part of it that's based on a solid security foundation intact, (the part that says "separate keys for each application with limited access") but remove all of the insanity around it that adds no extra security and just serves to confuse the issue and limit its usability.

Comment Re:Not complex; not broken; not meant for enterpri (Score 1) 86

If people were only using OAuth for web-to-web communication, I don't think those issues would have been raised. But many of the big players have their "API"s based on it. Take a look at this thread on citrix's development site for example. Here, there's a service which is hardly web-based, pretty much the only thing web-based about it is that you join meetings by browsing to a URL, and yet the only authentication model they provide for their "API" is OAuth. This is wrong. It's not what OAuth was designed for. And yet it's what's being used. If people would stick to its intended purpose when using it, there would be no problem, but this is hardly the case.

Comment Re:totally secure == powered off (Score 2) 86

Again, you miss the point. The point isn't separate accounts. The point is, you have a user account, say "JoeCool", and a password, say "12345". Your system allows Joe, when logged in under that password, to create a secondary password, 67890 which, when logged in with, only allows limited access. Joe can then give "67890" as a password a third-party application, which will then have only limited access. If the application misbehaves, Joe can remove the "67890" password, thus locking out the malicious application while keeping his primary password secure, along with any other secondary passwords he's generated for other applications. That's the system being described and that's a system which would avoid a heck of a lot of headache.

And I'd appreciate not being called names by someone who hasn't even taken the time to understand what's being said.

Comment Re:totally secure == powered off (Score 3) 86

You miss the point. He says to have the user create separate passwords from the primary one, with restricted permissions, and give a different managed password to each application. That way, if the application misbehaves, the user themselves can remove that password without having to affect anything else.

Comment Re:Really? (Score 1) 5

I think some of what you say is definitely true. Certainly the part about how it will be difficult for the secretary to do stuff for the boss and about repelling third party developers have less to do with his departure, less to do with the "web people", but I think that the parts about the insecurity and non-interoperability hit the nail on the head in terms of his reasons. I also think that the main point of this article is that the overall result of OAuth is a system that accomplishes none of the objectives laid out from either side, and I think that this is what he saw and why he left. He practically said so himself.

as the work was winding down, I’ve found myself reflecting more and more on what we actually accomplished. At the end, I reached the conclusion that OAuth 2.0 is a bad protocol.

To me, at least, this says he realized that they accomplished nothing, and had finally reached the point where he could no longer continue accomplishing nothing and call it progress.

Submission + - Truckload of OAuth issues that would make any author quit ( 5

DeFender1031 writes: Several months ago, when Eran Hammer ragequit the OAuth project, many people thought he was simply being overly dramatic, given that he gave only vague indications of what went wrong.

Since then, and despite that, many companies have been switching to OAuth, citing it as a "superior form of secure authentication" but a fresh and objective look at the protocol highlights the significant design flaws in the system and sheds some light on what might have led to its creator's breakdown.

Submission + - Why is anyone using OAuth 2.0? (

insane_coder writes: "The general consensus till now has been that OAuth 2.0 was an overly complicated and misdesigned framework resulting from an "unbridgeable conflict between the web and the enterprise worlds", where enterprise developers designed the framework completely contrary to the needs of the general web population.

New analysis demonstrates that the design of OAuth 2.0 runs completely counter to the needs of the enterprise market as well.

So if OAuth 2.0 isn't good for the web nor the enterprise, so who is it good for? And why is service after service switching to it, offering a confusing non-protocol, and crippling their capabilities?"


Submission + - HTTPS encryption is too little too late (

DeFender1031 writes: So it's time to pay the bills. You go to your bank's website to transfer some money, you log in, and your account information is completely secure because the bank's servers establish an HTTPS connection with your browser, right? WRONG! This article describes in plain english how a man-in-the-middle can be performed prior to an HTTPS handshake, neutralizing any security precautions that might have been in place. The attack described here can be extended to any protocol where the server specifies whether to use a secure or insecure mode.
The Internet

Submission + - Is HTTPTorrent the next-gen for web browsing? ( 2

DeFender1031 writes: We're all aware of BitTorrent and how it works. This proposal suggests that some of the concepts of BitTorrent can be applied to run-of-the-mill web browsing to lighten server load and distribute downloads to browsers which have already cached the same site. While it's not an official RFC, the idea certainly has promise, and if implemented, could help speed up download times, but more importantly, it could help small (or even large) websites save bandwidth, and as we all know, bandwidth is money.

Comment A good point (Score 2, Funny) 1

I had actually been been noticing recently the INadequacies of so-called "adequate" free software. Little things mostly, programs lacking certain features that their nonfree alternatives have, things of that nature, but it's really the little things much more than the big things that will draw users into the market and keep them there. It is as plain as day that merely "adequate" is by no means good enough to attract the average Joes and Janes out there en masse, we need software that is as good as or BETTER than the non-free competition. I especially liked the concerns about the games market, there really is no contest. When it comes to games, linux outright sucks, as said, due to the poor quality of sound and video. As for X... A wise man once said "XWindows is the defacto substandard". We need a replacement for decades-old shoddy software, we need to get our heads on straight and do things right, but most of all, we need to stop denying that Linux has these issues and address them head-on. Linux, and the free software community in general, have to be proactive in developing tools for the average user, rather than reactive in combating nonfree software. There's no reason a bunch of basement-nerds and 10 pounds of beard with a man attached can't develop a better product than a bunch of sissy, cubicle men and their high-paying jobs... We basement-nerds are the better programmers and we know it! Let's take back what's rightfully ours.

Slashdot Top Deals

The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin