I'm writing a web application that allows anyone to register (using their OpenID). When a user registers, their OpenID is saved in a MySQL database.
My question is: In which format should I be storing a user's OpenID value?
If someone were to gain access to my database (I'm planning for the worst case scenario) - would it be an issue that the user's OpenID can be viewed unencrypted? Should i be encrypting it when it goes into storage?
There is no real benefit in protecting their open id: that's the whole point of it!
OpenID is made so that the "secure info" is not available at the intermediary sites where you use it - the only secure info is held at the OpenID Provider (the site where you actually enter your password).
A compromised database on your site means that the attacker will know who your users are, but nothing more, nothing less.
This is one of those things that is up to personal taste, but MySQL do offer some encryption functions you might wish to take a look at.
http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html
In which format should I be storing a user's OpenID value?
Even when someone has access to the openid's stored in your database, this information will be of no use to him as it is only a url which asks for user authentication details when executed.
So you need not worry on that.
The openid providers will take care of that if the details entered are correct or not.
Related
I'm new to OAuth, and although I have scanned through many documents, I don't seem to have yet a good architecture / design to a secure web application, answering most/all of OWASP Top Ten
My newbie questions are
Why can't I just rely purely on OAuth? why do a user needs credential in my own application?
If I do, do I need hash / salt anything if I save it? I don't store any passwords, but what about tokens?
I still need to persist the users so they won't login everytime, (like in OS) - do I
Somehow use the OAuth token (save it? does it make even sense)?
Or use the plain old httpOnly secure cookie (if so, what happens if they log out of the Oauth provider? shouldn't I in this case ignore my cookie and let them log out?
How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?
How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)
I guess I have a lot to learn, but reading on so many potential security issues, and having to master so many different topics seems like a good potential for me missing something that someone later will exploit.
Is using a framework such as Spring Security, or using Lift's built in user management going to save me all this headache? or do I have to know exactly what I am doing to avoid things like Session Fixation, Cross Site Request Forgery, Cross site scripting, Rainbow tables and other things I only remotely get...
Why can't I just rely purely on OAuth?
From a service providers perspective, OAuth is a means of controlling access of third party applications to the business logic. The end user does not have to give out his password to the third party app, and the access can be controlled. For example, the provider could restrict the access to only parts of the service for limited amount of time.
If you write a third party application, there is no strict need for you to have your "own" user artifacts. You can rely on the users that authenticate your application.
You could require that user's have an account with a provider such as Facebook or Twitter and not implement any password stuff yourself.
(You probably need some sort of artifact to represent a user, it should in this case contain information about how that user authenticates your application, for instance an OAuth token, or an OpenID URL).
If I do, do I need hash / salt anything if I save it? I don't store
any passwords, but what about tokens?
Just to clarify, in OAuth a token is typically both a key and a secret, and they are needed in cleartext to sign requests (there are differences here depending on which version of OAuth you use). So you can store them encrypted, as long as it is reversible for you.
I still need to persist the users so they won't login everytime, (like in OS) - do I
somehow use the OAuth token (save it? does it make even sense)?
Yes this makes sense, a token represents your applications access to a specific user's data. Save the token if you want to keep a "session" alive.
How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?
There is no concept of "logging" out of OAUth, a token either has an expiration time or not. You can of course "log out" by simply choosing to forget the token. The next time you will have to redo the authentication. You cannot force users to invalidate an access token, unless the provider has an API for that.
You could save the token in a cookie, but I would use other unique identifiers for the session you want to keep alive. You can persist the details of the tokens server side. The information you store in your cookie shold make it possible to retrieve the token you need.
How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)
If you save a token in a database, save an ID for that token in a nice secure cookie. When a user goes to your service, use the information in the cookie to make a call from your service, to the service provider, to check if the token is still valid. If so, you have established enough trust for you to "log in" the user in your application without having to go through the pain of the OAuth process again.
And as a side not, StackOverflow uses OpenID and not OAuth for user authentication. OAuth can be used for the same purpose but is mainly a specification for application authorization.
I hope this helped, and don't sell yourself short. This site is for posting questions, not for appearing all-knowing.
I asked a similar question here a while back but all the answers were offering OpenID which is nice but it doesn't work with services that require authentication that don't use it (such as EventBrite).
Say I want to create an app that lists your events from event brite, and their analytics (which eventbrite includes). Any person can sign up for this service to list their events. But since EventBrite doesn't have OpenID to authenticate, I need to somehow get the user login and password to EventBrite.
Some possible solutions are:
Store credentials in YAML like this. Easily hackable.
Have user enter in credentials into a form on my site, I save the credentials to my database, and use them to login to EventBrite. Easily hackable.
Have user enter in credentials and I pass them directly to EventBrite without saving, and I save the response header Cookies to the database, and when they expire, have them login again. Is this easily hackable?
This hypothetical service also wants to automatically check events (say via cron), so it doesn't depend on the user going to my site via the browser. So cookies or credientials need to be stored somewhere.
The thing is, after asking this similar question about confidentiality and security it sounds like you should never build an application that does what I'm describing. There's got to be some way building something like this is okay.
What is that way? What am I missing? Is it okay to go with #3 and save the cookies (but still needing the user to submit their email/password via a form which I send to Eventbrite)? What is an acceptable solution to the problem?
There isn't a secure way to do this. You can employ workarounds, but that's about it.
Storing passwords in YAML or XML in cleartext is definitely out
In fact, even encrypting and storing passwords is wrong. Your application would need a way to decrypt the passwords, so the attacker can also decrypt the passwords.
The recommended way to store passwords is Salt + Hash, but because it becomes unrecoverable, it is useless in your case.
Because of 2 & 3, no matter where you store the users credentials, you are vulnerable.
Storing the cookies instead of the passwords is a better idea. But again, this involves the password going through your website, which isn't good.
Given your situation, storing the cookie is a better approach. Use HTTPS throughout, even on your website. Its less than ideal though, and you and your users should be aware of it.
Eventbrite has recently release new documentation describing how to implement OAuth2.0 for cross-site user authentication.
I would recommend using our javascipt-based OAuth2.0 widget, which stores the user's authentication tokens in their browser's localStorage by default.
Since the auth tokens are stored in the user's browser, and are prevented from being accessed by other domains, it's not likely that there would be any security leaks.
The need for email and password combos are completely avoided in this authentication scheme.
Most sites only support direct login with the original cleartext password, so you have to get, store and provide that too. And I would never ever trust you with that.
The problem with your concept is that you require the password to be given to a third party. The solution is not to involve a third party, for example my browser is pretty good at storing and filling in passwords for me automatically (my hard-drive is password protected too). And they are dozens of other password wallet apps too. I wouldn't gain anything by subscribing, using your service.
Before going into such a business, consider you are going to be the #1 target. Facebook, Google are incredibly paranoid about security, spending a lot of time, money and effort to keep the logins safe. Do you have the same resources? Then you are a better target. Also by hacking your service, they immediately get multiple accounts, passwords of your users, also seeing who is always reusing its password.
For working with the Eventbrite API, I'd recommend ensuring that all connections are over SSL, and that you authenticate using a user_key rather than a username and password.
More information about authentication for the Eventbrite API is here: http://developer.eventbrite.com/doc/auth/
After logging in, users can find their user_key here: http://www.eventbrite.com/userkeyapi
This should prevent username and password information from being intercepted over the wire, or read from a local data store.
Since I have never used openID befor I have no idea about it.
I want to know when someone want to log into my website using openID do I have to register his information (is there any registration process efen if the user don't fill the information).
should I provide an alternative classical user registration beside openID.
The best OpenID login experience has no user registration. You accept their OpenID and you and your user are both done. Talk about lowering the barrier to joining your web site. It doesn't get much easier than that! If you must gather more information about a user besides just their OpenID claimed identifier, and this is a general rule with user registration: keep it minimal, and preferably don't ask for the additional information until the user actually requests a service that requires that you collect that particular data. This helps keep the user interested in your site and doesn't drive him/her away.
And if you're writing a new web site, I highly encourage you to not accept username/password anti-pattern. If you do your OpenID login right (today that probably means making big, prominent Google and Yahoo login buttons and then a smaller OpenID button that makes a text box appear) then users won't get confused. Before OpenID, lots of sites had "Login with Yahoo!" buttons on their sites and users "got it". OpenID can look just like that and be easy for the user.
By not offering a username/password style login, you somewhat force the user (with your ultra-easy OpenID login) to start getting used to not reusing an old or inventing a new password at your site. We as webmasters must train web users to stop giving their private passwords to so many web sites.
Our solution was to run our own openID provider and not tell anyone. If you choose to sign in without openID you get redirected to a very locked down openID provider. This was great as we started with 1 site and now have 4 and they can all share accounts. Our provider will not let you use it anywhere else (can't login here with it).
Opinionated Rant
My opinion will almost certainly be unpopular; but I'm going to make it anyway, 'for the good of privacy' :)
OpenID is not a great idea; typically in computer security it is considered bad to have a single account for everything, as if that account is compromised the person can compromise all services attached to it.
OpenID violates this quite directly.
As well as this, it creates a single point of failure, and if the protocol is shown to have a flaw [removed incorrect reference to OAuth flaw] it means you are susceptible everywhere.
Now it goes without saying that OpenID provides convenience; and sure it does, but for mine, the cost of this is too great.
Personally, I was a bit frustrated to note that OpenID was the only way to sign up to this site; so I would suggest to you that you provide an alternative mechanism (and if it were me, I would not implement OpenID at all).
Summary
Yes. Provide alternatives (IMHO).
you can do like stackoverflow website, new user will be unknown until the user fill his information, and in your website you can disallow the user from posting if he didn't complete his profile info.
should I provide an alternative
classical user registration beside
openID
yes you should provide because maybe the user don't have openID registration or he know nothing about openID tech.
Google uses email addresses as OpenID login strings for its provider service.
I was reading about a conference where they were pushing to have it incorporated into the standard. Microsoft was against this, the "official" reason being security vulnerabilities this would supposedly introduce. Is this bogus? If not, why is it insecure?
This goes against the minimal disclosure concept. Right now if an OpenID relying party wants your email address they ask for it and you are warned about this by the identity provider and asked to confirm it. Using the email address means it goes whether you like it or not unless you're using OpenID 2.0 which can generate unique values on a per relying party basis.
It would also be a big change for all the OpenID libraries - URLs are discoverable, you know where to go with them, email addresses are not, which was why there was outrage at Google unilaterally doing this and effectively forking the OpenID standard to suit themselves.
The other problem lies in phishing. OpenID is very vulnerable to this as users trust the relying party to redirect them to their provider after discovering it via the OpenID provided - so a "mischievous" relying party may redirect to a phishing site which saves the OpenID and the password. With Google the OpenID and password is your gmail account and password so you've not only lost control of your OpenID but your email account as well. Of course this could be secured by the provider - you could have separate email passwords and OpenID passwords, you could have a secret message on a per user basis you show on the OpenID login page, but as we're well aware users are stupid. They don't check URLs in the browser, they blindly click OK on dialog boxes, they simply don't think that a web page could be fake. By using the email address and the same password Google are exposing the majority of their users to an unacceptable risk.
One danger of using email address is that it is guessable. Or rather than someone who wants to break your account will probably know it.
Compare that to the current situation where your username and your OpenID provider could be anything. Maybe that's guessable, maybe it isn't. If it's not it makes it just a little harder to compromise your account.
Some people seem to have a problem with this. Look it's pretty simple. I haven't said that a non-obvious username is in and of itself sufficient security. Far from it. Security through obscurity is no security at all.
However, it's pure commonsense that out of:
A password with an obscure username; and
The same password with an obscure username.
that (1) is, at worst, equally secure to (2) and at best it is more secure.
What's more if your email is your password then if you compromise someone's email address you potentially compromise every system that uses that as a username is more easily compromised both by virtue of "Forget Password?" links and the fact that a password used in one place is more likely to be used in another.
Sorry but that's just commonsense.
Is OpenID a secure method of authentication users on a website?
And, if not, what are the security risks associated with OpenID?
I agree with many of the points David makes above, so I'm making some points here just for the sake of argument.
For the knowledgeable user, I would argue that OpenID is a more secure form of authentication than many websites provide. Now let me back up that statement. First what do I mean by a knowledgeable user? I would define that person as somebody who is aware of the weaknesses of OpenID and who takes measures to mitigate them:
Maintains multiple personas if they don't wish websites to be able to track them effectively.
Registers two or more OpenID providers at websites where 24/7 access is an issue.
Always logins to their OpenID provider directly. They never login to a page a 3rd party web site has redirected them to.
Many websites do not know how to securely maintain user's passwords. The really nice thing with OpenID is that I get to choose my OpenID provider and thus the level of authentication needed to login to a relying party. For example, I can choose to delegate authentication to Verisign or Trustbearer - both of which provide much stronger authentication techniques than most websites on the web. I would much rather trust an organization which specializes in security with my password than some random web site on the web. So I would argue, that for the knowledeable user, OpenID can be more secure than each website implementing their own authentication system.
All that being said, most users are not aware of the risk factors inherent in OpenID and won't take the steps to mitigate the risks.
Actually I always disliked OpenID for various reasons.
I have to trust the OpenID provider who I gave my data. I do trust certain sides to certain degrees, but just because I may trust Stack Overflow, I don't automatically trust any of the well known OpenID providers.
If my OpenID password is compromised, all my sites where I'm using OpenID are compromised. Usually I would chose a different password for every site I'm using, but I can't with OpenID.
I don't like the Persona concept at all. Even though I'm asked before any data is sent, it just doesn't seem right that one provider has this information and other services can request it. Okay, I don't have to use it if I don't like, but the concept seems flawed to me.
As has been mentioned already, data is sent between a site and the OpenID provider and back again. Whenever data is exchanged, it can be compromised. No system is 100% secure; not even SSL (HTTPS). It's a difference if data only travels from me to a side and back to myself or if it also travels from that side to another one and back again.
If an OpenID provider is hacked and the hacker gets the login data of all users (after all they are lovely centralized in one place!), just think of the impact!
Just to name a few. I also fail to see the big advantage of OpenID. For the user they say
Faster & easier registration and login
Reduced frustration from forgotten user name/password
Maintain personal data current at preferred sites
Minimize password security risks
Okay, let's analyze that.
(1) How often do you register for a page a day? 200 times? If I register for 2 pages a week, that is already a damn lot. Usually rather for 2-3 a months at most (actually Stack Overflow, or my OpenID provider to use Stack Overflow, was the last page I registered and this was not quite yesterday). So when you register for 2 sites a month, you don't have the 5 minutes it takes to fill out a form? Come on, don't be ridiculous.
(2) How? Because it uses the same password everywhere? "This is no future, this is a bug", most security experts would say. Or because it allows me to recover my password via mail? Well, actually almost any side I use allows me to do so. Despite that, my Firefox remembers my passwords quite well, stores them encrypted on disk (using a master password) and this encrypted database is back-uped regularly to never get lost.
(3) Well, this is probably something positive... however, my name has never changed so far, my e-mail address won't either as it's one of the domain I use and forwarded to a real address (so the real one can change, I just update the forward and everything works as before). My street address? Well, some people move a lot. I only moved once in my whole life so far. However, most sides don't need to know my street address. Sites where I see no reason for having the people know this information, but that demand me to fill it out for registering, just get a faked one. There are very little sites on the whole Internet that know my real address (actually only those that may ever have to send me a snail mail or where I might order goods).
(4) Actually I see it the other way round. It maximizes the security risk. How would it minimize the risk?
OpenID is inherently insecure. It works by your site redirecting the user to their open ID provider site and then accepting an ID back from that site. This provides insecurities in both directions. You have to trust the ID that comes back (as you have no way of authenticating the user yourself) and it is easy to operate a proxy to the user’s open ID provider, that allows you to steal their username and password.
OpenID is fine for something like Stack Overflow, where it doesn’t really matter if someone impersonates you. Using OpenID for sites with more serious – on a personal level – content is extremely risky. If you use OpenID for your email for example, then anyone stealing your Id can access your email. They could then in turn send password reminder requests to other sites that you use in order to get passwords for those sites. In the worst case, you could use OpenID for a bank account, or have a bank that sends password reminders to your email account...
There are numerous other security problems with OpenID. You can find more information in "Privacy on the Internet".
OpenID does add another party to the authentication process which you must treat as a trusted component. It's quite similar in that regard to any application that allows account recovery by e-mail, but whereas your email messages are transmitted in cleartext, you may choose to communicate with OpenID providers only over verified HTTPS connections.
Review the Security Considerations section of the specification.
For a great description of the weak spots in OpenID and a demonstration of how a good OpenID provider can give an experience that's much more secure than the traditional easily-phished password, see this short video by Kim Cameron from his Identity Weblog.
OpenID can be made more secure if you choose to ignore all OpenID providers that do not support HTTPS
I think the main weakness of most OpenId providers is that they offer password recovery via e-mail. That reduces OpenId security to the security of my e-mail provider. If someone gets access to my e-mail account he can effectively steal my identity (with or without OpenId).
Using OpenId for authentication makes stealing ym identity just easier. Just get access to my e-mail account and reset my OpenId password. Nothing more to do (instead of 100 password reset requests, one for each of my accounts on the web).
Even worse, if the attacker changes my e-mail account's password it will be very hard for me to prove that I am the original owner of that OpenId account. The attacker might change the associated e-mail account to his one so I can't reset the password even if I get back my e-mail account later.
It might be enough to get acces to the password recovery e-mail my OpenId provider sends to steal my identity.
OpenId providers musst offer disabling e-mail password recovery and provide a more secure way to recover a lost password. Something based on postal address, passport or bank account (things I trust more than an e-mail account).
As long as an OpenId account can be taken over by just getting access to a single e-mail it's nothing more than an additional single point of failure.
See also: http://danielmiessler.com/blog/from-password-reset-mechanisms-to-openid-a-brief-discussion-of-online-password-security where "The Weakest Link: Email Password Reset Mechanisms" is adressed, too.
While this thread is old I wanted to add my 2 cents. I think OpenId has one flaw that no one seems to care about. When I authenticate with Yahoo, it actually logs me into yahoo. It should not log you into yahoo it should just authenticate that you have the proper credentials with yahoo. When you log out of my app, you are still logged into yahoo. If you walk away from a shared computer and another person goes to yahoo, you will be logged in.. because when you authenticated with Yahoo, they also log you into their service. They should just authenticate you, not log you in. I have told several people about this and even demonstrated it with stackoverflow.com (who has a terrible log out mechanism, when I hit log out I expect to be logged out, not please click another logout button). Try this logout of yahoo or gmail. Close all your tabs, and then log into stackoverflow with yahoo/gmail. Then log out off stack overflow..(make sure you hit logout twice).. now browse to yahoo or gmail, you are logged in. Now the snide answer I get is "Don't use a shared computer, you should log out of Yahoo/gmail, etc"... Everyone is not a developer with a degree in MIS or computer science, my mother in law would think when she logged out of Stackoverflow, that she would not be logged into yahoo still.. Perhaps I am missing some parm or something that will actually force what I want, but it is surely not in the documentation telling you how great OpenId is!!!
Ouch. MyOpenID reports unconfirmed email addresses, just did a test for that. Looks like email info should be trusted only for some manually white-listed providers like google/yahoo and couple of others. I'll link the code here if someone's interested.
I like Verisign's VIP access which sites can make use of, and there is a nice little iPhone application that will let you have your generated token to get in, much like secureID