Re: National Student Clearinghouse authentication changes

[Alex <alex.everett () UNC EDU>]

That sounds like a poor idea.
The GET field as specified by the RFC is intended for providing query data,
not for providing data to a server.
In addition, this could lead to cacheing of the URL, containing the user's
SSN.
Also, most web servers log the GET requests, but do not log the POST data.
Which means, that the SSN would likely also be stored on the web server, and
not just a back-end database.
I don't know the whole story on this or technical details, but those are
some of my opinions.

-Alex Everett, CISSP
University of North Carolina

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Kevin Shalla
Sent: Friday, November 07, 2008 11:01 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] National Student Clearinghouse authentication changes

We refer many students and others to the National Student Clearinghouse
(NSC) to get enrollment verifications.  When we registered for this service,
the NSC offered several options for referring students from our web site.
The one we chose was the client-side authentication, where the student
authenticates (with our standard net ID and password), then chooses the link
to the NSC, then the student enters in the name, date of birth, and SSN.
This helped to prevent anyone not a student at a school which registered for
this service at the NSC to access the service.

Now the NSC no longer offers that option, and is requiring us to switch to a
system where we authenticate the student, then pass the SSN in the URL to
them.  Apparently now they want us to do their authentication for them.  It
seems to me that passing the SSN in the URL would allow the user to simply
modify the SSN in the URL to someone else's and then gain access to the
information for the person with that other SSN.  What are others doing
regarding this NSC policy change?

Attachment: smime.p7s
Description: