Authentication can have three factors: something you are (fingerprint, retinal scan), something you have (your ATM card or these information cards), or something you know (your password or PIN).  Security experts recommend two-factor authentication for important stuff; you use two-factor authentication when you go to the bank, insert your card and use your PIN.  Two-factor authentication means that the password can be a lot simpler, because one of the other factors is acting as a second check.

However, two-factor authentication is not foolproof, either; there have been sophisticated ATM scams where thieves installed a magnetic stripe reader over the normal slot, with a video camera to record the user’s PIN as they type it.  One of the things about information cards is that you may have to use them in untrusted environments; if you’re traveling and want to check your email, nothing will protect you from the hacked machine at the internet cafe where you put in your card.

On campus, IST is developing what they’re calling “second level authentication” which can be used for security-sensitive web-based applications.  This would augment the security of your CalNet ID; for a sensitive application like HRMS, you would log in with your CalNet ID, but then also input a PIN using an on-screen keypad.  This does not qualify as two-factor authentication, because both authentication tokens are “things you know,” but it should make those applications somewhat safer.

There is also a significant effort underway on campus and at UCOP to set up an “identity management” (IdM) system.  IdM attempts to combine authentication (verifying who the person is) with authorization (verifying what the person should have the rights to access).  Right now CalNet is basically an authentication system; each application which uses CalNet ID must maintain their own list of which CalNet IDs are allowed to access the application.  IdM would provide a central place to store information about each user’s access rights, and also provide a way (through “federated identity management”) to communicate authorization to external entities, like UCOP or a third-party vendor.  UC Davis recently did a pilot to see if GMail could provide email for students; in the pilot, students were able to use the UC Davis equivalent of a CalNet ID to log in to their UC Davis GMail account.  Federated IdM has come a long way in the last year or two (mostly through the Shibboleth project), and I expect we’ll start to see many more of these kinds of arrangements.

The new rates are:

• Annual Desktop Support: $1410/year (was $1290/year in 07-08, $1320/year in 06-07)
• Unix and server administration: $89/hour (was $83/hour in 07-08, $75/hour in 06-07)
• Web and database development: $77/hour (was $70/hour in 07-08, $70/hour in 06-07)
• General hourly work: $75/hour (was $70/hour in 07-08, $69/hour in 06-07)

(See our “What we do” page for descriptions of these services.)

Our strategic planning process is nearing a close, and we are beginning work on a significant reorganization of LSCR’s business.  We expect to develop a significantly improved financial and support model that better meets the needs of our customers and the College.  I think we’ll have something specific to talk about in the next month or so.

The tactic is used primarily because mail with a legitimate From address is more likely to get through spam filters.  In general, the spammers are not targeting any individual or institution; they’re just doing whatever they can to improve their chances of having their messages delivered.

Users who are victimized by large amounts of backscatter often worry that their computer was broken into, or that they  have a virus.  Generally, backscatter does not indicate any problems with your own computer or mail server.  There have been some cases where a virus sent out messages designed to look like backscatter, with the virus payload as an attachment to the message, but even these cases were not a problem for users unless they clicked on the attachment.

As with most spam issues, backscatter is a pernicious problem.  When we send out a legitimate email that doesn’t get through, we want to get a bounce message that informs us of the problem, so we can resend or readdress the message.  It’s quite difficult for mail servers to tell the difference between a legitimate and an illegitimate message, so as long as mail servers are configured to deliver bounce messages, and as long as spammers are still spamming, backscatter will continue to occur.  We are looking at moving more of our mail services to the CalMail domain hosting environment; CalMail has better spam protection than we can easily implement at the departmental level, including better protection against backscatter.  Unfortunately, there is no magic bullet; CalMail users also experience spam and backscatter problems, though generally with less frequency than our other mail server users.

For now, our best weapon in the spam wars  remains the same; take a deep breath, let it go, and hit the delete key.

