Indonesia KTP NIK (stands for Nomor Induk Kependudukan ([National] ID number [for]) Kartu Tanda Penduduk (Citizen ID Card)) is a number that assigned to each of Indonesian Citizen. KTP NIK actually contains a few information such as the location where the KTP (National ID Card) is issued, the holder’s birth-assigned sex, and their birthday date. This number cannot be changed, so in the case where your data got leaked, you cannot change this number.

Since the government keep pushing their one KTP NIK for everything campaign, meaning a lot more stuff will be paired with the KTP NIK. This also means if it got leaked, the impact will be much more severe because now everyone that holds the leaks can just quickly do a single table join to connect the dots with other leaks to get the data correlation 🙃.

So in recap, if you’re happen to be Indonesian Citizen and happens to have your KTP NIK leaked (which is millions impacted already), the data leak owner will have this data, guaranteed:

• Where this KTP NIK is issued (more likely to be your current living region).
• Gender (if the birth date section is >40, your assigned gender is girl)
• Bithdate (DD-MM-YY format)
  i.e Ao Fukai (or Ao Thurston; male) would have something like 120727 (27 June 2012).

… and if in the future all of government services depends KTP NIK, the list will definitely grow :).

One of worst part of the KTP NIK is, you cannot just do a quick, dirty authentication with this information (the “something you know” part) because the KTP NIK already contains your birthday. Birthday is one of the easiest way for auth-ing people because most people will remember their birthday, down to its year.

NISN: the Goat

NISN (stands for Nomor Induk Siswa Nasional, National Student ID Number) is a number that assigned to each active student. This student id number are created to make sure every data that school publishes regarding this particular student is centralized and properly linked to this student.

In my opinion NISN is one example that are properly designed: Not derived from actual student data, regularly rotated¹, and short enough to remember.

There’s this one system that my previous employer made for competition that requires the participant to be a student. A verified student. How do we do that? By make sure they entered their NISN upon registration, and validate it on the spot.

This means we need a way on authenticating arbitrary user that they actually them by asking security question that only they know: birthday! Since NISN doesn’t have birthday date component in them, this option became viable! We can just do a quick API Call to the identity server and verify the birthday date. If it matches, we can continue, if it doesn’t we provide them several ways to resolve this: check your data again, or ask your school operator to fix the data for you.

This benefits everyone: the student have quick and cheap authentication and government get the latest clean data. Student don’t have to wait for account validation or something, because they student status has already been authenticated automatically. So they can focus more on getting more familiar with the application, and back on focusing more on the competition rather than worrying if they need to do a side quest to get their account activated.

More Thoughts

Pairing with Other ID

So, we have both KK NIK (the family registry number), and NPSN (stands for Nomor Pokok Sekolah Nasional, national school registration number), why don’t we use those as a factor for auth too?

In the case of KTP NIK, yes we use those, not because we can, but because we’re forced too. While registering SIM in Indonesia, you’re asked for to provide your KTP NIK and KK NIK pair as part of the activation process. This is quite a hassle because that means you’re forced to enter a 32 digits of number. If only KTP NIK doesn’t have birthday number component on them, we can just use the 16 digit of KTP NIK and birthday date (which is ~24 digits of number, 8 of which are already easy to remember).

This also means that third party able to store the KTP NIK and KK NIK pair on their database, in which, in case of data leak… you’re even more got screwed 🙂

As for NISN (student number) and NPSN (school number), I think that this is not that secure since NPSNs are widely displayed on the school, and people can even search them on this Government Website. So if you happen to know a student’s NISN, and you know the school name, the student’s already screwed. So this is why both of the factors is kept as “only the student knows” as much as possible and obviously this is not the silver bullet for every authentication. I’m just saying that this is a quick, dirty, and cheap solution for relatively low risk of being abused. If it have higher risk, then I’d put more checks and stricter procedure.

Oh also, you can actually find someone’s NISN number on Pencarian NISN (NISN Finder), and Pencarian NISN berdasarkan Nama (NISN Finder by Name), and take a look on what information they need for them to give you the number.

Revisiting the Data Leak Risk

You’ve said that in the case of data leak, KTP NIK have more information from it, but what about NISN? What makes the data leak risk is much more impactful?

As mentioned earlier, if KTP NIK is leaked, you’ll be guaranteed to have your location, sex, and birthday information leaked. In the case of NISN, the severity will heavily depends on the service that holds that data. If the service only stores the student name and its birthday, then that’s the only data that potentially got leaked.

So what makes it more impactful depending on the what data that got leaked. The more data got leaked, the more the attacker can make data correlation. The more the attacker make data correlation, the more value their data will be.

In addition to that, I think this is also the reason why devs should encrypt this field by default. Fields that actually keep somekind of ID Number or string issued by government, that directly tied with that person.

1. KTP NIK also rotated, but I don’t think that it is regularly rotated, it’s just, the condition that it will hit the same number only happens once every century. See the details here if you want to learn more about them. ↩︎