Hot answers tagged oauth
23
I like the idea, but I too have many questions left open. Please do not see this as any form of bashing, because I wrote it trying to apply my authentication experience to this new scheme.
I am concerned about (in no particular order) :
Unauthorized use of the private key
Rich client support (Outlook, Notes, etc.)
Using from multiple computers
Private ...
15
I guess there is no really good solution for everday websites (e. g. not high profile sites such as banks for which users accept and economic allows a two factor authentication). One can only pick a solution which as little negative impact as possible.
Unfortunately people are not good at remembering a huge number of passwords. This results in either them ...
13
The benefits of systems like OAuth are:
there are fewer databases in the world storing a user's login credentials. Considering a service like Twitter, this means that your username and password is known only to Twitter and not to Favstar, Amazon, LinkedIn, New York Times and all of the other applications that build on top of the service.
as @Rory says, the ...
12
From a security perspective, having a tried and tested mechanism is almost always better than rolling your own. Implementation errors are one of the most common ways a good security concept gets broken.
From a usability perspective I slightly prefer oauth, it is just easy to use, so for your end users that is a huge benefit. An average non-technical user is ...
10
Without a specific scenario and threat model in mind it is hard to answer your question.
But one clear win is the classic OAuth use case. It turns out users are amazingly willing to give one web site their password for another web site, e.g. their Google password to a social networking site like Shelfari. And as Kalsey notes, they were sometimes horribly ...
10
The OAuth RFC states:
OAuth uses tokens to represent the authorization granted to the
client by the resource owner. Typically, token credentials are
issued by the server at the resource owner's request, after
authenticating the resource owner's identity (usually using a
username and password).
There are many ways in which a ...
9
Stack exchange also has a detailed comparison of BrowserId and WebID. As argued there BrowserId is very close to WebID (a W3C Incubator Group at the W3C).
Here are some points that need to be made in defence of both protocols usually as they are very different from how public key cryptography is usually done.
Unauthorized script use of key. Agree that ...
8
You are correct. App secret should be secret and should not be easily obtained by reverse engineering your client code.
Facebook uses OAuth so everything I say here also applies to all the applications that use OAuth to authorize and authenticate. The app secret authenticates your client to facebook. Just like a username/password authenticates a user to a ...
7
PCI DSS v2, Requirement 7: "Implement Strong Access Control Measures" is the pertinent section. This section details access control primarily for non-consumers that will be accessing cardholder data for business purposes, though there are a couple requirements that seem applicable to consumers as well as non-consumers:
8.1 Assign all users a unique ID ...
7
I haven't found a way to comment on the accepted answer, so I'm submitting a response to those six points as a new answer. Sorry.
1. Unauthorized use of the private key
In the case of the Javascript BrowserID implementation, the private key is stored in local storage under the login.persona.org domain. So a rogue script would have to be hosted on that ...
7
Rather than logging in to accounts they control, I expect voter fraud would be done by clickjacking or CSRF, harnessing the social viral power of Facebook to attract unwitting accomplices.
With the prevalence lately of images on Facebook that claim that you can obtain a PS4 simply by "liking" and "sharing" an image and the sheer numbers of people who do so, ...
6
One more protocol to add to the list: WebID : http://webid.info/
One disadvantage of BrowserID in its current form compared to /some/ of the alternatives is that anything beyond the core functionality is difficult: further discovery of information requires other protocols such as WebFinger, whereas e.g. an OpenID URL can provide links.
I'm hoping the ...
6
Wrote this about federated ID.
Basically you are talking about the centralized risk problem or keys to the kingdom. This also applies to password managers, but securing a small number of identity and authentication systems is a lot easier and more effective than having hundreds of weak passwords (or the same weak password a hundred times). Open-ID providers ...
6
State Parameter
The scope parameter is not used to secure the authentication request against CSRF attacks (see below). But there is another parameter called "state", which matches your description.
[Asking the user]
This step cannot be skipped.
I am afraid, this assumption is not correct. It is very common, that the user is only asked for permission, ...
6
This does depend on your situation, but the short answer is don't re-invent the wheel if you don't have to.
If you can take advantage of OAuth/OpenID (stackoverflow does) then you probably should. This can me more for connivence then security, sites will offer OpenID but allow you to create a login if you don't already have one (so as to cover all bases). ...
6
There is absolutely nothing in the OpenID/OAuth authentication methods that guarantees an individual signing-in through them is indeed a unique user. OpenID provides a bit more data in a form of a certificate (user name, email address, and notary) than OAuth's valet key authentication, but that alone isn't enough to prevent voting fraud. Using the word fraud ...
5
From having conducted many an IT audit over the last ten years or so, I would say my biggest worry would be gaining assurance that this third party authentication mechanism works as it should. An auditor who puts their neck on the line and green-lights this is in a very sticky position if something happens at the facebook/twitter end of things (they are ...
4
Unlike the resource owner credentials,
tokens can be issued with a restricted scope and limited lifetime,
and revoked independently.
from http://tools.ietf.org/html/rfc5849
I guess the RFC has also example, but I did browse it entirely. The oauth site also feature some code, maybe it can help you, http://oauth.net/code/
4
Having 1 password stored in 1000 servers is less secure than 1 password stored in 1 server which authenticates 999 servers is less secure than 1000 password for 1000 servers.
However the latter is impractical, people aren't capable of remembering 1000 password for 1000 servers, the only way they do that is to use password managers. And where does password ...
4
For more extensive information on BrowserId/Persona, I eventually found what Daniel contributed to the related Q&A on BrowserId/Persona and WebID. (I tried to convince him to post here, but he suggested I do so.)
Security, Privacy and Usability Requirements for Federated Identity by Michael Hackett and Kirstie Hawkey provides a comparison between ...
3
Assuming all your accounts are stored in Active Directory, and only AD, and you will not accept any account registered at an external provider, it's hard to see additional benefit of simply using OAuth solely as the protocol to authenticate* users registered on your AD.
OAuth has a different use-case, it is designed to fit for federation scenarios:
...
3
The right answer will clearly depend on your application.
For example, you've listed:
Option for "difficult" sign in process to improve security (Verisign), also see this related question
Using a provider like this would be a terrible choice for a site with low login security requirements and a strong desire for low barriers to entry in order to gain ...
3
It's a good to have option for the end-users, although the protocol does not mandate this possibility. Imagine the following scenario:
The end-user starts to use an application that wants to access his google account data. So the end-user is redirected to google to approve the request. Once he approves the request, google issues access token to the third ...
3
In the case of Facebook — I don’t know about other OAuth-enabled sites — there is a possibility to use the anonymous aka application access token. It’s a token created by concatenating appId with appSecret, for instance 504216299598238|59d273f6dddb0a2f72e727132f4a74a4.
One could obtain this access token from the mobile app source and make authenticated ...
3
In that case -
Client credentials would need to be sent with every request to every server-side app/system that can present resources.
There would be no expiry and no scope limitation on any specific session.
It would be just like legacy basic auth, with all its drawbacks and benefits (simplicity)
In the OAuth client credentials flow, 'client' refers to ...
3
So typically is is exactly the sort of problem that OAuth was designed to avoid, not create.
You, as a resource provider, have created a system that you have decided to protect with OAuth, and a WordPress plugin that acts as a client to your system.
Bob, who has a WordPress site and who would like to use your system, installs the plugin into his ...
3
The client is a network concept: the data is transported between two machines, the server and the client. The client is the one who initiates the conversation; the server is the one who is sitting all day, waiting for clients to connect.
The user is the biological entity (presumed human) who controls the client. Authentication is about the server making ...
2
The original question asks if Facebook, Twitter, etc authentication schemes are PCI-compliant.
The Payment Card Industry (PCI) Data Security Standards (DSS) specification cites two separate and distinct things about authentication and it is the context of use that discriminates between the requirements:
Section 8 states that a unique ID must be assigned to ...
2
One thing to consider if you're considering relying on Twitter/Facebook for authentication is that both of them still allow for session IDs to be transmited over an unencrypted connection as, after authentication, they are accessed over http and not https.
As such they're unlikely to be considered to be in-line with PCI requirements.
2
#2 is absolutely true but not primarily a problem of federal id, only that it is even more critical in this case.
You have similar problems with all login forms embedded in (actually) untrusted content, especially because the used authentication is the most insecure(secret is simply transmitted by the browser, and if you're lucky the server puts SSL ...
Only top voted, non community-wiki answers of a minimum length are eligible