To ease the transition for our users, we have devised a way to allow two web servers to co-exist on the same machine.  (Geek aside: to do this, we’re using Apache’s reverse proxy directive, ProxyPass).  Our current plan is to put the PHP 5 -based server into production on Wednesday, April 23 at 5:00 PM; we will continue to keep the old server running so that any sites which have problems under PHP 5 can continue to run until their code is fixed.

In most cases, code that works with PHP 4 should work with PHP 5, but there are exceptions.  We know that the development framework LSCR has been using for our web team’s internally-developed applications (such as our department directory, news+events system, and course listings) does not work under PHP 5; we are in the process of migrating our code to the Zend framework.  If you are one of our web customers, we will be contacting you about migrating your department’s applications to the new framework.

If you are managing your own PHP code, or your own installation of a PHP tool like WordPress or drupal, it might be a good idea to test your code on our development server, which is already running PHP 5, sometime before April 23.  Mail sysadmin@LS if you’d like to get set up on the development server.

If you do nothing, your site will be migrated on April 23, and it’s possible that it will work just fine, but we would recommend that you check and test for problems.  Most problems should be minor and quickly fixable; if you have major problems after the migration, contact sysadmin@LS and we can temporarily put your site back on the old server to give you time to deal with the issues.

Many L&S academics are still using socrates, usually as a place for simple web hosting for their individual or lab home pages.  It does not appear that there will be a simple migration path for those users; IST’s announcement of the abatement, and the lack of a clear migration path, generated a lively discussion on the campus Micronet mailing list.

In response, IST will be holding a Socrates Customer Forum on  Tuesday, April 8, at 10:00 AM in Sibley Auditorium (Bechtel Engineering Center).  If you are invested in web hosting or other services provided on socrates, especially web hosting, it may behoove you to attend that forum.

If you simply need to be able to use a Unix command line, there are probably reasonable alternatives for you; Mac OS X is a full Unix environment, and if you use Windows you can install the Cygwin environment to be able to work in a Unix-like way.

The final version of PHP 4, version 4.4.8, was released in January and was recently installed on our main web server. The PHP development team has committed to providing security patches for 4.4.8 until this August; after August, using PHP 4 will be a violation of the campus minimum security standards. That situation gives us a fairly hard deadline for migration, and we’d like to be migrated well before then.

We have set up a development web server running Apache 2.2.8 and PHP 5.2.5 to allow departments to test their sites with PHP 5. Contact sysadmin@LS if you are interested in getting set up on the development server.

Our target date for cutting over to PHP 5 will be May 1, 2008. At that time, we’ll put PHP 5 in production on our main server, and any of your PHP code which is incompatible with PHP 5 will break. I expect that most sites will continue to work fine, with perhaps some small glitches, but it’s impossible to know unless you test your code beforehand.

We’ll be sending more communications about this change-over as it approaches.

Due to the aging of the technology, AWS is going to be replaced by Central Authentication Service (CAS); the tentative date for the deprecation of AWS is December 31, 2008. Moving from AWS to CAS will require some changes to all the applications currently using AWS; the changes should be fairly simple to implement.

The biggest advantage of CAS is that it provides single sign-on to all applications using CAS; that is, once you’ve logged on through CAS once, if you visit another web site which uses CAS, you won’t have to retype your password. This will be a boon for most users, especially those coming in through AirBears who’ll have to use CAS to get on the network in the first place.

If you have an application that’s currently using AWS, you should look at the links above to start working on migrating to CAS. Both services will run in parallel for at least the rest of this year; you can move to CAS at any time. It probably makes sense to move sooner rather than later, since CAS provides better functionality.

All of these alternate addresses have been basically equivalent until now; you could use any of them in your From: address, and anyone sending you mail could use any of them to address you. They all wind up in your CalMail inbox. Going forward, most of this will still be true; mail sent to user@uclink will still be delivered to user@Berkeley.EDU. The change is that, due to anti-spam provisions in the mailing list system, you will need to subscribe to the mailing list with the same address you use in your From: address in your email client. There are mailing lists which have been in existence for many years which are filled with @uclink and other legacy addresses; CalMail’s current plan is to replace those email addresses on mailing lists in bulk. (Scheduled for February 28).

