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?

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.

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.

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.

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!

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.

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.

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.

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.