Forgot your password?
typodupeerror

+ - Preventing the next Heartbleed->

Submitted by Anonymous Coward
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."

Link to Original Source

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

by DeFender1031 (#43261037) Attached to: A Truckload of OAuth Issues That Would Make Any Author Quit
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

by DeFender1031 (#43260481) Attached to: A Truckload of OAuth Issues That Would Make Any Author Quit
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

by DeFender1031 (#43260425) Attached to: A Truckload of OAuth Issues That Would Make Any Author Quit
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

by DeFender1031 (#43252687) Attached to: A Truckload of OAuth Issues That Would Make Any Author Quit

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

by DeFender1031 (#43247473) Attached to: A Truckload of OAuth Issues That Would Make Any Author Quit
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.
Security

A Truckload of OAuth Issues That Would Make Any Author Quit 86

Posted by Soulskill
from the tell-us-what-you-really-think dept.
New submitter 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 departure."

Comment: Re:Really? (Score 1) 5

by DeFender1031 (#43241709) Attached to: Truckload of OAuth issues that would make any author quit
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.

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

Submitted by DeFender1031
DeFender1031 (1107097) 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."

Link to Original Source

+ - Why is anyone using OAuth 2.0?->

Submitted by
insane_coder
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?"

Link to Original Source
Encryption

+ - HTTPS encryption is too little too late->

Submitted by DeFender1031
DeFender1031 (1107097) 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."
Link to Original Source
The Internet

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

Submitted by DeFender1031
DeFender1031 (1107097) 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."
Link to Original Source

Federal grants are offered for... research into the recreation potential of interplanetary space travel for the culturally disadvantaged.

Working...