• UCF Data Breach - Over 63000 SSN's stolen from students and staff
    31 replies, posted
[quote]In an unprecedented data breach at UCF, about 63,000 Social Security numbers and names of former and current students and UCF employees were hacked, officials revealed Thursday. The people whose information has been compromised have not been notified yet. The university will alert them by letters that are expected to be sent Friday, officials said. The University of Central Florida first became aware of the issue on Jan. 8 but waited until Thursday to announce it because officials were finishing their investigation with the help of a national forensics firm a day ago, said Joel Hartman, who oversees information technology at the college. It's unclear who is responsible for the hack - although it likely was done by multiple individuals over time, Hartman said, adding there has been no indication of identity theft so far. Among those affected include about 600 current student-athletes, former student-athletes who last played sports in 2014-15, student staff managers for the teams and other related positions. [/quote] [url]http://www.orlandosentinel.com/features/education/school-zone/os-ucf-data-hack-students-story.html[/url] Woke up to an email from the school regarding this incident this morning. We'll find out if our information was in the leak via the mail, and they set up a call center for us to call if we need any assistance. Everything about this shit makes me embarrassed to be a UCF student.
Watching the video in the article and I couldn't help but notice they forgot to update the twitter name on the template they used. Lol. [url]https://gfycat.com/PoliteLightCricket[/url] Sucks to hear though. Hopefully your information was not in the leak, Frisk.
Finally, being too poor to go to college pays off.
This is why people that vie to ban encryption are ridiculous. Also, why people that DON'T encrypt (or that don't properly encrypt) are foolish as hell.
My girlfriend literally just now registered with them
[QUOTE=phygon;49672442]This is why people that vie to ban encryption are ridiculous. Also, why people that DON'T encrypt (or that don't properly encrypt) are foolish as hell.[/QUOTE] I don't think encryption would have helped here.
[QUOTE=Map in a box;49672481]I don't think encryption would have helped here.[/QUOTE] Why not? we didn't get much detail in the article but if the info wasn't encrypted and stored in a spreadsheet or database somewhere it would have been much easier to get at.
[QUOTE=Map in a box;49672481]I don't think encryption would have helped here.[/QUOTE] If this information was encrypted, they wouldn't have been able to retrieve the SSNs of users. They'd just get encrypted garbage data.
I believe information assigned to you will be obsolete and be replace with biometrics because of problems like this.
[QUOTE=Mattk50;49672500]Why not? we didn't get much detail in the article but if the info wasn't encrypted and stored in a spreadsheet or database somewhere it would have been much easier to get at.[/QUOTE] assuming the hacker got into the database, there is probably a vulnerability that would allow them to get private keys for the databse. If they salted the SSNs, then they wouldn't be able to retrieve them. Encryption(in this case, ciphering I believe) only works for authenticating people, not for keeping data accessible but only to certain people. Security experts: Please excuse me if I fucked up a bunch of terms
[QUOTE=Daysofwinter;49672506]I believe information assigned to you will be obsolete and be replace with biometrics because of problems like this.[/QUOTE] Biometrics are scary easy to fake, and should be usernames not passwords or identifying information. [editline]4th February 2016[/editline] [QUOTE=willtheoct;49672520]assuming the hacker got into the database, there is probably a vulnerability that would allow them to get private keys for the databse. If they salted the SSNs, then they wouldn't be able to retrieve them. Encryption(in this case, ciphering I believe) only works for authenticating people, not for keeping data accessible but only to certain people. Security experts: Please excuse me if I fucked up a bunch of terms[/QUOTE] Salting is something that you do to make encryption more secure, you can't "salt" something without encrypting it(In this case, it would be hashing, a non-reversible encryption). Essentially, a salt would let you protect the data as a whole instead of letting every single SSN get decrypted as soon as they figure one out (this also prevents you from figuring out password banks from the hash of the passwords via rainbow tables) [quote]In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" a password or passphrase. The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.[/quote]
[QUOTE=phygon;49672523] Salting is something that you do to make encryption more secure, you can't "salt" something without encrypting it.[/QUOTE] Right, but you can decrypt anything that is encrypted if you get access to the key and know the encryption algorithm. This is useful for storing data that only one group can decrypt, but useless if someone else knows the key. Then of course, you can make it so NO ONE can decrypt it, by salting it. But I think there's a reason that a university would need to access a student's SSN.
[QUOTE=willtheoct;49672554]you can decrypt anything that is encrypted if you get access to the key and know the encryption algorithm[/quote] Not if the data is saved as a hash. Hashes are non-reversible. The idea goes like this: you want to verify a user. The user signs up and puts in their SSN: 000-000-000-000. This turns into the hash ABCDEFG. Later, they want to change something. To verify, they put in their SSN again, 000-000-000-000. The system returns ABCDEFG, and the user is verified. If a hacker steals the database, they get ABCDEFG but not the SSN. [quote]Then of course, you can make it so NO ONE can decrypt it, by salting it.[/quote] Consider why having encryption that nobody could access would be useless, which is why this statement is false. You can decrypt salted encryption if you know the salt and the passkey so long as the data is encrypted in a reversible way, although typically non-hash data isn't salted because if the passkey is unique then it's not a big deal.
[QUOTE=willtheoct;49672554]Right, but you can decrypt anything that is encrypted if you get access to the key and know the encryption algorithm. This is useful for storing data that only one group can decrypt, but useless if someone else knows the key. Then of course, you can make it so NO ONE can decrypt it, by salting it. But I think there's a reason that a university would need to access a student's SSN.[/QUOTE] they wouldn't salt or hash the SSNs, that'd remove the point of it. you don't decrypt a hash, you crack it. Hashing is not encryption. Salts just prevent rainbow tables from working, and for something like an SSN it'd be stupid easy to crack it. The point of storing the SSN in the first place is because there's a lot of federal requirements for it and having it stored is easier to work with. If the SSNs were encrypted, whatever decrypts them could have been used to recover the SSNs.
I was actually thinking of posting this article too, but figured it was too specific to post
It says current and former students might be affected, but what about students that have applied? Am I affected because of this?
[QUOTE=phygon;49672583]Not if the data is saved as a hash. Hashes are non-reversible. The idea goes like this: you want to verify a user. The user signs up and puts in their SSN: 000-000-000-000. This turns into the hash ABCDEFG. Later, they want to change something. To verify, they put in their SSN again, 000-000-000-000. The system returns ABCDEFG, and the user is verified. If a hacker steals the database, they get ABCDEFG but not the SSN. Consider why having encryption that nobody could access would be useless, which is why this statement is false. You can decrypt salted encryption if you know the salt and the passkey so long as the data is encrypted in a reversible way, although typically non-hash data isn't salted because if the passkey is unique then it's not a big deal.[/QUOTE] Right, and like Map in a box said, the whole problem with this is that the SSN needs to be retrievable. Which is why encryption wouldn't help here. Hashing the SSN would make it inaccessible, and simply encrypting it wouldn't help much if someone has your system compromised.
[QUOTE=willtheoct;49672657]Right, and like Map in a box said, the whole problem with this is that the SSN needs to be retrievable. Which is why encryption wouldn't help here. Hashing the SSN would make it inaccessible, and simply encrypting it wouldn't help much if someone has your system compromised.[/QUOTE] There are ways that allow organizations to encrypt data wtihout only having the hash. There's a reason this sort of thing isn't exactly super common, there are ways to secure this data through encryption (that are very advanced and I am not altogether familiar with to be honest).
[QUOTE=willtheoct;49672657]Right, and like Map in a box said, the whole problem with this is that the SSN needs to be retrievable. Which is why encryption wouldn't help here. Hashing the SSN would make it inaccessible, and simply encrypting it wouldn't help much if someone has your system compromised.[/QUOTE] Encryption isn't limited to being "one-way". Right now you're connected to Facepunch via an encrypted connection; everything (basically) that is sent between you and Facepunch is encrypted. This requires an encryption solution that allows for decryption. If encryption would have helped in this particular case is impossible to answer without more details; generally speaking though using encryption is better than not for highly sensitive information like SSNs. For example, if the SSN information was stored in an encrypted state in the database and the key used to encrypt/decrypt was stored outside of the database, gaining access to the database doesn't necessarily mean an attacker also has access to the key, and without the key (unless there was another failure, like using a bad encryption algorithm or a poor key) the attacker doesn't gain any valuable information.
[QUOTE=phygon;49672709]There are ways that allow organizations to encrypt data wtihout only having the hash. There's a reason this sort of thing isn't exactly super common, there are ways to secure this data through encryption (that are very advanced and I am not altogether familiar with to be honest).[/QUOTE] The hash is the output of a one-way algorithm. You can't use it to recover things. You can only use it to check if the input is (almost certainly) the same as another input. A key allows you to recover things(not from a hashed algorithm, mind you), but if someone can access your encrypted data, they likely also have access to your key, since they would have compromised your system. A hash is useful to check if someone entered a correct password, while making the password non-retrievable. It can't work here. Whereas, encryption is only as good as the thing storing your key. The thing storing the key was compromised, so encryption was, or would have been, useless. There's nothing special that large organizations do, aside from not storing sensitive data, storing data on secure systems, and regularly checking for vulnerabilities. If storing an SSN, for example, you might choose to store it on an offline database, and only let a trusted human access it. You may even choose to store it in a file cabinet, on paper. There's no magic that organizations do to keep things secure. [QUOTE=DaMastez;49672804]Encryption isn't limited to being "one-way". [/QUOTE] I get how encryption works, I just get terminology confused. Don't worry, it's all understood. I'm just trying to explain why neither encryption nor hashing(excuse any bad terminology again) are useful in this situation. And in this situation, storing the key to decrypt SSNs for thousands of students on a non-electronic medium would be terrible at tax time, so assuming it can be accessed electronically, the hacker has access to that in the same way they got to the database.
[QUOTE=phygon;49672523]Biometrics are scary easy to fake, and should be usernames not passwords or identifying information. [/QUOTE] Fingerprints, Dana, my facial features, speech patterns? Not sure how that all can be faked.
I never should have started studying cryptography. It's made me too paranoid. The other day I forgot my password for something, and they emailed me my password in plaintext. This was from my College. And that was the day I realized nobody knows what they're doing.
[QUOTE=willtheoct;49672832]The hash is the output of a one-way algorithm. You can't use it to recover things. You can only use it to check if the input is (almost certainly) the same as another input. A key allows you to recover things(not from a hashed algorithm, mind you), but if someone can access your encrypted data, they likely also have access to your key, since they would have compromised your system. A hash is useful to check if someone entered a correct password, while making the password non-retrievable. It can't work here. [/quote] Yes, thank you, I understand how encryption works, I literally just explained how hashes work earlier in the thread. I was saying that hashes could be used in cases where SSNs are used to verify users (as my college does). [quote] Whereas, encryption is only as good as the thing storing your key. The thing storing the key was compromised, so encryption was, or would have been, useless. [/quote] Not if it was employed properly, in an offline server, as it should have been. There might not be a magic way to make something completely secure, but there are steps you can take to prevent massive data breaches from happening. [quote] There's nothing special that large organizations do, aside from not storing sensitive data, storing data on secure systems, and regularly checking for vulnerabilities. If storing an SSN, for example, you might choose to store it on an offline database, and only let a trusted human access it. You may even choose to store it in a file cabinet, on paper. There's no magic that organizations do to keep things secure. [/quote] Right, this is what I was saying. The bottom line is, this was preventable, and if encryption was verboten this kind of thing would probably happen more often.
Here's hoping my SSN doesn't turn up somewhere strange
Nice. I'll be watching for that letter. :dead:
[QUOTE=KillerJaguar;49672618]I was actually thinking of posting this article too, but figured it was too specific to post[/QUOTE] That's what I thought too, but given we're one of the biggest schools in the country (I think second biggest), and the sheer amount of SSN's lost in the breach, it seems like a big enough fuck up on their part.
[QUOTE=Map in a box;49672481]I don't think encryption would have helped here.[/QUOTE] If they steal a database of encrypted SSNs then they get nothing It should be a law by now that if you are collecting SSNs they must be stored in some form of encryption, idk if it would help but my god there are tons of companies that just store the stuff in plain text There's only like a handful of people who should need to get into your SSN on a campus, everybody else should only handle the student ID number
[QUOTE=Sableye;49675556]If they steal a database of encrypted SSNs then they get nothing It should be a law by now that if you are collecting SSNs they must be stored in some form of encryption, idk if it would help but my god there are tons of companies that just store the stuff in plain text There's only like a handful of people who should need to get into your SSN on a campus, everybody else should only handle the student ID number[/QUOTE] The article implied the data wasn't stolen from the database directly.
UCF finding new ways to fuck up my life even after college. Recently I had to prove to the IRS that I paid for classes in 2013, because UCF claimed I wasn't even a student that year. Their mistake nearly fucked me out of over $2,500 but that's okay I can do their record-keeping for them I guess. It's also worth mentioning that a lot of UCF's shit is run by student volunteers when it really shouldn't be. I wouldn't be surprised if this was also the case in this scenario.
[QUOTE=phygon;49673245]Yes, thank you, I understand how encryption works, I literally just explained how hashes work earlier in the thread. I was saying that hashes could be used in cases where SSNs are used to verify users (as my college does). Not if it was employed properly, in an offline server, as it should have been. There might not be a magic way to make something completely secure, but there are steps you can take to prevent massive data breaches from happening. Right, this is what I was saying. The bottom line is, this was preventable, and if encryption was verboten this kind of thing would probably happen more often.[/QUOTE] SSNs aren't used to verify users, though. For universities, they need to be retrievable, at least so they can be put on tax forms. If you're storing SSNs on an offline server, you have no way of retrieving the SSN in a reasonable time. And that just won't work for thousands of students who need to access their tax forms online, instantly. Therefore, encryption is useless here, and storing things offline is unacceptable.
Sorry, you need to Log In to post a reply to this thread.