Forum OpenACS Q&A: Password in ClearText

Request notifications

Collapse
Posted by Andrew S on
Hi..

I'm looking at content management systems and noticed after some packet sniffing that OpenACS, like many other systems, sends passwords in the clear.  Security by default is something I look for in a CMS.  How about changing things to avoid sending passwords in the clear, e.g., by using Javascript and server and client nonces as in Digest Authentication?

Collapse
2: Re: Password in ClearText (response to 1)
Posted by bill kellerman on
or ssl.
Collapse
3: Re: Password in ClearText (response to 1)
Posted by Andrew S on
I did not have SSL in mind.  SSL with OpenACS is not security by default.  That is security by the user of OpenACS spending time and possibly money to set up SSL in an error-prone process.  Using SSL also eats up CPU time.
Collapse
4: Re: Password in ClearText (response to 1)
Posted by Patrick Giagnocavo on
Correct me if I am wrong, but there is some security available without using SSL.

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?

Collapse
5: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Hi -

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.

Collapse
6: Re: Password in ClearText (response to 1)
Posted by Tom Jackson on

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.

Collapse
7: Re: Password in ClearText (response to 1)
Posted by Andrew Piskorski on
Andrew S., in what was way is "SSL with OpenACS not security by default"? Are you complaining about the install docs, or you just don't like SSL, or what?

You can handle SSL roughly three ways with OpenACS:

  1. No SSL, everything is in the clear including the login page.

  2. SSL only on the login pages, secure, but has SSL only where you really need it. All ecommerce sites want this.

  3. 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.

Collapse
8: Re: Password in ClearText (response to 1)
Posted by Andrew S on
SSL is not security by default because by default most people won't use SSL at their OpenACS site.  This web site here at openacs.org doesn't.  At least, when I logged on here, a packet sniffer showed the password going by in the clear.

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.

Collapse
9: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Oh, Tom Jackson mentioned the ns_pam module..  This is a bit of a side discussion since I think OpenACS's default should be to not transmit passwords in the clear.  On the other hand maybe ns_pam would help me even if it does not help the default OpenACS installation.  So I would like to find out a bit more about this.  I'm not familiar with how ns_pam would work with OpenACS.  Would passwords be transmitted from the client to the OpenACS server as they are now, and then used by OpenACS once they are received?  Or is some other system used?
Collapse
10: Re: Password in ClearText (response to 7)
Posted by Lars Pind on
Yes, we now default to login pages over SSL, when SSL is installed.
Collapse
11: Re: Password in ClearText (response to 1)
Posted by Raad Al-Rawi on
To be fair, I think most people/organisations running OpenACS who require a secure login *will* use SSL - that's my impression anyway and that is what we have done at Cambridge University here in the UK. If you just have SSL running on the login page and one or two others, the performance hit is insignificant.

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?

<Raad>

Collapse
Posted by Jeff Davis on
Keep in mind that if you want to have passwords which are not sent in plaintext and don't want to use ssl you will have to have some javascript to do it, which would mean people with javascript turned off would not be able to log in to your site (well at least as far as I can see).

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)...

I think the javascript hashing of the password is a waste and digest authentication has some value but it's not without some real drawbacks too.

Collapse
13: Re: Password in ClearText (response to 1)
Posted by Tom Jackson on

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.

Collapse
14: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Lars, that is good news about the login pages using SSL if it's available.  I was wondering: when is the determination made about whether or not to use SSL?  For example if SSL is incorrectly installed or is uninstalled, does openACS stop using it automatically, or is this something that is settable in the admin panel?  (I'd hope the latter so that an error would be generated if SSL were not available.)

Jeff, that's right, OpenACS could use either Digest Authentication, or JavaScript for a home-brew implementation.  Do the major browsers not support these?Possibly there could be issues with Digest and old versions of Netscape, since as I recall Netscape had some complaints with the protocol, but I think these were resolved years ago, e.g., 1999 or so.  Really old versions of other browsers don't support it either since the protocl didn't exist.  I am not sure why you think Digest-like hashing in JavaScript is a waste -- it would acomplish essentially the same thing as Digest.  I do agree that having the option to use Digest in OpenACS would be nice.

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!

Collapse
Posted by Tom Jackson on

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?

