very concerning security breach in portal URL

Diana Day

Hello all – we just heard that a middle schooler has discovered a major security problem. If a user looks up a person in the system, whether it's through the directory or via a class page, the URL shows that user's User ID. Not only is that number used for Billing, but more importantly, we use the User ID for door codes and cafeteria accounts. Since a student discovered this problem, word is going to get around about the glitch, and we fear that door code and cafeteria accounts can and will be compromised. We contacted Blackbaud and were basically told that this is a system limitation and that we are welcome to put an idea in the ideas portal! But we obviously can't wait for that. Has anyone else dealt with this problem?

Lauren Henderson

@Diana Day as far as I know, this is how the system has always operated. Do you mean that you are using User ID as the passcode for your other accounts? Alternately, if the other accounts don't have a unique password or code, I would add them into those systems. User ID is a record identifier, not a secure field (obviously).

Kathy Hannon

@Diana Day we don't give access for students to see other students' information in directories or rosters. I just checked with a couple my students and none of them can see a User ID for another student - no way to see in url.

Crystal Bruce

@Diana Day Hi! I reviewed the support case and I am making sure to flag this to the Product Management team as well.

Lauren Henderson

@Kathy Hannon We also have directories restricted so that students cannot access them, and they do not have access to the rosters for their classes.

Diana Day

@Kathy Hannon The information is in the URL. We also do not have the User ID available for students to see. The issue I'm describing is something that is beyond what we can control – seems to be hard coded into the system. The students caught it before any of us saw it – check it in your system. If you visit a profile, the User ID appears in the URL in the browser.

Diana Day

@Lauren Henderson Seems very strange to have a unique ID as something that is not secure.

Diana Day

@Crystal Bruce Thank you so much!!

Eleanor Page

@Crystal Bruce This is also a significant problem for my school. Thank you for flagging this with Product Management.

David Gillespie

@Diana Day Lauren is exactly right. This is literally how software works now. Unique IDs are how courses, people, etc. are referenced and they are definitely not private/secure, they are the official, internal “name" of the object and how it will be referenced to anyone who needs access. They have to use something in the URL, and this is most reasonable. I remember a similar discussion happening several years ago on here. Note that Canvas does exactly the same thing; when I go to users on there, I see “https://hawken.instructure.com/accounts/1/users/6754” - and user 6754 is that person's unique identifier. It's just how API-based systems work. User IDs are not private and should not be used for any passwords or secure purposes. It's like deciding to use someone's house number on their street as their security code - sure, it's (somewhat) unique but it's definitely not private.

Geoffrey Goodfellow

@Diana Day, we use the User ID as the Student ID. It is a record number and they are assigned in sequence by the system, so all the students have a similar Student ID, and it would be very easy for them to guess another. Therefore, like any website login, we use the number as the login User ID and not the password. Just like having an email address prefix that can be discovered by someone else, we don't consider the User ID to be anything private or secure since it is an identifier equivalent to the student's name or email. I know that doesn't solve your immediate problem, but I would highly discourage you from using the User ID as a mechanism for students to login to doors or cafeteria. We use thumbprint scan for our cafeteria charging and prior to that issued plastic Student ID cards.

Marcel Mattern

@Diana Day

Hello everyone! This is Marcel, reaching out as a Senior member of our Education Management Support team. I really appreciate everyone highlighting this inquiry and providing some valuable insight, as I'm sure there are other schools that have utilized a similar set up of having the User ID value also be the Student ID value.

To confirm, the User ID is a unique identifier for each record in our system. This is automatically assigned by our system, and is how the software references each person. While this tends to be visible primarily in Core, we do not have this as a 'public' facing ID since this is just referential data, and it's intended use is for our system to determine which record to pull. We do not have the ability to publish, edit, or hide this value as it is hardcoded, and with current system functionality, we expect to see this in the URL of each contact card referenced by a user. We do not recommend, due to this system functionality, using this identifier for any security or billing purposes, such as passwords or lunch pins, as our system provides this value only for a data reference point on each individual user.

With the Student ID field being on each user's contact card, this field is customizable and accepting of alphanumeric characters, and it also has customizable publishing options on a role-to-role and user basis. Our recommendation will be to create a separate unique identifier for each user in this field, outside of the User ID generated for the system,. This will allow our schools to have an identifier for each student that cannot be referenced in the contact card URL, and if utilizing this value for access to areas of your campus or for billing purposes, you are able to hide this field from other roles in a highly customizable way via Profile Access. This value can be updated using a Data Import, under the User Management Category Student ID Type.

As suggested by a few people in this post as well, a more immediate solution would be to restrict Student access to Directories, as well as rosters, so that they cannot access each other's contact cards. This can be achieved by editing Group Page Access to rosters for the student role, as well as removing access for the student role in the Directory settings. This would be a recommendation for anyone experiencing a similar concern, as we are amidst the 24/25 school year and changing the identifiers associated with billing features and access at the school would not be ideal. Following the conclusion of the current school year, your organization can take action to update student ID values over the summer to provide a better long term solution for your constituents as well.

I hope this helps! I understand that our Support team has created a case for those involved here with current concerns. If there is anything else that we are able to clarify, don't hesitate to reach out on your respective cases, as we are here to help!

Lisa Tulchin

@Marcel Mattern Hi Marcel! Is there a way to keep the Athletic Team roster access, but remove the contact card button for students only? It's so nice to see the team rosters, jersey numbers, the coaches contact info and the kid's faces, but parents and other students don't need the contact card button of other students, especially since we locked it down and there's hardly any information in there.

Marcel Mattern

@Lisa Tulchin Hi Lisa! If you have a question in regards to product functionality for publishing access, I would direct you to contact our Product Support and get a case started with our team. They should be able to address your inquiry as well as any follow up questions you might have on the subject. As long as you are a support user for your organization, you can contact us at 1-800-468-8996, or visit www.support.blackbaud.com for assistance. Hope this helps, have a wonderful day!

Lisa Tulchin

@Marcel Mattern I mentioned it because Athletic Team Rosters are the only rosters we allow students and parents to see, so they will also see the student ID in the URL when they can click on the Contact Card Button. The contact Card button for students is useless otherwise because we lock down all information on it. However, I guess now the kids can figure out the student ID based on the URL. The work around you offered to remove roster access doesn't work because Athletics wants to publish Team Rosters.

Art Bryman

There are 2 reasons why many of us use the User ID as the Student ID.
1. Some student-related functions - like the enrollment import - don't use Student ID:

Section enrollment matching on student user_id, course_code and/or course_title

user_id, school_year_label, term_name, level_description, section_identifier, firstname, lastname, course_title, course_code, begin_date, end_date, dropped, enrollment_type

This forces us to either export both IDs for everything, or keep a conversion file. It's easier to just use the User ID.

2. There's no built-in mechanism to easily create Student IDs. Raiser's Edge handles this really well:

Carolyn Stevens

@Art Bryman - Not sure if this is helpful, but we create student IDs in a spreadsheet using a formula, not the slickest process, but it's super simple. Then we import them to both the STUDENT ID field and the HOST ID field, the latter of which can then be used in import schemas. We also replace the “school student ID” in Tuition Management (aka the user ID) with the STUDENT ID to link to student charges. That way, USER ID can stay as-is.

We (and many other schools) leverage the fact the USER ID is in the user's url for reporting purposes, especially for Power BI. So, I am glad to hear this is not going away.

Art Bryman

@Carolyn Stevens thank you for sharing your process, and I didn't know about using Student IDs in TM. We use Host ID for Raiser's Edge Import ID, which would break a few things.