Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
OpenID is a great idea in principle, but the UI and the explanation as to why it is good are currently not tailored for general use -- what do you think it would take to make OpenID work for the general public? Can this be solved with technology, or is the problem so intrinsically hard that we are stuck with difficult explanations/multi-step registration procedures, numerous accounts, or poor security?
It needs to be much simpler: involve less knowledge of the concepts, and require fewer steps - preferably zero. When the technology works with little or no assistance, it'll take off.
The mechanics of OpenID credentials, providers and suppliers shouldn't need to be exposed to the user. People talk about educating the masses of internet users, but that's never going to happen - the masses never stop being stupid. If you want to appeal to the masses, you need to bring the technology down to meet their level instead. When a Google-affiliated site picks up that you're logged into Google and silently uses that account, it works without you ever having to tell it who you are. The fact that OpenID is so clumsy in comparison is why the big providers like Google are still avoiding it, and why the general public won't adopt it.
I think the developers of OpenID messed up when they used a URL rather than an email address for the IDs. People know what email addresses are, they already have one that's associated with them (or can get one easily), and email providers like Google and Microsoft are happy to adopt a role as portals. In fact, an automatic translation from email address to URL is all it would take:
myname#example.com -> http://www.example.com/openid/myname
I think it'll take a huge buy-in from a site that millions of people use; for example, MySpace is soon supporting OpenID, so now the number of users that OpenID supports has just jumped by a huge amount. If more of the high activity sites on the net follow this lead, there you go!
ISPs should provide openIds to all their customers that mimic their e-mail addresses. Perhaps openID needs to support automatic translation of foo#example.com into http://openid.example.com/foo so that ISPs can easily set this up on a separate server.
It will take all the popular sites supporting it and making it transparent to the user.
"You can make a useraccount here, or if you use MySpace, Google Mail, Hotmail, etc then you can sign in using OpenID."
Don't sell it as a new service, sell it as being able to sign in using a different ID from another site.
The issue, however, is that with everyone supporting it each user will now have a myspace id, google id, etc. Now if they sign onto stackoverflow with their myspace id then later with google they may be perplexed that stackoverflow doesn't recognize them.
I wonder if openid has a solution for linking openid accounts so they are one and the same - I doubt the technology allows for it, since they are essentially independant signing authorities. Google would have to share data with Myspace and vice versa to enable that...
I don't think it will become mainstream. I think Ted Dziuba gets it right when he says it solves a "problem" that most people don't consider to be worth solving.
http://teddziuba.com/2008/09/openid-is-why-i-hate-the-inter.html
It will have to get a hell of a lot simpler, with easier-to-remember IDs.
You mean it isn't already? ;)
Obviously a lot of currently-popular applications would need to offer it and make it obvious that it was a good alternative.
If Google and Facebook made it an obvious option, that would help.
Ultimately, user education will really be the thing that does it. I doubt most people would care though...dumb sheeple.
Many of the responses so far seem to boil down to two options:
user education, and
forcing adoption (lots of sites changing to openid from in-house auth.)
Is that all we can do? What about distributed tools to make it easy for casual users to do openid delegation? (Say, something integrated with OS X / Windows / Ubuntu) Are there technological barriers that make this infeasible?
If client-side (and vendor-issued) applications could let you manage your on-line security preference, then we'd possibly be able to combat some of the risks associated with giving random sites your passwords -- since the "login area" would be some local program sitting in your systray, or what not. Of course, the integration of web apps with the desktop (such as that provided by Chrome) may make such a distinction impossible in practice, so it may be a moot point.
In any case, it seems like there should be something we could do now to make openid more palatable to the general public, and speed adoption in addition to making the system more user friendly.
As someone who primarily programs web apps in Java, I can't/won't use OpenID because the library support isn't there. JOID and openid4java are the only two that I know of. JOID is apparently not actively maintained, not including really important patches that have been on the mailing list for months; and openid4java requires >40 megabytes of external dependencies, including some that need to go into the endorsed classpath, which is, as one user commented, ridiculous:
Comment by witichis, Apr 28, 2008
46MB download for a simple redirect and de/encryp - are you f****n' drunk?
In my opinion, OpenID is not bad. It consolidates login credentials. It does solve a real problem, while it may not be the optimal solution The only two problems I can see are that you must trust the identity provider not to allow someone else to claim to be you, and that relying parties (web sites you log in to) can collude to link your identity on multiple sites together.
I think we need to see OpenID offered as a login method more consumer oriented websites. There are a lot of big consumer sites that can be used as OpenID providers, but the only place I recall seeing OpenID available as a login before Stackoverflow is to comment on Blogger. Being a provider is great and all, but it's pretty much invisible to consumers. Seeing an actual place to use OpenID, on the other hand, will probably garner somewhat more interest.
It would certainly help if more OpenID consumers were also OpenID providers. As a developer, I'm comfortable going through a few contortions to figure out that I can create a new ID on openid.org, but the more mainstream consumer could easily be put off by the process.
The fact that big sites will accept OpenID isn't, on it's own, enough to make it mainstream. The closest I've seen so far was having LiveJournal both accept and provide OpenID authentication (which I believe it has been doing for quite some time).
But I think that just accepting OpenID isn't enough. What we really need is more sites like this one that refuse to make their own authentication system, and require OpenID authentication. If the "next big thing" said you have to use your OpenID to log in (with a really simple wizard to set up a new ID with someone else), I believe that it will start the ball properly rolling.
Browsers should auto-fill OpenID login boxes so that you don't have to remember your ID.
Web frameworks should come with it as the default, unless you take lots of extra time to configure a simple username/password combination.
Sites that use OpenID need to put it front and center on the login page. I have seen many sites hide it behind a link under the standard login/registration page like this:
Username:
Password:
or use your OpenID
Choosing a provider needs to be much simpler.
At present there's no way to know how reliable, trustworthy or secure any of them are, or which will still be around in 6 months time.
It won't be mainstream, as it's too much effort and is too confusing for those used to email address and password.
For example:
To login to stackoverflow with Opera I have to click login, select myOpenID from the list, type my username, hit enter, press Ctrl+Enter to autofill the password on the myOpenID site, then press the continue button.
To login into any normal site with Opera I just press Ctrl+Enter to autofill the saved user/pass combo.
Im looking into OpenId right now to integrate into a start up site so it can manage the login process for my site.
I think to make this main stream they need to make this super simple. Copy, paste code into your site and it loads the login form that gives you pretty much what Stackoverflow.com does.
I think you can style up the layout of the form to be more recognizable as well.
Personally I don't think it needs to be mainstream at all, it was an interesting idea, but it is no longer relevant.
When I create a normal login, I type in my username, master password and click on the SuperGenPass bookmarklet. That is it, when I had to sign up to stackoverflow I had to find an openId provider, sign up there (which took forever) login to my website and setup delegation, then add stackoverflow to my list of sites.
And yesterday I couldn't login because I had removed the file from my webhost and they had some security issue.
Conclusion: Don't use openid.
I'd use it if I could do it per-site and aggregate the identity later on my own time and terms. As it is, it's a giant pain in the ass to even find a decent OpenID provider; by decent I mean stackoverflow.com isn't one so I'm not going to bother.
Make it less open.
i do not want the same identity on multiple sites.
i do not want to have to create a flickr account before StackOverflow will let me post.
i do not have to have to create a new flickr account for each website that i want to register with.
Related
Stack Overflow is obviously a great example of really successfull implementation of OpenID, but let's be honest - it's a little easier when your target user base is geeks like us! I'm really interested to hear people's experiences of implementing OpenID outside hi-tech websites.
What kind of responses have you got from
a) users?
b) statistics?
with regards to the user experience of OpenID 'login with..' login systems?
With a universe of undergraduate university students, I had a positive experience. OpenID was required for them to register in an event. Beware the sample was small (around 150 persons) and of a narrow scope (undergraduates). Also note that OpenID was required, so they maybe they were willing to spend some extra effort.
Login with is essential and you need to add a small set of instructions, telling them to click a provider or to enter an OpenID address, and that they may have to register e.g. with myOpenId. Except for an audience of programmers, virtually no one is going to enter an address of his own the first time (some tried to enter their e-mail or their name, but then they eventually got it -- maybe they read the text). After registering with myOpenID, one or two entered their claimed identifier directly.
I showed only three possibilities: Gmail, Yahoo and myOpenID. For myOpenID, I used IDENTIFIER_SELECT (I didn't tell them to enter their username and use that to build the URL, like SO does). Around 80% used their gmail account, Yahoo accounts comprised little above 5% and the rest registered with myOpenID.
I only got two support e-mails where the users had made logins with two different identifiers and therefore weren't being associated with their previous login. The first case was a bug in the normalization phase of my OpenID implementation (a problem with trailing spaces). The second one was caused by the mandatory (per the spec) distinction between http://www.example.com/path and https://www.example.com/path. I think one should consider to disregard that part of the spec.
In my experience, the use of OpenID by your average home user is low to non-existent. I guess they are either uninformed about the existence, or scared to use it. On a local news site, where commenting can be done by logging in with OpenID, statistics show less than 1% usage. Most of these users have no problem logging in with their (social site of choice) credentials, which they also support. Use of these types of login are very common.
In my experience, I notice a difference more with age-groups, than with techie/non-techie status. I guess you could look at that in general terms of younger folks being more "techie" than older folks, but I wouldn't go so far as to call them "high-tech" -- they're just more comfortable with computers/internet because it's always been part of their lives.
The younger my customers are, the less concerned they seem to be with privacy / sharing their information with a "service" on the web, be it OpenID, Google, Facebook, or what have you. They also don't seem to mind having 2, 3 or even more email accounts with different providers.
The older my customers are, the less comfortable they become putting their info online (e.g.: even the bare minimum required to get an OpenID). There are enough horror stories in the news about privacy-related issues -- be it advertisers, hackers, or government subpoenas getting a hold of their information, etc. It isn't that they know something bad will happen -- it's that they know they have no idea how to spot a fraudulent service, evaluate risks or protect themselves -- it all seems so complicated, so they make the conservative choice not to put their information "out there" at all. Some of my older customers will give it a go, but even then, I also see a lot of reluctance in this group to setup more than one email account -- they use the one that their ISP provides, and won't use anything else.
Anyway -- those comments are just about who is more or less willing to use something like OpenID. Of those who are willing (of my users, I'd say about 85% below age 40 will use it; I can count on about 60-70% of my working-adult customers in general to use it; And my retiree users are at about 20%). I have only a few complaints in the "willing" groups about usability.
OpenID can be implemented on the client site in different ways and that affects how likely it is to be used on any given site.
I think StackOverflow does a very good job and you just click on your provider and it redirects and you can authenticate. I've seen other sites that just give you a text input that say "OpenID" and it's not clear what they want you to type in; not nearly as easy to use. Zendesk is one example:
https://support.zendesk.com/access/unauthenticated?return_to=https%3A%2F%2Fsupport.zendesk.com%2Flogin
I'd say that the rising popularity of Facebook as a single login is going to drastically change how people feel about logging in using OpenID, provided you make the process entirely invisible. Look at the login page for FriendFeed, for example, which promotes "one click" joining/logging in. They actually appear to be using a combo of OpenID and OAuth but the user experience is largely the same.
Now that Facebook uses OAuth, it's fairly simple to login via Twitter, Facebook, or any OpenID provider by simple implementing login for OpenID and OAuth. I actually would recommend against implementing OpenID alone as it's not much more difficult to add-on OAuth and once added provides you with the BIG THREE: Facebook, Twitter, and Google along with Yahoo, MySpace, and all the other OpenID providers that are out there.
I have a webapp that requires security beyond that of a normal web application. When any user visits the domain name, they are presented with two text fields, a username field, and a password field. If they enter a valid user/pass, they get access to the web application. Standard stuff.
However, I'm looking for additional security beyond this standard setup. Ideally it would be a software solution, but I'm also open for hardware solution as well (hardware=key fobs), or even procedural changes (one time use passwords on a password pad for example).
The webapp is unique in that we know all our users ahead of time, and we create their username and password and give it to them. In this sense, we can be assured that the username and password are "strong".
However, our clients have requested additional security beyond this. Anyone have any ideas on how to add another layer of complexity to the security?
Our company used PhoneFactor and we absolutely love it.
We've also used Safeword Tokens in the past.
However, it's notthe only game in the book. I'd start by googling "Two factor authentication"
The OWASP guide to authentication is another good place to start. Actually, OWASP is the first place I'd look for ANY web security question.
Another option for additional security is to use a piece of physical 'evidence' such as a Smart Card: Protect Your Data Via Managed Code And The Windows Vista Smart Card APIs
There are lots of different areas that web apps can have their security improved on. Before getting started you need to determine what, exactly, your problem areas might be and what you want to focus on.
You might start this process by having a third party do Penetration Testing (PEN Testing) on your application. This should give a quick hit list of things you can take care of and, when you have a passing grade, is something to use in your sales literature.
Next you'll want to talk to your customers to understand what they mean by "more secure". Is it simply two factor authentication like David and Mitch mentioned or are they more concerned about things such as data in motion (ARP Poisoning, SSL, and the like), data at rest (everything from hard drive encryption to database encryption), authorization, impersonation (cross site and replay), personnel (ongoing background checks on who has access to the machines), etc..
The concept of security covers a lot of ground.
For the sake of simplicity I want to use admin links like this for a site:
http://sitename.com/somegibberish.php?othergibberish=...
So the actual URL and the parameter would be some completely random string which only I would know.
I know security through obscurity is generally a bad idea, but is it a realistic threat someone can find out the URL? Don't take the employees of the hosting company and eavesdroppers on the line into account, because it is a toy site, not something important and the hosting company doesn't give me secure FTP anyway, so I'm only concerned about normal visitors.
Is there a way of someone finding this URL? It wouldn't be anywhere on the web, so Google won't now it about either. I hope, at least. :)
Any other hole in my scheme which I don't see?
Well, if you could guarantee only you would ever know it, it would work. Unfortunately, even ignoring malicious men in the middle, there are many ways it can leak out...
It will appear in the access logs of your provider, which might end up on Google (and are certainly read by the hosting admins)
It's in your browsing history. Plugins, extensions etc have access to this, and often use upload it elsewhere (i.e. StumbleUpon).
Any proxy servers along the line see it clearly
It could turn up as a Referer to another site
some completely random string
which only I would know.
Sounds like a password to me. :-)
If you're going to have to remember a secret string I would suggest doing usernames and passwords "properly" as HTTP servers will have been written to not leak password information; the same is not true of URLs.
This may only be a toy site but why not practice setting up security properly as it won't matter if you get it wrong. So hopefully, if you do have a site which you need to secure in future you'll have already made all your mistakes.
I know security through obscurity is
generally a very bad idea,
Fixed it for you.
The danger here is that you might get in the habit of "oh, it worked for Toy such-and-such site, so I won't bother implementing real security on this other site."
You would do a disservice to yourself (and any clients/users of your system) if you ignore Kerckhoff's Principle.
That being said, rolling your own security system is a bad idea. Smarter people have already created security libraries in the other major languages, and even smarter people have reviewed and tweaked those libraries. Use them.
It could appear on the web via a "Referer leak". Say your page links to my page at http://entrian.com/, and I publish my web server referer logs on the web. There'll be an entry saying that http://entrian.com/ was accessed from http://sitename.com/somegibberish.php?othergibberish=...
As long as the "login-URL" never posted anywhere, there shouldn't be any way for search engines to find it. And if it's just a small, personal toy-site with no personal or really important content, I see this as a fast and decent-working solution regarding security compared to implementing some form of proper login/authorization system.
If the site is getting a big number of users and lots of content, or simply becomes more than a "toy site", I'd advice you to do it the proper way
I don't know what your toy admin page would display, but keep in mind that when loading external images or linking to somewhere else, your referrer is going to publicize your URL.
If you change http into https, then at least the url will not be visible to anyone sniffing on the network.
(the caveat here is that you also need to consider that very obscure login system can leave interesting traces to be found in the network traces (MITM), somewhere on the site/target for enabling priv.elevation, or on the system you use to log in if that one is no longer secure and some prefer admin login looking no different from a standard user login to avoid that)
You could require that some action be taken # of times and with some number of seconds of delays between the times. After this action,delay,action,delay,action pattern was noticed, the admin interface would become available for login. And the urls used in the interface could be randomized each time with a single use url generated after that pattern. Further, you could only expose this interface through some tunnel and only for a minute on a port encoded by the delays.
If you could do all that in a manner that didn't stand out in the logs, that'd be "clever" but you could also open up new holes by writing all that code and it goes against "keep it simple stupid".
I've been doing a fair bit of work with OAuth recently, and I have to say that I really like it. I like the concept, and I like how it provides a low barrier-of-entry for your users to connect up the external data to your site (or for you to provide the data apis for consumption externally). Personally, I've always balked at sites that ask me to provide my login for another website to them directly. And OAuth "valet key for the web" approach solves this nicely.
The biggest problem I (and many others) see with it though, is the standard OAuth work-flow encourages the same type of behaviors that phishing attacks use to their advantage. If you train your user that it is normal behavior to be redirected to a site to provide login credentials, then it is easy for a phishing site to exploit that normal behavior but instead redirect to their clone site where they capture your username and password.
What, if anything, have you done (or seen done) to alleviate this problem?
Do you tell the users to go and login to the providing site manually, without automatic links or redirection? (but then this increases the barrier of entry)
Do you attempt to educate your users, and if so, when and how? Any lengthy explanation of security that the user has to read also increases the barrier of entry.
What else?
I believe that OAUth and phishing they are inexorably linked, at least in OAuth's current form. There have been systems in place to prevent Phishing, most notability HTTPs (pause for laughter...), but obviously it doesn't work.
Phishing is a very successful attack against systems that require username/password combos. As long as people use usernames and password for authentication phishing will always be a problem. A better system is to use asymmetric cryptography for authentication. All modern browsers have built in support for smart cards. You can't phish a card sitting in someones wallet and hacking the user's desktop won't leak the private key. The asymmetric keypair doesn't have to be on a smartcard, but I think that it builds a stronger system than if it where purely implemented in software.
You have an account with the site you are being redirected to, shouldn't they be implementing anti-phishing measures such as a signature phrase and image? This also leverages any existing training the users have received from e.g. banks who commonly use these measures.
In general, the sign-in page should present user-friendly shared secrets to the user to confirm the identity of the site they are logging into.
As Jingle notes, a ssl certificate could be used for authentication, but in this case couldn't the user load a certificate directly from the site into their web browser as part of the OAuth setup process? If a trust relationship has already been established with the site, I'm not sure further resort to a CA is necessary.
There are some techniques that can be used to avoid or diminish phishing attacks. I made a list of cheap options:
Mutual identification resources. E.x. icon associated with a specific user shown only after user input his username.
Use of usernames not deterministic and avoid emails as usernames.
Include option to user see his login history.
QRCode that allows authentication in device pre-registered like smartphones. Like whatsapp web.
Show authentication numbers in login pages that the user can validate in the official company site.
All options listed above highly depends on user education about information security and privacy. Wizards that appears only on the first authentication can helps achieve this goal.
To extend the valet analogy: how do you know you can trust the valet, and that he/she is not just someone trying it on? You don't really: you just make that (perhaps unconscious) judgement based on context: you know the hotel, you've bene there before, you might even recognise the person to whom you're giving your key.
In the same way, when you sign in using OAuth (or OpenID), you are redirecting the user to a site/URL which should be familiar to them, seeing as they are providing their credentials from that site which is known to them.
This isn't just an OAuth problem, it's OpenID's problem as well. Worse of course with OpenID you're giving a web site your provider, it's easy to automatically scrape that site if you don't have a bogus one already and generate one which you then direct your user too.
It's lucky that nothing serious uses OpenID to authenticate - blog posts, flickr comments just aren't a juicy target.
Now OpenID are going somewhere to mitigation as they start to develop their Information Card support, where a fixed UI in the shape of client side software will provide an identity "wallet" which is secure, but MS appear to have dropped the ball themselves on Information Cards, even though it's their (open) spec.
It's not going away anytime soon.
What about to certify the oAuth provider just like the ssl certification? Only certified oAuth provider is trustworthy. But the problem is, as with ssl certification, the CA matters.
I am working on a project that requires user login/registration. I'd like to avoid setting up private SSL since I am using a shared hosting provider and would like to host multiple domains off of the same plan (but since a private SSL certificate requires a dedicated ip, I can only have 1 certificate per plan...but would still like to secure all of my sites).
I am debating between
resorting to OpenID (although for a non-technical audience all the complaints I found on SO would be further multiplied)
using my host's shared SSL (which will pop up those annoying certificate warnings in the browser saying that the sites don't match).
What seems like a better option? Or would you suggest run away from both and just suggest sucking it up and purchasing additional/better hosting plans?
From my experience in dealing with SO and a fairly simple site using Google App Engine (and their authentication system), I'd give the following advice:
Do NOT use OpenID for identification. It can work for authentication with your own identity management, but there are issues as soon as you try to identify a specific user.
Its amazing how many open ids people will have, so be prepared to support multiple OpenID auth URLs (definitely more than 1, probably more than 2)
If high security is a requirement, be very wary of OpenID. Many people will use providers that they normally only use for low-security tasks (and therefore have weak passwords). This particular issue struck Jeff Atwood directly (his account was stolen due to exactly this mistake)!
Keep things simple for your users. If you do go with OpenID, emphasize one or two providers that they likely already have (eg, Google), and then provide a deemphasized selection for generic providers. Don't make the more simple-minded users think about OpenID.
Along with that thinking, a simple "Login with your Google Account" button works surprisingly well. I thought people would find it confusing to login to a third party site with their google account, but in practice this has not been a problem with our .appspot.com domain.
The bottom line is that you shouldn't expect your users to prefer openid, but it can be an acceptable compromise. I don't think that showing an invalid certificate is a reasonable option for many end-users.
Of course, the separate certs option is the cleanest, but you have to decide if thats really worth it for the value gained. I'm a cheapskate and would tend to avoid it myself. :)
Why not roll your own from the ground up? If your database is accessible from each domain, you could keep one user store that every domain could access.
Is there a particular reason you do not want to create your own user model? It's easy to do but you may have other factors that are leaning you towards something like OpenId that I am not aware of.
If you use the shared SSL's URL, you shouldn't get the popups. That's the whole point of shared SSL. What you is the identity of your site's URL when the user jumps to the secure connection.
I would talk to your hosting provider about your options when it comes to private SSL. They're really not that expensive (even free if you're ok with poor IE support). I've been with shared providers in the past that would allocate you a dedicated IP for use with SSL for a tiny extra fee (like $2/mo).
To me, the extra $54 per year ($30 for the cert + $24 for the IP) was well worth the peace of mind for me and my users.