So I like the OpenID idea. I support it on my site, and use it wherever it's possible (like here!). But I am not clear about one thing.
A site that supports OpenID basically accepts any OpenID provider out there, right? How does that work with sites that want to reduce bot-signups? What's to stop a malicious OpenID provider from setting up unlimited bot IDs automatically?
I have some ideas, and will post them as a possible answer, but I was wondering if anyone can see something obvious that I've missed?
You have confused two different things - identification and authorization. Just because you know who somebody is, it doesn't mean you have to automatically give them permission to do anything. Simon Willison covers this nicely in An OpenID is not an account! More discussion on whitelisting is available in Social whitelisting with OpenID.
The short answer to your question is, "It doesn't." OpenID deliberately provides only a mechanism for having a centralized authentication site; it's up to you to decide which OpenID providers you personally consider acceptable. For example, Microsoft recently decided to allow OpenID on its Healthvault site only from a select few providers. A company may decide only to allow OpenID logins from its LDAP-backed access point, a government agency may only accept OpenIDs from biometrics-backed sites, and a blog might only accept TypePad due to their intense spam vetting.
There seems to be a lot of confusion over OpenID. Its original goal was simply to provide a standard login mechanism so that, when I need a secure login mechanism, I can select from any or all OpenID providers to handle that for me. Allowing anyone anywhere to set up their own trusted OpenID provider was never the goal. Doing the second effectively is impossible—after all, even with encryption, there's no reason you can't set up your own provider to securely lie and say it's authenticating whomever you want. Having a single, standardized login mechanism is itself already a great step forward.
OpenId isn't much more than the username and password a user selects when registering for your site. You don't rely on the OpenId framework to weed out bots; your registration system should still be doing that.
Possible solution - you can still ask new IDs to pass a CAPTCHA test. Just like bots can sign up with fake/multiple email addresses to any site, but fail the "verification" step there as well.
Or are we going to have to start maintaining provider blacklists? Those won't really work very well, given how trivially easy it is to set up a new provider.
As far as I can tell, OpenID addresses only identification, not authorization. Stopping bots is a matter of authorization.
Notice that unlike conventional "per site" logins, OpenID gives you an identity that potentially transcends individual sites. Better yet, this identity is even a URI so its perfect for using with RDF to exchange or query arbitrary metadata about the identity.
You can do a few things with an OpenID that you can't do with a conventional username from a new user.
Firstly you can do some simple whitelist operations. If *.bigcorp.example are OpenIDs from Big Corp employees and you know Big Corp aren't spammers, then you can whitelist those OpenIDs. This ought to work well for sites that are semi-closed, maybe it's a social site for current and past employees.
Better though, you can make inferences from the other places that specific OpenID has been used. Suppose you have a map of OpenIDs to reputation values from Stackoverflow.com. When someone shows up at your web forum with an OpenID, you can see if they have decent reputation at Stackoverflow and skip the CAPTCHA or probationary period for those users.
Related
I just went to a workshop on web security, and it was kinda depressing and terrifying. We spoke about how hackable so many different aspects of web security are. Weak passwords, email reset links as a hacker's work around, and never mind distributed login attempts.
So, I was thinking what if I only use single sign on. Google, Facebook, Github etc...
Would I successfully be shifting the security burden onto these entities? Or are their still aspects of authentication I'm responsible for? I suppose SSL is one. Are there any others?
I have external customers with their own intranet sites that have links to our web application. Once their employees have logged into their intranet they don't want them to have to enter separate credentials when they follow the links to us.
What are some options for offering a single sign on for them such that we bear the majority of the technical cost for setup and that we can use with as many customers as we want. Seems like it should be a solved problem but I have not been able to find an appropriate solution (other than coming up with something completely custom).
To be clear, employees already have accounts on our application.
You don't specify which platform you are on, but you should look into authentication federation. The idea is that their intranet site produces a security token that you trust to authenticate their users on your site.
On the Windows platform, WS-Federation is typically used. On non-Windows platforms, the SAML protocol is more popular. Security protocol can use different token formats like SAML or JWT.
After further investigation, I finally found some standard protocols for doing this:
JWT - http://www.intridea.com/blog/2013/11/7/json-web-token-the-useful-little-standard-you-haven-t-heard-about
SAML - http://wso2.com/library/articles/2014/02/introduction-to-security-assertion-markup-language-2.0/
For my purposes, I think JWT is best because it requires the least amount of effort to integrate.
Greetings all:
I currently am building a web application, and have been debating whether to go with a conventional database login system, or going with an openid based login system as we have on stackoverflow and family. What my question is when would an application designer would choose an openid system over the more conventional login system, and when would it be better to use a conventional database login system?
Well it depends on several factors. Some of them are:
Security (is it a critical login like banking system? does the user need to change the password from time to time? logging into my bank account using my facebook account is quite absurd!)
Privacy (dont forget you giving information to openid providers or facebook or google or whatever you port to an synthetic openid)
Dependency on external services (avilability of those in your environment)
Portability (support them once, you have to do it 4ever!)
and the list goes on and on and on.
Generally speaking websites use Single-Sign-On and openid to increase registrations because its convienient for the user.
Permission Control / Oauth etc is another thing.
In my opinion its a very good thing but you should always offter the alternative of a genuine registration.
avoid as many problems as you can. Allow linking of accounts so that the user may change is mind and use his newly acquired openid for his account form now on, or switch to an old school user account.
To sum it up: In the background there ARE in 99% "real oldschool user accounts".
All those openid/connect stuff is just authentication. another way of entering the password.
Is this something that can be used for highly secure information or should it be bypassed for a single site authentication system? This may be a stupid question (as it does not sound secure) but I would like some advice.
OpenID itself is no less secure than the traditional username+password login.
Obviously, you're entrusting a large part of the security to the provider - e.g. brute force prevention, password size policy, etc.
Wouldn't use it for online banking for example, not while the OpenID protocol itself is insecure, but due to the use case.
highly secure information
Financial info? DoD Top Secret? Really secure information isn't available via the internet, only on the local network or through a VPN, which is moving a chunk of the security to the network level. Really really secure information is on a computer with no network connection...
There is the theory that the user, having just one password to use for their OpenID account, has the possibility to choose a decent strength password, less likely when they have to remember x passwords.
OpenID is technically sound, but can be baffling for some users. I recommend browsing through the responses to this question. For very private information I would be cautious about using OpenID because:
Since the login is being used so widely and so frequently there are more opportunities for the password to be accidentally disclosed. A particular worry would be if another OpenID-enabled site which the user is registered on one day asks them for their actual password...some users might enter it without thinking, not realizing that they are circumventing the OpenId security model.
If you have doubts about the security of OpenID, users might also have these doubts. From a business point of view, is it worth the risk of being perceived as insecure? (Of course, this is at least better than the other way around -- bad security being perceived as safe!)
There is a trend towards offering OpenID login on social networking sites and such, but I doubt we will see it being adopted very much for protecting extremely sensitive data.
OpenID itself is secure, however due to its decentralised nature it often assumes that three servers are "trusted". If these servers are not trustworthy then your security is gone.
For instance, if you use your own website as an identifier but delegate authentication to a 3rd party provider, then if your website, or the identity provider, or the consumer server is penetrated, then the information is not secure.
If you want to use OpenID internally, and use only your own secure server as an OpenID provider, then you should be pretty secure. But if you want people to "bring their own OpenID account" then OpenID is not the right choice.
In general, it's not really any more o less secure than normal user/password authentication, but with one major difference (IMO). OpenID allows a user to login via multiple different methods (Google, AOL, Yahoo, etc..). If someone were to crack it, they'd have to go after each individual service. You have the option to not allow certain services to participate, in the event you found one of them to be less secure.
I need to work out a way to setup the validation of the users of a web application before they've actually arrived at the site. That is, someone browses to a url, enters a username and password which is then validated against a db or whatever. They are then automatically redirected to the real web application, on a different domain out across the internet, which is passed the details of the user and which then lets them through to the site without asking for the credentials again. And this must be done as securely as possible.
What are the options available for this sort of problem?
Thanks,
What you are describing is a typical use case of intern-domain web authentication. There are multiple ways to do it,
If both domains belong to the same application/company, you can just do your authentication and then pass some token/secret to the other domain in your redirect. The other domain can drop another cookie to maintain the session. This is practically how it's done between different domains all popular websites. For example, flickr.com uses yahoo.com to login.
You can use Identity Federation if the domains are closely related (partners). Most popular mechanism to achieve this is through SAML.
OpenID can also be used (That's how you arrived at this site) if the sites are loosely connected. OpenID uses arcane login URL so it only makes sense for tech-savvy users. The regular user may easily get confused by its complicated login process and consent page.
OAuth is an authorization scheme. It's not designed for federated login but you might be able to use it.
Look up OAuth or OpenID.