| |||||||||||||
Non-iteratedNon-iteratedPosted Jan 8, 2013 18:13 UTC (Tue) by pboddie (subscriber, #50784)In reply to: Non-iterated by tialaramex Parent article: An analysis of Debian wiki security breach
LWN uses usernames and passwords: are the developers of this site lazy, too?
In fact, MoinMoin supports a variety of single sign-on technologies and alternative authentication mechanisms that don't involve having to be concerned about how you, as the person deploying the Web application, will store your user's passwords. That said, you then have to integrate applications with the authentication infrastructure which is sometimes easier said than done. And for a lot of sites, if you go for something like OpenID, you also have to tell your users to go and make identities with other services who will, of course, want you to provide credentials that they store in a hopefully secure fashion.
It also doesn't help that the various single sign-on technologies are a stew of continuously changing aspirations, features and the occasional nod in the direction of backwards compatibility. Coincidentally, I am currently investigating one of the favourite federated authentication technologies and the available Free Software client (relying party) and server (provider) solutions, and it's hardly surprising that most people would rather not even look at such things given the breadth of homework required to not only figure out what the solution is supposed to be doing but also to deploy it correctly with only minimal and vague documentation (and not to mention fight with bizarre Web framework behaviour).
So yes, we could encourage everyone to not write their own password storage code and instead delegate authentication to other services or, at the very least, to well-documented, portable, easily-deployed libraries that everyone knows about, uses and supports. However, until such time as the grunt work involved in delivering these usable libraries and services has been done - a prime candidate for paying people instead of having them or others paid to ruin the Linux desktop, or whatever it is that we like to complain about - one can't blame Web application developers for working within the constraints of their domain - presumably not getting paid to do everything in the absolute best way possible while also meeting demand for new features and the stuff people also want (because they saw Facebook do it, or whatever) - and providing the option for only moderately secure password storage.
I think we'd all like to be able to do everything to the best of our ability all the time. Unfortunately, no-one ever seems to pay the rates required or permit the necessary working conditions, at least in my experience.
(Log in to post comments)
Non-iterated Posted Jan 9, 2013 11:26 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Yes, this site is lazy too, but it _does_ have the marginal excuse of protecting financials, LWN takes credit card payments for its subscriptions and I can see why somebody might not be comfortable authenticating users via an out-of-box third party solution like OpenID in that scenario.
The wiki situation, like web forums, is not like that. The tired excuse is trotted out, "We don't want to inconvenience our users" which ignores the fact that the _only_ reason this doesn't inconvenience ordinary users is because they've learned to type "pa55word" into the box whenever prompted and as a result they have no security anyway (and so MoinMoin contributes to other break-ins all over the web and perhaps beyond). If you don't care about their security why waste their time with the login box at all?
The excuse that it's easier for the developers is stupid, it portrays the situation as "secure password handling is easy, everything else is hard" when in fact the situation is that MoinMoin never really offered secure password handling as we've seen above.
Non-iterated Posted Jan 9, 2013 13:59 UTC (Wed) by pboddie (subscriber, #50784) [Link]
I didn't make the excuse that it is "easier for the developers"; I stated that most people deploying Web applications don't feel the need to integrate those applications with other authentication solutions, and so they will use whatever is provided. The provided functionality could probably be better, but I imagine that there are more people wagging their fingers than working to improve the situation amongst the many different solutions deployed on the Internet today.
As for integration with identity providers, apart from leaning heavily on Google and Facebook, for it to be commonplace the various solutions would have to be a lot easier to deploy - particularly under the conditions currently experienced by those deploying Web applications - than they currently are. Even the commercial solutions can be dreadful: on one project I was involved in, the large vendor concerned had to get consultants in from abroad because there was no-one in the entire country who could offer the necessary assistance.
With things as they are, I think it is somewhat optimistic to expect people - those deploying applications, of course - to enthusiastically abandon the simplest thing that works for them and somehow hook up their application to an inscrutable stack of authentication components with varying levels of documentation for a technology that, if not properly digested, will have people wagging their fingers once again that the resulting solution is insecure because some aspect of the configuration was not fully understood.
All this reminds me of people trying to fathom why organisations buy monolithic solutions (often not very nice and even rather maintenance-intensive) from vendors instead of piecing together freely available tools. No amount of pointing to "how to" documents and calling people stupid is going to change people's behaviour in situations like that.
Non-iterated Posted Jan 10, 2013 1:21 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I own a tablet that I can't login to the support site for it, because they have opted to require SSO with facebook, and since I don't use facebook I can't login to the support site.
Whatever SSO source you pick, you are going to run into some people who won't use it.
Open-ID Posted Jan 11, 2013 15:59 UTC (Fri) by kleptog (subscriber, #1183) [Link]
Getting Django to work with OpenID is trivial, there's are modules for it.
I used django_openid-consumer and I got it working in an afternoon, and I wasn't even using the integration.
So I think, yay, don't have to deal passwords, lost passwords, changing password, encrypting passwords, etc. And then I get people complaining that they don't want to use OpenID because it lets the provider know that you're logging in, and so they asked for username/password mechanism.
What's a developer to do in this situation? People can set up their own provider, but no. The set of people who don't trust OpenID providers and don't want to setup their own is apparently larger than I thought.
Open-ID Posted Jan 11, 2013 16:49 UTC (Fri) by pboddie (subscriber, #50784) [Link]
To be fair, OpenID is a well-trodden path (unlike various other technologies that shall remain nameless), and there appear to be plenty of OpenID solutions, although many of them seem to rely on the same set of fundamental libraries, so that doesn't mean that the technology is necessarily well-understood even if the amount of common experience is considerable.
Sadly, like everything else, the original simple idea has raced away leaving a lot of people to abandon the idea of running their own provider, and it also doesn't help that people who supposedly accept OpenID sometimes reject identities from providers other than the big names because, paraphrasing one explanation I heard at one point, "you can't trust providers you've never heard of before". Obviously, OpenID is just about the identity and not whether that identity can be trusted with anything - something a Google-minted identity isn't going to help you decide anyway. And let us not consider the expanding interoperability matrix and all its accompanying problems.
I think we're going to see a lot more discussion around trust and decentralisation - for example, whether it is prudent to delegate any control over one's identity either by using a big-name service or by running one's own Internet-resident service on someone else's server - as people begin to question the centralised nature of their Internet interactions.
|
|||||||||||||