UCF Data Breach - Over 63000 SSN's stolen from students and staff
31 replies, posted
[QUOTE=willtheoct;49681615]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.[/QUOTE]
[quote]SSNs aren't used to verify users, though[/quote]
They are at my school to reset things like your password, at least the last four digits. Which is what I thought this thing was grabbed from in the first place.
I'd definitely argue that they should make a more efficient system if that speed is unacceptable, because someone learning something like your SSN can be really, really horrible for you down the line. A data breech of this magnitude is really, really bad and unlike a credit card getting a new SSN is a huge pain in the ass that many people will not do.
[QUOTE=willtheoct;49681615]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.[/QUOTE]
As an example, Google Drive (and a ton of other Google services) encrypts the personal data "at rest" (meaning when it's being stored on their servers). Why would Google take this action, which requires additional resources, if there was no benefit to security? For marketing? Unlikely given mention of it is buried in a help article and a blog post.
Perhaps because there are tangible benefits to encrypting data when it's being stored and no, encrypting data at rest doesn't make it impossible to access automatically when it's needed, because the encryption key can still be stored somewhere accessible to the server, just not the same place as the data.
So then, how is that any more secure if the key is still stored digitally and connected to the internet?
For one, simply being in a different place may mean an attacker needs a completely different attack to get the key. For example, SQL Injection can allow an attacker to dump the entire contents of a database. But, if the key is stored someplace else (on the filesystem in a configuration file for example), the attacker just has a bunch of garbage data unless they can get the key too.
Another example is backups; data is often backed up and stored someplace. It might be easier to get access to a backup, but again encryption can stop this too, even more so since the key backup shouldn't be stored anywhere near the data.
Security is about defence in depth, meaning many overlapping layers of security are applied so that there is redundancy. At rest encryption is a valid layer of security that can be, and is, used for data that needs to be accessed at a moment's notice.
Though, encryption may or may not have helped for this particular case, it really depends on the attack(s) that were used. They may have even been using encryption.
Sorry, you need to Log In to post a reply to this thread.