[Mac_crypto] OSXPASS on SourceForge

R. A. Hettinga mac_crypto@vmeng.com
Tue, 13 Apr 2004 21:48:19 -0400

--- begin forwarded text

To: macos-x-server@lists.apple.com
From: Dale Musser <dale@eyebits.com>
Subject: OSXPASS on SourceForge
Date: Tue, 13 Apr 2004 19:43:12 -0400
Sender: macos-x-server-admin@lists.apple.com
List-Id: for administrators of Mac OS X Server and related technologies.
List-Post: <mailto:macos-x-server@lists.apple.com>
List-Help: <mailto:macos-x-server-request@lists.apple.com?subject=help>
List-Subscribe: <http://www.lists.apple.com/mailman/listinfo/macos-x-server>,

I found out from Stale Bjordal and Nico Rozendaal that OSXPASS was
being discussed on the macos-x-server list and thought I'd jump in with
some information and a request...

OSXPASS is available if you go to

If you go to http://osxpass.sourceforge.net/  you will get a directory
listing with nothing in it.  This is because I haven't put up a web
page in SourceForge for the project.  (I guess  I should do that...but
we all know about the shoemaker's children :)  But, accessed via the
project page you can get what you need:

Some notes:

OSXPASS is written in C.  This was done to avoid some security risks of
getting password info in a form, going to a CGI/PHP/JS script and then
having to run an external executable.  I did that at first and got
screamed at about possible security issues.  In the current version
(2.1) the CGI contains all of the code for generating the page, getting
input from the user and performing the password change.  This avoids
the possibility that someone will enter code for a password or user id
that would be passed to a system call to run an external command.  I
have also paid attention to things like buffer overflow problems.  The
input from the user is limited to the number of characters of my
buffer.  More is discarded...plus I put room at the end of input
buffers.  So, I don't forsee any security problems.  But, if you see
one that is possible I *definitely* want to know about it.  I will fix
problems that arise and do new releases.

The password change mechanism is based on code from 'passwd' which is
available from Apple under an open source license.  Essentially I put a
web interface on the guts of 'passwd'.

You can modify the interface by creating new images held in the images
directory.  If the images are the same size they will work in the
interface.  I'd appreciate keeping a reference to 'eyebits studios' in
there somewhere though.  In a coming version I will use an external
HTML template for the interface so you can customize it at will.  The
current version was done as quickly as I could because I have customers
that demanded a way to change their passwords and I needed to write
something to solve the problem I had for email only users.  One note
reminded me of other users...such as those who have accounts to access
the system from other computers such as Windows users who access SAMBA
shares.  So, although I wrote this for the problem of password changes
for email-only users, there are probably a lot of other users who could

You are strongly urged to provide access to the application through
your site using SSL (https).  Otherwise, the password info will be
passed in plain text.  My own site for password changes uses SSL
encryption (https) and works fine.  For those of you who want to see
what the application looks like go to:  http://eyebits.com/support and
click on the Change Email Account Password link on that page.  It will
redirect to the CGI accessed under https.  Certificates for setting up
SSL can be found inexpensively ($40-$60/year).  So, there is no reason
not to be using SSL.  Self-signed certificates can be used to set up
https, but a self-signed certificate will not work under Internet
Explorer (on the Mac...maybe on Windows too).  If IE doesn't know the
cert and you say 'yes' when told so, it actually reverts to non-SSL
transactions.  This problem does not occur if you use a self-signed
certificate with Safari if you accept the certt when told it is
unknown.  So, the lesson is that one should use a commercial
certificate.  Self-signed certificates are a good way to practice
setting up https if you have never done it before.  But, once you know
how to do it, go live with a commercial certificate.

So far, the problems that have been reported...and then later resolved
by my working with the individuals were a result of:
- misconfiguration of the web server to access the CGI
- rights and ownership on files being wrong
- one instance of having a corrupted CGI file

But, if you see anything that doesn't work right for you (regardless of
whether it is a problem with the CGI or something you have done) I
would love to hear about it.

The request:
Please let me know of any features or things you want OSXPASS to do
that it does not do.  I plan to keep supporting OSXPASS until Apple has
a similar solution that is available with OS X Server.  (BTW, a request
for the need for this kind of functionality has been passed along to
Apple Engineering.)

Some of what has already been requested by users of OSXPASS:
-  enforce and communicate new password rules in the interface. (E.g.
tell the user why their new password is not acceptable and give them
the rules.)  Right now it just fails saying password or ID is wrong if
new password is not acceptable.
- possibly allow an admin to define additional rules they want
enforced...so new passwords can be more restricted than Password
Server/Open Directory allows
- configurability of the interface...use a template that admins can edit

Thanks to those of you who have shown an interest in OSXPASS.



Dale Musser, Owner
eyebits studios
301 S. Elm St., Suite 510
Greensboro, NC  27401-2696
+1 866 eye bits    Toll Free Voice/FAX
+1 336 272 5670 Voice - Greensboro, NC
+1 336 510 1472 Voice - Greensboro, NC
+1 650 331 0519 Voice - Bay Area, CA
+1 336 254 1693 Cell
macos-x-server mailing list | macos-x-server@lists.apple.com
Do not post admin requests to the list. They will be ignored.

--- end forwarded text

R. A. Hettinga <mailto: rah@ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'