Password Management in an Identity-Theft World

The problem

At Plymouth State University we, like many institutions and organizations are facing the challenges of password maintenance for our twenty-some-odd thousand constituents, many of whom may never visit our campus. As our systems become more integrated, password security becomes more important. Today a user accesses everything from address information to grades to financial information all with the same password.

Historically a system was used in which an initial password was set up for users when their accounts were created. In the case of a forgotten password, a user could present a college ID in person (which they had to present a government issued ID to obtain) and we could update their password. This has proven to be time consuming for the IT department and is inconvenient to our growing audience of distance education students and alumni.

Other popular solutions to this problem currently being used at other organizations include the use of security questions, alternate email addresses, or remote assurance of identity by a third party (e.g. notary.) None of these options provide a complete or ideal solution for the following reasons:

Security questions:
– Answers to standard questions like “What is your mother’s maiden name?” or “What is your pet’s name?” can be easily researched or even guessed.
– Offering a free-form question frequently results in overly simple question/answer pairs such as the question: “What color is the sky?” with the answer: “Blue.”

Alternate email address:
– As we provide email services we do not want to require the user to maintain a separate email service.
– Email accounts, especially those associated with an ISP are rarely permanent.
– Email addresses may be re-used resulting in password information being sent to a third party.

Remote identity providers:
– Time consuming, cumbersome and costly for the end user.
– Involves extensive manual processing at the institution.
– Difficult to identify remote identity providers globally.

Another potential solution which has become available is Faces. This is a commercial solution which presents the user with a series of faces to remember. To authorize the user to change their password, they identify the unique pattern of faces they were given to remember. The company claims users have no problem remembering their face-code after two years; however, our user relationship may last 80 years or more. This solution is also likely to be costly.

Our solution

Faced with this password management challenge, Zach Tirrell and I have formulated the following solution.

When a user obtains an account in our system, regardless of their relationship with the institution (student, faculty, alumni, guest) they will receive a username and Password Change Authorization Code (PCAC) through the mail. The PCAC is a 32 character code, unique to that user.

Upon receiving the PCAC, the user is instructed to keep it in a safe place, such as with their birth certificate or social security card. While the user’s account has been created it is initially locked. With PCAC in hand, the user accesses a secure web form on our site. They are prompted for their username, PCAC, and their desired password. Upon entering a password which fits our requirements (capitalization, numbers, etc.) the account is unlocked and the user may now log in with their password.

Users can change their passwords at any time with their current password. If the user has forgotten their current password they can change it with the same procedure as when they set it up, provided they have access to their PCAC. This offers the user the opportunity to change their password anytime from anywhere and frees them from the necessity of either providing personal identifying information over the phone or having to be physically on campus.

Of course we do expect some users will loose their PCAC. A user can request a new PCAC be sent to them at a known address at any time. Even without their current password we would mail a new code to the user. This cannot be done without the time lag of a few days in the mail; however if the user fulfils their responsibility to keep their PCAC in a safe place they should never encounter this delay.

This solution has the potential to increase the security of user passwords, decrease the time to reset passwords, and decrease the amount of human intervention and IT time involved in password maintenance. Perhaps more significantly the responsibility for securing and resetting passwords is put in the hands of the user.

This flowchart (pdf) outlines the entire password process. I have also provided an example of the PCAC here.

This process is still in the design stages here at Plymouth State University. While we are airing it internally we are also looking for outside opinions. If you have any suggestions or comments please leave a comment here, or email me at

To read more about our procedure, check out Zach Tirrell’s post about this procedure on his blog.

Technorati tags: , , , ,

Useful Oracle Security Views

One of the cool things about oracle is that if you have the right privileges you can learn all it’s secrets from the so-called “data dictionary.”

If you’re interested in this then you probably already know what that’s about, so here are what I consider the important data dictionary views for Oracle security:

DBA_SYS_PRIVS – Probably most important, this show system privileges granted to users and roles