Collapse
17: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Tom, it is possible that I am confused, but I am not confused about the name and password being sent in clear text over the network.  What I am talking about are ways to avoid that.  I am not talking at all about what happens after that, e.g., user groups.
Collapse
Posted by bill kellerman on
hi andrew.

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.

Collapse
19: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Thanks Derek.  I thought that I already did those things though -- I explained why SSL is not a good solution for this problem and explained some other solutions that might be better.  Did I miss something?
Collapse
Posted by Jeff Davis on
Tom, it's not at all clear to me why you couldn't use digest authentication on the page that grants the auth token. Maybe you could elaborate here on why that wouldn't work...

Andrew, I say javascript is a waste since most of the painful authentication experiences I have had have been with ecommerce sites who have "rolled their own" in javascript. Of course you can say "just get it right and everything works smoothly and if someone turns off javascript they just can't use the site" but I think given that ssl will just work and is in fact much more secure it's a waste to add something that will definitely lock some people out and provides only a moderate amount of security and especially a waste if we could make digest authentication work for granting auth tokens.

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.

Collapse
Posted by Tom Jackson on

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.

Collapse
21: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Tom, I am just giving feedback and asking questions about what is going on.  If you don't like the feedback, that is fine, but to suggest that there shouldn't be feedback in the first place is a bit ridiculous.
Collapse
Posted by Tom Jackson on

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!

Collapse
23: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Oh well.  We have gotten way away from the main thread.  If you want to continue personal attacks that's fine, but it's not very interesting or informative.
Collapse
24: Re: Password in ClearText (response to 1)
Posted by Dave Bauer on
Jeff,

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.

Collapse
25: Re: Password in ClearText (response to 1)
Posted by Jun Yamog on
I am not too sure about this.  But would the external authentication module may satisfy Andrew's needs.  Create's a custom authentication module plugs through ext authentication?
Collapse
26: Re: Password in ClearText (response to 1)
Posted by Andrew S on
There are at least three different topics.

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.

Another topic is how to solve my needs.  If I were going to use OpenACS, the best situation would probably be if OpenACS used a JavaScript digest-like protocol, or Digest, by default.  The next best option is probably to use SSL for the login sequence and to not use SSL for the rest of the site.

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.

Collapse
27: Re: Password in ClearText (response to 1)
Posted by Andrew Piskorski on
There has been some recent discussion on the AOLserver list about exposing the necessary API hooks so that Digest Authentication could be more easily added. Someone mentioned there that Digest Auth is likely to be needed for many server-to-server protocols that are becoming more popular. (I don't remember if that included just WebDAV like Dave mentions above, or other stuff too.) So on an OpenACS site maybe human users would never use it, but various web services would.

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.

Collapse
28: Re: Password in ClearText (response to 1)
Posted by Stan Kaufman on
Andrew, here's a brief summary of digest authentication with links to the full RFCs: http://frontier.userland.com/stories/storyReader$2159
Collapse
29: Re: Password in ClearText (response to 1)
Posted by Andrew S on
Thanks Stan.  I had seen those links.

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).

If JavaScript isn't widely implemented in browsers, then it's not a good solution.  I thought though that JavaScript was in fact widely implemented.  For example, vBulletin, a widely used bulletin board package, sends md5 hashes of the password from the client and it appears to me that it must use JavaScript or something like it in order to compute the hash.  (What vBulletin does is very weak and is only a small step up from sending passwords in the clear.)

Collapse
Posted by bill kellerman on
it is the responsibility of the the web site owner to understand the level of security in the operating system and applications.  anyone who "will simply not install ssl" is actively taking a risk with the security of their data, and laziness or lack of technical skill is not an excuse.

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.

as far as javascript, not everyone enables it or uses a modern browser.  i work for a university and we are required to cater to the end user's lowest common denominator so ssl is our best option for secure connections.

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.

Collapse
31: Re: Password in ClearText (response to 1)
Posted by Don Baccus on
To build on Derek's response ... we do target the web developer with a clue.  I think Andrew thinks we should aim lower - as folks working on "website in a box" type solutions typically do.

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.

Collapse
32: Re: Password in ClearText (response to 1)
Posted by Alfred Essa on
The logic here is twisted. There is no such thing as "security by default" in software or, for that matter, in life.  I for one would not trust someone to run a web site who thinks in those terms.

The standard way of encrypting login passwords on a production web site is by using https and ssl. Forget JavaScript and Digest Authentication.

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.