| |||||||||||||
Non-iteratedNon-iteratedPosted Jan 8, 2013 10:58 UTC (Tue) by epa (subscriber, #39769)In reply to: Non-iterated by tialaramex Parent article: An analysis of Debian wiki security breach
You need a specialized password storage device which attaches via USB and supports two operations:
- set the password for a given username
- check the password provided for a given username
The device could have some rate limiting to say one check per second for the same username, and 1000 checks per second in total. Surely it could be built using a Raspberry Pi or whatever and then it would just be normal when setting up a server to get one of these devices plugged in and use it for password storage. (To keep the passwords secure even if the device is stolen, it should use pessimized salted hashing for its internal storage, but this is not strictly necessary.)
Of course, many servers these days are virtualized, so Amazon S3 and other cloud providers would need to give you a virtual password-checker attached to your virtual server.
(Log in to post comments)
Non-iterated Posted Jan 8, 2013 13:19 UTC (Tue) by sbakker (subscriber, #58443) [Link]
Um, LDAP over SSL will get you a long way. Rate-limiting ldap_bind() requests is a little harder, I guess, but solving that is less work than designing a completely new protocol.
Cheers,
Non-iterated Posted Jan 8, 2013 14:03 UTC (Tue) by epa (subscriber, #39769) [Link]
Right, LDAP over SSL, but might the machine running the LDAP server not be compromised? The purpose of having a specific piece of hardware which stores and checks passwords, and supports no other operation, would be that even if the host system is 0wned the password store is not accessible.
Non-iterated Posted Jan 8, 2013 14:42 UTC (Tue) by sbakker (subscriber, #58443) [Link]
(My LDAP comment was aimed at the notion of providing the USB device on cloud services. I don't see how you could get the physical USB device accessible from a cloud without using some networking stuff, in which case LDAP is just easier.)
Regarding the LDAP server being compromised or not, that depends on how well you protect/harden your LDAP server(s). I just don't see USB devices on each host scale very well and single sign-on is pretty much out of the question... Unless you attach your USB device to your LDAP server.
Also, how do you synchronise passwords in a HA environment? Given that the storage on the USB device is not accessible, it means you cannot make backups either. If the USB device breaks, that's it. Game over.
And, of course, you are assuming that the USB device has faultless security, and cannot be compromised itself. You still need to talk to it; over USB rather than IP, but buffers being buffers and programmers being programmers, I'm far from convinced there wouldn't be exploitable holes. Holes that would be that much harder to plug, because the device wouldn't (shouldn't!) allow you to fiddle with the firmware. Compare that to an apt-get/yum update to patch slapd.
Non-iterated Posted Jan 8, 2013 15:54 UTC (Tue) by epa (subscriber, #39769) [Link]
All quite valid points. I guess it's not practical to use such a hardware approach. Getting people to sign in with Gmail or Facebook accounts may be a better answer to the problem.
Non-iterated Posted Jan 8, 2013 15:46 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Or, and here's a startling thought (unless you've been paying attention to security research in the last decade or two)
Don't bolt password authentication into every single individual application.
There's no reason (other than laziness on the part of MoinMoin's developers) why it cares about passwords at all, either in the general case or in the specific case of this Debian wiki. We're not talking about a missile launch system, or even a financial institution, it's just a wiki, password authentication was used because it's the "easy" way out if you don't actually care about security.
Every time we sell a hosted version of our main revenue generating service, we walk the partner through the options for how their users can get access to the service. We work really hard to persuade them to pick a single sign-on approach, even if means more work for us, because it's not only a better experience for users, it's a far more secure option for everybody. We don't store any passwords, hashes or password equivalents, the user doesn't end up memorising another password (or more likely, re-using one) and Bad Guys™ can't steal a password because there isn't one.
Yet apparently we're the only ones, since every service _our_ company buys (e.g. video conferencing, travel booking, online training, expense claims) from a big enterprise vendor expects to have its own passwords and its own separate user management, even though that's both wasteful and less secure.
Non-iterated Posted Jan 8, 2013 18:05 UTC (Tue) by drag (subscriber, #31333) [Link]
So what?
You want to force everybody that wants to help update Debian wiki to subscribe to a third party web-based SSO system?
Seems rather big PITA for something that is a effort with international scope like Debian has.
Non-iterated Posted Jan 8, 2013 18:13 UTC (Tue) by pboddie (subscriber, #50784) [Link]
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.
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.
Non-iterated Posted Jan 8, 2013 19:32 UTC (Tue) by corsac (subscriber, #49696) [Link]
Well, to be honest, I don't exactly trust web-based SSO stuff. See for example the SAML vulnerabilities published at Usenix Security this year.
|
|||||||||||||