What that means is that if you currently have your From: address set to be user@uclink, on February 29 (happy leap year!) mail you send to (most) mailing lists on lists.berkeley.edu will not be delivered–it will be held for approval by the list owner.

The easiest thing to do is just to set your mail client to use user@Berkeley.EDU as your From: address. It looks nicer that way, anyway. Bernie provided rudimentary instructions if you want to do it yourself, or you can contact your LSCR support team for help. Note that if you do this before February 28, you may have the same problem sending to mailing lists until the change is made, so it’s best to wait until the end of the month.

Dear HENRIETTA TWITTLEWHEEZE

The Software Assurance (SA) portion of the current three year UC Microsoft Select license agreement will expire on January 31, 2008.

Select SA coverage provides you with the right to upgrade to newer versions released during the term in which you own SA. SA is valid for the term of the agreement, purchased in one, two or three year increments depending on when during the three year agreement period you purchase the license with SA. Renewals are all for the full three year period. SA also provides you with certain learning tools and trainings that Microsoft makes available to customers who own SA.

If you purchased or renewed Select SA coverage at any time from January 2005 through December 2007 and wish to renew that coverage, *you will need to submit your renewal order to CDWG by February 26, 2008* to ensure process time before the deadline with Microsoft.

Your order(s) that need to be renewed are:
Q5877392

Items ordered were
ACAD MS SEL VIRTUAL PC MAC LIC/SA 1Y

I think I can speak for the majority of our departments when I say: Huh?

What happened here is that the department (often unwittingly) purchased a license for Microsoft software that includes Software Assurance (SA) for one year. (That’s what “SA 1Y” means at the end of the license). Usually this was unintentional and caused by the confusing CDW-G price lists. What it means is that you purchased the right to upgrade your software to the latest version, for a period of up to one year. (Actually, it’s not really a full year; it’s whatever portion of the year was left until January 31, and it’s not pro-rated). If you renew your SA (by paying an additional license fee), you’ll continue to have the right to upgrade to the latest version; if you don’t renew, you’ll have to buy a new license when you want to upgrade.

Our general recommendation on SA is, don’t buy it unless there’s a specific reason to. The way the pricing works is that you pay almost double the stand-alone license cost for the right to upgrade to a future version you don’t even know you’ll want. Better just to buy the stand-alone license, and buy another one when you know you want to upgrade. (Back in the old days, you could buy a cheaper upgrade, but Microsoft and most other software companies have done away with upgrade pricing.)

But, if you got one of these messages, you already bought SA, so what should you do? First of all, you should make sure you have the most recent version of the software; you’ve purchased the rights to it, so grab it before your rights expire. If you already have the latest version, you probably don’t need to renew SA; you can just buy a new license when the time comes.

Licensing is one of the issues we’re examining as we develop a strategic plan; this situation highlights the high cost of managing and keeping track of software licenses the way we currently do. I would like to move to a model where a standard suite of software licenses is paid for centrally or included in our yearly rates, so that departments don’t have to spend so much energy on these kinds of issues. It will take a fairly significant reworking of how computing in L&S is funded, but I think we can do it.

If you have public mailing lists, you’ll have to update the instructions you publish about how to sign up for the list. You’ll also want to familiarize yourself with the new interface for approving subscriptions and moderating postings, if you use those features. You will find it a lot easier in the new system once you get used to it.

The team has been working on this migration for over two years; the fact that it is now here will enable a number of other projects to move forward. Most importantly, Calmail is now very close to being able to realistically replace the functions of most departmental mail servers. CalMail is much better positioned to be able to deal with anti-spam and anti-virus protection schemes, and there is no way we can compare with the 24×7 support the service is offered. There are a few more technical details to work out, but we expect that we’ll move most of the email domains that we currently run on L&S hardware or departmental hardware over to CalMail’s departmental domain service over the next year or so. I encourage any of you who are still running your own mail servers to consider whether CalMail can meet your needs.