DBA_TAB_PRIVS – While the name implies table privileges this actually incorporates view privileges, procedures, packages and functions

DBA_COL_PRIVS – Not always used, but this view tracks grants on columns

DBA_ROLE_PRIVS – This shows who (or what roles) a role has been granted to

These views don’t seem to have changed much from 9i to 10g (or in 8i at that matter) but it is always best to check documentation for your version of Oracle.

Stay tuned for some handy queries to run on these to get quick reports on who can see what.

Technorati tags: , , , , , ,


So what exactly is in those CONNECT and RESOURCE Oracle roles? The ship with every Oracle database and many apps require they be granted. I did a little digging and found the following:

In Oracle 10gR2 things are fairly sane:

In Oracle 9iR2 things get a little scary:

The admin option would allow the users to grant the privlelge to another user. Thankfully neither of these roles have the admin option in the versions of Oracle I checked.

To find these privileges you can query the DBA_SYS_PRIVS table with a query like this:

select grantee, privilege, admin_option from dba_sys_privs where grantee='CONNECT';

Of course an oracle role could also have table or column privileges granted to it, so to be thorough you should also check for entries in DBA_TAB_PRIVS and DBA_COL_PRIVS.

NOTE: You should always check these privileges in your database before granting roles as a script, application or previous DBA may have granted or revoked additional roles.

Technorati tags: , , , , , ,

Oracle Change Tables – An Example

Here is an example of how to create and use Oracle Change tables. This is part of what Oracle refers to as “change data capture” or CDC.

Oracle change tables allow you to capture what has changed in a specific table over a period of time. This can be useful if you are attempting to keep data updated with a source. Typically CDC is used as part of the “extract” process in an extract-transform-load procedure for loading a data warehouse.

There are many sties and articles on this topic that go into much more depth than I will here, however I have never found a fully functional demonstration of an entire CDC cycle.

Change table example code

For more information on change data capture I recommend Oracle’s Data Warehousing Guide. More on data warehousing in general can be found at Mark Rittman’s Oracle Weblog.

A new feature in Oracle 10g called ‘streams’ offers an alternative to this type of CDC, however I (and I’m sure many others) are still dealing with change tables on a regular basis.

Technorati tags: , , , , , ,

Search UNIX without the junk

If you have done much UNIX systems administration you have probably seen output like this from the ‘find’ command:

$ find / -name
find: /proc/tty/driver: Permission denied
find: /proc/sys/kernel/pax: Permission denied
find: /proc/net: Permission denied
find: /proc/4680/fd: Permission denied
find: /usr/local/dh/apache/logs/basic-argon/fastcgi: Permission denied
find: /usr/local/dh/apache/logs/basic-bongo/fastcgi: Permission denied
find: /usr/local/dh/apache/logs/basic-cabo/fastcgi: Permission denied
find: /usr/local/dh/apache/logs/basic-dap/fastcgi: Permission denied
find: /usr/local/dh/apache/logs/basic-adamant/fastcgi: Permission denied
find: /usr/local/dh/apache/logs/basic-emu/fastcgi: Permission denied
find: /usr/local/dh/apache/logs/basic-fritz/fastcgi: Permission denied
find: /usr/local/dh/apache/logs/basic-grog/fastcgi: Permission denied

Annoying, to say the least, that your actual search results may be buried in pages upon pages of this.

Here’s a quick way around this. Redirect the error output to /dev/null (the black hole of data.) It’s as simple as appending ‘2>/dev/null’ to the end of the command.

$ find ./ -name 2>/dev/null

Any errors are ignored, which can complicate troubleshooting, but if things aren’t doing what you want them to, just drop the redirect and run the command to see the errors again.

The command may vary depending on your shell and breed of UNIX, but this has always worked for me.

Easy Linux CommandsFor more tips like this check out my book Easy Linux Commands, only $19.95 from Rampant TechPress.

Technorati tags: , , , ,