This is the paragraph on OpenID security from Wikipedia. Are there any new updates about this, or any comments?
Security and phishing
Some observers have suggested that
OpenID has security weaknesses and may
prove vulnerable to phishing
attacks.[26][27][28] For example, a
malicious relying party may forward
the end-user to a bogus identity
provider authentication page asking
that end-user to input their
credentials. On completion of this,
the malicious party (who in this case
also control the bogus authentication
page) could then have access to the
end-user's account with the identity
provider, and as such then use that
end-user’s OpenID to log into other
services.
In an attempt to combat possible
phishing attacks some OpenID providers
mandate that the end-user needs to be
authenticated with them prior to an
attempt to authenticate with the
relying party.[29] This relies on the
end-user knowing the policy of the
identity provider. In December 2008,
the OpenID Foundation approved version
1.0 of the Provider Authentication Policy Extension (PAPE), which
"enables Relying Parties to request
that OpenID Providers employ specified
authentication policies when
authenticating users and for OpenID
Providers to inform the Relying
Parties which policies were actually
used."[30] Regardless, this issue
remains a significant additional
vector for man-in-the-middle phishing
attacks.
Other security issues identified with
OpenID involve lack of privacy and
failure to address the trust
problem.[31]
This phishing attack still holds. If I (as a phisherman) sets up a page, I can link to my self-made (copied) Google login page and claim it's the real one. I don't even need to implement OpenID, I can just say that I do.
So yes, this attack is still very much possible. The solution is to educate computer users: they should check the domain name, make sure the login page uses SSL and that the SSL certificate is for the correct domain.
Related
I intend to have a PHP web service accepting JSON-RPC over TLS (HTTPS). Every client will have an API key that I will use for identification purposes. Is that enough security, is there a JSON-RPC security specific standard?
That's a fine way of doing things. Here's an overview of the requirements and components play in your security scheme:
Checklist
Here's the checklist of what security is needed, and how you would address it:
A third party can't eavesdrop on your communications. HTTPS provides this.
A third party can't tamper with your communications. HTTPS provides this too.
The client can authenticate the server. HTTPS provides this (*).
The server can authenticate the client.
Client authentication
There are lots of way to authenticate the client. Here are a few exaples:
Use the API key to calculate an HMAC of the request and include the HMAC as a header in the request. (**) The most secure, but more complicated to set-up. The key advantage is that should your server be compromised, API keys won't be exposed.
Include the API key itself in the request. Easier to set-up, may be sufficient security depending on your requirements.
...
(*): So long as the client library does. HTTPS requires that you use a certificate that validates your site corresponds to the domain name. Unfortunately, many HTTPS libraries do not validate this by default.
(**): You should also use a nonce to prevent against replay attacks.
You could be signing a request using a secret salt (+hashing algo of choise, MD5 will do fine) because this way an eavesdropper cannot obtain the "API key" and forge his own requests. Use a very long salt.
The salt also acts to protect against intentional altering of a message by a successfull eavesdropper.
How can there be a man in a middle? TLS(SSL) is not much security against man in the middle attacks, unless you issue whitelisted certificates per client. For example, the server in the middle (attacker) obtains valid certificates, or the client application is not checking for various certificate validity settings (expiration dates, etc.). If not under your control, it is likely that clients of your RPC server will connect without doing any sort of security checks. This is a widespread problem. Eavesdropping usually implies access to your (or your client's) network so this could mean poisoned DNS traffic redirects to the rogue server.
Wether your or your client's network connection is secure enough to exclude the possibility of DNS poisoning, or your client is checking the certificates for validity, or you force the client to use whitelisted SSL certificates, are things only you can influence or decide upon.
You might also want to prevent replay attacks by assigning a unique number for each request (possibly overkill if these API calls are just for reading) for denying duplicate requests.
The API keys you mentioned, are generally used when browser side JavaScript clients are involved to track usage. API keys are reissued, when stolen, to identify and disable unauthorized apps (and maybe automatically make a list of the fraudulent domain names for further [lawsuit] action).
We have an app hosted on our domain. All users are required to first log in through a POST form. Once login has happened, then form redirects to dashboard page on our site automatically.
Is it possible to allow some clients to host their own login forms (on their site), that POSTS to our app? Is cross-domain posting considered bad practise in any way? Are there any pitfalls to be aware of? And lastly, how is SSL taken care of given that our site always runs on HTTPS, but client sites may not? Can this be circumvented with an iframe?
What you are trying to reinvent is called openid.
What you need to do is provide a openid service, and then users can make there own login forms that connect to your open id server.
I have a great example of such a site: http://www.stackoverflow.com that uses google and others as openid service to log in, making there own login form.
What you're trying to do is generally referred to as Single Sign-On (SSO). This can be implemented using a variety of technologies.
The general idea is to separate the Service Provider (SP) (also sometimes called Resource Provider), which is what provides the actual service the user is going to use, from the Identity Provider (IdP), which is where the user's identity is verified.
The simplePHP library provides implementations for both IdP and SP authenticating layer using a number of SSO standards: SAML, Shibboleth (also SAML-based), OpenID, ...
Note that if you're using a standard, the IdP shouldn't need to be implemented using the same implementation as the one you've chosen for your service. It could be possible to have an IdP implemented in Java using the Shibboleth libraries and use it in conjunction with an SP that uses simplePHP, for example.
Which of these techniques you use will depend on the kind of information your require after authentication, for example if extra attributes are required, and how trust is managed between the IdPs and the SPs.
Typically, a simple OpenID system will be rather straightforward to integrate, from an SP point of view, but it will be quite limited in what it can assert about the user. In contrast, Shibboleth has a number of options to specify which SP can see which user attributes and what IdPs are meant to release or not, but it requires a more substantial infrastructure: this is typically done in a federation, where all the parties exchange a set of metadata configuration that comprises X.509 certificates they use to trust each others' assertions.
Since the authentication will happen outside your administrative boundaries, you can't really control how the users will have authenticated (unless this is part of a more formal agreement, such as in a Shibboleth federation). The OpenID provider could potentially let users authenticate over plain HTTP even if your service requires HTTPS. (This being said, most serious OpenID providers do it securely, and it's up to the user to pick one their trust anyway.)
Never embed the IdP page in your service: make the user go to a their IdP page instead. For an authentication system to be secure (as far as the user is concerned), it is essential that the user be able to see what they're typing their passwords in. By using an iframe, you would effectively hide the real site behind (and logos are easy to grab/forge). (The StackExchange OpenID provider has some problems in that respect.)
i'm developing a website with videos. i do not have any transactions in my site. i have a login system.
Do you think i require ssl for the login system? i've even integrated facebook, so mostly users would login with their facebook account.
Is there any alternative for ssl for websites like mine?
Anything you pass over the Internet without using SSL/TLS (or an equivalent system to encrypt/protect the confidentiality of the information you are passing) must be assumed to be completely compromised and visible to anyone. In your case, that would include usernames, passwords, and session tokens, which could allow an attacker to learn your UN/PW combinations, so they could impersonate users for the long term, and session tokens so they could act as a logged in user.
Do you need to protect this? Absolutely a risk decision. What is the sensitive level of your data? What would be the consequences if this compromise happened? What would your users think if their usernames and passwords were to be made available to the world? As users tend to reuse passwords among websites, then there would be some damage to your site's reputation (and your reputation) should this happen.
The same thing can happen with your Facebook-based login. This uses OAuth, which is just a bearer token sent from the client to your server. If this is sent outside of an SSL/TLS tunnel, it has to be assumed to be compromised and, based on how bearer tokens work, anyone who can see the token and reuse it and act as the user.
Basically, SSL/TLS is cheap, both in terms of the cost of a certificate from a respected and trusted CA and server power/latency. If you have a user base of any significant size, then it most likely a very easy decision to use SSL/TLS.
I would seriously consider using a 3rd party OpenID or OAuth provider as an authentication system. There are many considerations for handling a login. Often users are put at risk by custom login systems that use weak hash functions to store the password. A good example is the Gawker leak which used DES for password storage. Pretty terrifying stuff, especially when you think that this can be avoided entirely.
Obviously you need SSL to transmit a username and password over the network. But really the user is authenticated to your application using a cookie value or session token. This is the real method of authentication and why OWASP a9 requires that this value is never spilled over an insecure channel.
If your website is worth anything at all, then use SSL to protect your user's sessions. If your website is useless and no one cares about having an account, then why build it?
Many people use the same logins on different sites, so to prevent eavesdropping, it is recommendable to use ssl.
If it is the price you are worried about and you do not do any financial transactions on your site, you can try to get a free certificate: https://www.startssl.com/?app=1
what is phpmyid exactly?
can I use it for logging into yahoo mail?
which steps I must follow?
Well, basically OpenID is a way to authenticate yourself to various places (websites) by verifying your identity as the owner of a particular URL (say, a website of your own)
I can't understand it's explanation exactly.
OpenID is a way of using one ID for multiple sites. Think of it like using a Facebook login to register on multiple sites, just without the Facebook account.
The great thing about OpenID is that it's based on secure principles, and you only have to remember one password to identify yourself to any site that chooses to implement OpenID.
The problem, however, is that OpenID relies on OID providers. If you want to maintain your own identity, you're pretty much out of luck. You still have to hand over some of your identity to a third party who maintains your identity to serve it to any website which you authorize to use your identity to log you in.
PHPMyID allows you to essentially be your own identity provider. Instead of registering on one centralized provider to maintain your profile, you set up the script and run it on your own server. This way, you retain control of your own identity, while still using one login for any website that supports OpenID.
Note, of course, that PHPMyID is no longer developed.
phpmyid is a buggy, insecure and unmaintained openid implementation that you should not bother with. See this page for the juicy details.
Started with this question: OpenID. How do you logout
OK. So OpenID does not have single logout.
I can see the uses but there are some situations that worry me:
Single signon on is great for mobile devices and your personal computer.
You sign on once and probably never need to sign out again (just authenticating with new sites as you go).
But if I am on a public computer (airport, or even a work computer) this is a problem.
When I sign into a website using openID I am signing into two different places and that is not obvious. I sign-onto a website (stackoverflow for example using gmail account) but at the same time I have just signed into gmail (OpenID Provider).
When I sign out of stackoverflow I am still singed into gmail (OpenID Provider).
When I authenticate with gmail I don't want to login into gmail I just want to authenticate.
A hack around this is to have the logout flow log me out of gmail at the same time, but as noted on the last post, if I log out of stackoverflow I don't necessarily want to logout of gmail if I am at home.
So the question really is:
Is there a way to authenticate with these OpenID providers without logging on.
Because even sites like stack overflow, they do not log you out when you logout of the OpenID provider you authenticated with. If you have gmail account I can log in and out all day without affecting if stackoverflow is logged in.
If the protocol doesn't support it (and it doesn't) then there's nothing you can do here, aside from delete all your cookies once you're done, which would clear the cookie which logs you into your provider and the ones that log you into services.
As an aside an OpenID provider doesn't have to provide you with a persistent cookie, or even a session cookie which keeps you logged into your OpenID account, it could authenticate you once for itself, then sent the authentication token onwards. If you're worried about being logged into Gmail when you use OpenID then choose another OpenID provider.
But how is this a question?
People apparently fail to see the question in your question, so I repeat it here just for clarity (and with a question mark)
Is there a way to authenticate with these OpenID providers without logging on?
I believe that the answer to this question is "no" (as blowdart elaborates).
The short answer is yes, in practice, by choosing a reasonable OpenID provider.
The long answer is that this is a question about your OpenID provider, not OpenID itself.
OpenID only handles authentication. Session support (and related concepts such as logging in or out) is outside of the OpenID spec.
Your OpenID provider may keep a session for you (probably with a browser cookie). Any reasonable provider will not do this unless you indicate ("remember me when logging into stackoverflow.com").
The OpenID consumer (such as StackOverflow) may keep a session for you as well. There is nothing you can do about this, but this is true for any authentication scheme, whether 3rd party or direct.
Because the 3rd-party aspects of OpenID are well designed, it is easy to avoid logging in in practice, by choosing a reasonable provider, or better yet, by using a HTML page as your claimed identity, which delegates to a provider which you can change if you decide to switch.
OpenID doesn't specify if provider should create a login session for themselves but almost all of them do. So there is no option to just authenticate RP without leaving a session in OP.
If you really want to authenticate without leaving a session, you can do it with other protocols. Just about every OP provides a proprietary protocol to login with username/password. For example, Google has ClientAuth and AOL has directLogin. This is so called password anti-pattern. It creates some privacy concerns because you collect Google password on your site. I am not recommending it in anyway.