Not logged in
Log in now
Create an account
Subscribe to LWN
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
Posted Jan 8, 2013 10:50 UTC (Tue) by tialaramex (subscriber, #21167)
If you chose a fairly good password, and you weren't first on the list of targets the weak MoinMoin password hashing may have bought you enough time to go change it anywhere else that you used it - nothing more.
I don't know why that Wiki page is called "Secure Password Storage". A few minutes with Google would have told the MoinMoin developers that this fell short of the state of the art circa 1975 let alone today, but then they're competing with PHP software that still thinks MD5(password) is "uncrackable encryption"...
Posted Jan 8, 2013 10:58 UTC (Tue) by epa (subscriber, #39769)
- 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.
Posted Jan 8, 2013 13:19 UTC (Tue) by sbakker (subscriber, #58443)
Posted Jan 8, 2013 14:03 UTC (Tue) by epa (subscriber, #39769)
Posted Jan 8, 2013 14:42 UTC (Tue) by sbakker (subscriber, #58443)
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.
Posted Jan 8, 2013 15:54 UTC (Tue) by epa (subscriber, #39769)
Posted Jan 8, 2013 15:46 UTC (Tue) by tialaramex (subscriber, #21167)
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.
Posted Jan 8, 2013 18:05 UTC (Tue) by drag (subscriber, #31333)
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.
Posted Jan 8, 2013 18:13 UTC (Tue) by pboddie (subscriber, #50784)
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.
Posted Jan 9, 2013 11:26 UTC (Wed) by tialaramex (subscriber, #21167)
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.
Posted Jan 9, 2013 13:59 UTC (Wed) by pboddie (subscriber, #50784)
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.
Posted Jan 10, 2013 1:21 UTC (Thu) by dlang (✭ supporter ✭, #313)
Whatever SSO source you pick, you are going to run into some people who won't use it.
Posted Jan 11, 2013 15:59 UTC (Fri) by kleptog (subscriber, #1183)
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.
Posted Jan 11, 2013 16:49 UTC (Fri) by pboddie (subscriber, #50784)
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.
Posted Jan 8, 2013 19:32 UTC (Tue) by corsac (subscriber, #49696)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds