Forum OpenACS Q&A: Password in ClearText
There are cookie generation routines that can function as shared secrets, are there not? The cookies can be "signed" in some fashion.
While they could well be sniffed, their value would be of little use since they are oneway hashes of a set of values including an IP address; if the attacker could not spoof the IP address sending the sniffed info the information would be useless.
See security-procs.tcl in /packages/acs-tcl/tcl and the other files with security in their names in that package.
Andrew, could you have a look at these procedures and give us your opinion on their usefulness?
I am talking about what happens when you enter your name and password: the name and password are sent as clear text. This is before cookies are created.
If you want security, use https. That's it. It is general, it works, and most of your users are familiar with it. Be happy if your service is so popular that your cpu is maxing out. Othewise you might also check into the new ns_pam module, which may have different security features, but I don't know.
You can handle SSL roughly three ways with OpenACS:
- No SSL, everything is in the clear including the login page.
- SSL only on the login pages, secure, but has SSL only where you
really need it. All ecommerce sites want this.
- SSL on the whole site (except a few particular URLs (e.g., "/SYSTEM/dbtest.tcl") which you have special reasons for leaving open). If you have secret or proprietary content all over your site (e.g., some company intranets...), this is what you want.
It would be good if the stock OpenACS install defaulted to choice 2, above. I'm not sure whether it does or not.
If you don't want to send password across the net in the clear, then using SSL on the login pages fixes that. If there is some other solution which both fixes that, and is preferable to SSL for some reason, please let us know. I'm not aware of any.
As I mentioned, there are some other problems with SSL that would apply even if SSL were the default.
RFC 2617 talks about a method for doing authentication without sending passwords in the clear. The method there is called "Digest Authentication." It's possible to use the core ideas of Digest Authentication in a relatively simple implementation without using Digest Authentication itself. These ideas should not be very hard to implement and are probably much easier to do than the cookie stuff that OpenACS does now (if OpenACS has the stuff that's described in section 4(?) of the openacs.org kernel manual that talks about security).
The vBulletin forums at vbulletin.com have a thread called "Major Password Security Weakness" that's about this topic. (This almost trivial weakness is unfortunately very common among content management systems and bulletin board software.) The second to last post in the thread at vbulletin.com has a description of how to do this kind of authentication. The current URL is http://www.vbulletin.com/forum/showthread.php?t=85515&page=3&pp=40
I will be glad to clarify parts of the discussion but
I am not gonna get into an argument about whether this should be done in OpenACS -- I just wanted to suggest it and see what the response was. If the developers aren't interested in implementing it, then that is fine and I can move along to the next CMS to look at.
But Andrew S raised a good point about OpenACS.org - should it be configured to provide a secure login? As a showcase site I think it is something worth considering. Perhaps something for the next update?
Or we could use digest authentication as mentioned (and I think we should probably provide that as an option since it has some value -- one particularly useful way to use it is to password protect an entire dev site rather than count on the openacs authentication working in dev) but it does mean that the browser will then be responsible for popping up its standard password window. Digest authentication protects passwords but provides very little in the way of security beyond that (although if we issue more restrictive nonce's that is not strictly true). Also I think there are also browser support issues for digest authentication (ns4 doesn't do it iirc)...
Of course if you can sniff the password, you could probably figure out a way of substituting your own man-in-the-middle attack on the digest. Oh, btw, without ssl, how do you get the password to the website in the first place? Is a password replacement is used, this is just as easy to sniff.
Anyway, if you want security, or at least what is accepted as security, you need ssl. It also doesn't matter what fancy thing we do on the website if users don't have browsers which support the login method.
Tom, Digest prevents simple replay attacks. It is susceptible to more sophisticated attacks but it's more secure than "Basic Authentication". And you are right that Digest doesn't solve the problem of how to establish the shared secret in the first place. But just because there are insecurities with this protocol doesn't make it useless -- it is generally a lot better than doing nothing!
First off, I think you must totally misunderstand the way authentication and security are handled in OpenACS. Basic or digest authentication simply will not work with OpenACS. They don't use the same semantics as OpenACS authentication. So authentication to view a page is one issue, this is handled with a the OpenACS permission system. The other is security of the data passing over the network. We have that with ssl.
Is this your only issue with OpenACS, it seems like a non-obvious place to start?
i think the point is that the standard method of protecting data sent over the network is ssl. it may not be ideal, but it works, many people use it, and it doesn't have outrageous requirements of the client.
this is a common problem though, so if you have some suggestions of how you'd solve it or some more information or examples then it might help you to learn how things are working, in what direction they are going, and improvements that could be made to better suit what you're asking for.
I do think we got the ssl side right (with the notion of secure and insecure tokens, an easy way to restrict parts of the site to ssl, and login using ssl by default assuming ssl is available). I think we should have a way to say "disable logins if ssl is unavailable" but I expect that would not be at all hard to add.
Jeff, I guess the question is how would it work? First off, I didn't think AOLserver supported digest authentication. But maybe that isn't what is being talked about here.
I think I'd rather leave it to someone who thinks this is important to actually write up a working example. It seems pretty useless trying to convince someone who prefers MySQL over PG or Oracle to take my word for it anyway.
Andrew S, given all your other reservations about OpenACS listed in another thread, I would recommend looking elsewhere for your CMS solution. This one obviously isn't it. There are lots of products out there that meet your stated needs.
Advice is worth what you pay for it. So here is some: if you visit France, don't complain that they don't speak English. If you visit MIT, don't complain that there are a bunch of geeks hanging around and in your way. And if you don't like the length of your foot, get into therapy.
I'm only speaking for myself here, others are probably nicer than I: you didn't offer any feedback. You haven't said anything of interest yet. You appear to be only interested in picking a fight over non-issues. The only reason I am even responding is that some future potential user may run across your post and believe there is something to your observations. There isn't.
So everyone else: Happy Halloween!
The WebDAV spec requires digest authentication, so I think it will end up as an option with OpenACS and AOLserver. I am looking into it now to see what it is going to take to get it working.
One topic is what OpenACS should do by default. This is mostly what I was asking about in the original post. It seems that a system like OpenACS should default to something that does not send passwords in the clear, but what do I know.
Another topic is what openacs.org should do.
I hope nobody goes out of their way trying to help me find a solution right now -- I am probably going to use something other than OpenACS. Thanks to those that tried to help with passwords.
For actual human beings using an OpenACS website, AFAICT SSL on the login page is by far the best solution, and OpenACS already has a very good solution for this, and indeed has had it for many years, since at least ACS 4.0 if not earlier. Andrew S. seems to dislike SSL for this and states that he would prefer Digest auth. without SSL as the default for the login page. Frankly, I don't understand why, his expressed preference there makes no sense at all as far as I can see.
I don't know enough about Digest Auth. to understand Tom's argument that it has different semantics than OpenACS login and so can't work for OpenACS login. If someone could explain that, I'd like to hear it.
Some reasons for defaulting to sending passwords not in the clear instead of using SSL are:
- SSL requires an expenditure of time and energy on the part of the person setting up the site,
- it is easy to mess up the installation of SSL,
- many people will simply not install SSL, so if the default is to send passwords in clear text, there will be lots of OpenACS installations sending passwords in clear text (and many site owners will not even know it).
my issue isn't whether or not digest authentication is a good or useful solution with benefit, my issue is your insinuation that openacs is an inferior product because it doesn't use digest authentication. this is not true.
besides... the average user knows to look for the "https" up in the browser url of good web sites when submitting security-sensitive data.
if digest really is a benefit, then to implement in aolserver/oacs while either minimizing client requirements or with the ability to disable it for the option of standard ssl would be fine.
I'd say it's also the case that when someone without a clue builds a website, it's likely to attract little attention and in practice the chance of someone using a packet sniffer to grab a password in the clear, log in, and do Something Terrible to such a website are ... very low.
Not that this is an excuse for not using SSL.
But I think Andrew's raising a non-issue here.
It takes some tiny effort to set up SSL, but it's not that hard. The problem with making it as a "default" is that it creates the illusion of security.
This is indeed one of the problems with Microsoft products. They make it "very easy" for a clueless administrator to setup a "sophisticated" and "secure" web site using defaults, wizards, and point and click. But by masking the underlying complexity, the same clueless administrator can easily end up believing that things are working when they are not. When something breaks and there is no "solution by default" at hand, that's when the folly of the easy path becomes apparent.
When it comes to security, having to use your "grey cells" is not a bad thing.