> For the complete documentation index, see [llms.txt](https://cdef.gitbook.io/2023-1st-cdef-magazine/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cdef.gitbook.io/2023-1st-cdef-magazine/cyber-horizon/mengenal-lebih-dekat-teknik-tokenisasi-dalam-melindungi-data-sensitif-selain-enkripsi-dan-hashing.md). # Mengenal Lebih Dekat Teknik Tokenisasi dalam Melindungi Data Sensitif selain Enkripsi dan Hashing Mochammad Ronny Ardianto & Andrew Sagitta Jauhari ## Keamanan Data (Data Security) Saat ini, kita berada di era digital yang berkembang pesat ditandai dengan kemunculan berbagai inovasi teknologi canggih secara disruptif. Hal ini menyebabkan data dapat dihasilkan dengan sangat cepat dan dimana saja, mulai dari perangkat sehari-hari seperti *laptop*, *smartphone*, dan *smartwatch*, hingga di *cloud* dan internet yang dapat menjadi medium penyebaran data dengan lebih masif. Namun, sebagian dari data tersebut bisa saja berisikan informasi sensitif, sehingga diperlukan upaya teknik pengamanan data untuk mencegah risiko ketika data tersebut terekspos. Upaya tersebut dapat dicapai dengan menerapkan keamanan data atau *data security*. *Data security* melibatkan penerapan kontrol-kontrol keamanan data dengan tujuan mencegah tindakan penyalahgunaan data, penghancuran data, dan modifikasi data baik yang disengaja maupun tidak disengaja. Dalam konteks keamanan siber, data diklasifikasikan menjadi tiga (3) status utama, yaitu: * *Data at rest* – data yang disimpan pada media fisik atau digital yang tidak secara aktif sedang ditransmisikan maupun diakses. * *Data in transit* – data yang secara aktif berpindah antar perangkat, antar jaringan baik lokal dan internet, maupun melalui transmisi koneksi terenkripsi. * *Data in use* – data yang secara aktif dioperasikan oleh sistem atau user serta aktif berpindah di sepanjang infrastruktur IT. \[1] Langkah-langkah keamanan perlu diimplementasikan untuk setiap status di atas dalam upaya untuk melakukan upaya pencegahan risiko secara proaktif. Hal itu bisa dicapai dengan penerapan *security control*. Contoh *security control* terhadap setiap status tersebut antara lain sebagaimana pada tabel berikut. | Data at rest | Data in use | Data in Transit | | ------------------ | ---------------------------- | -------------------------------- | | *Data encryption* | *Authentication* | SSL/TLS | | *Password hashing* | *Data accessibility control* | *Email encryption* (PGP, S/MIME) | | *Tokenization* | *Memory encryption* | *Firewalls* | | *Masking* | *Identity management* | *Data Loss Prevention* (DLP) | | *Data federation* | | | ## Research Questions Dari sekian banyak upaya kontrol keamanan yang disebutkan di atas, enkripsi mengambil bagian mayoritas yakni paling banyak diterapkan sebagai opsi *security control* di status data *at rest*, *in use*, dan *in transit*. Namun, pernahkah Anda bertanya-tanya apabila suatu data sudah terenkripsi, apakah data tersebut sudah sepenuhnya aman? Bagaimana jika peretas mendapatkan data terenkripsi tersebut melalui celah kerentanan pada sistem? Dan apakah data asli kita masih dijamin aman karena sudah terenkripsi? Dari pertanyaan-pertanyaan tersebut, jawaban lugasnya adalah kunci enkripsi (*key*) merupakan titik krusial yang memiliki peran penting di dalam rantai risiko kerentanan pada teknologi enkripsi. Kunci enkripsi berperan sebagai syarat sah pembuka informasi terhadap data asli, yang juga berisiko membuka data asli kita kepada peretas. Apabila kunci enkripsi berhasil didapatkan oleh peretas, maka data asli kita dapat mengalami kebocoran dan berisiko terhadap penyalahgunaan data. Jadi, kelemahannya adalah data terenkripsi masih memiliki keterikatan – *“tied”* – terhadap data aslinya. Lalu, apakah ada teknik security control yang karakteristiknya adalah data yang termodifikasi tidak *“tied”* terhadap data aslinya bahkan ketika data tersebut bocor ke peretas? ## Solusi-Solusi Kontrol Keamanan Data Sebelum menjelajah lebih jauh, di artikel ini penulis akan menjelaskan secara detail beberapa contoh teknik kontrol keamanan terhadap data yang memiliki tujuan serupa dengan enkripsi, yaitu berusaha menyembunyikan informasi dari sebuah data asli. Kontrol keamanan data terpilih pada pembahasan kali ini adalah: *encryption*, *hashing*, dan *tokenization*. ### #1 - Encryption **Enkripsi (*****encryption*****) adalah suatu proses yang bertujuan untuk mengubah informasi menjadi kode atau sandi rahasia untuk menyembunyikan makna atau artinya**. Dengan menggunakan algoritma enkripsi tertentu, perusahaan dapat mengamankan data mereka dengan mengubahnya menjadi bentuk yang tidak dapat dibaca (*ciphertext*). Untuk mendapatkan akses terhadap informasi asli, maka penerima perlu melakukan proses dekripsi (*decryption*) menggunakan kunci kriptografi. \[2]

Gambar 1 - Diagram blok kriptografi enkripsi

Gambar 1 merupakan diagram blok yang menggambarkan cara kerja dari kriptografi enkripsi. Sebuah pesan berupa *plain text* yang notabenenya adalah mudah terbaca (*readable*), bersama dengan sebuah kunci dilakukan proses enkripsi F(k,P) menjadi *cipher text (unreadable)*.

Gambar 2 - Diagram blok kriptografi dekripsi

Gambar 2 menunjukkan proses dekripsi sebuah *cipher text* yang dihasilkan dari proses enkripsi. Dengan menggunakan kunci kriptografi, cipher text tersebut didekripsi F(k,C) untuk mengkonversi balik menjadi *plain text*. Jenis enkripsi berdasarkan kunci kriptografinya terbagi menjadi 2, yaitu: * ***Symmetric encryption** –* Hanya satu kunci yang digunakan dalam enkripsi simetris, yang juga disebut sebagai *private key*, untuk melakukan proses enkripsi dan dekripsi pada data. * ***Asymmetric encryption** –* Menggunakan dua jenis kunci enkripsi yang berbeda yaitu *public key* dan *private key* pada ke-2 belah pihak. \[3] ### #2 - Hashing ***Hashing***** adalah metode yang digunakan untuk menghasilkan *****string***** karakter acak dengan panjang tetap (*****fixed-length*****) – bisa pendek atau lebih panjang – terhadap suatu data atau pesan dengan menggunakan algoritma**. \[1]

Gambar 3 - Diagram blok hashing

Gambar 3 menggambarkan cara kerja *hashing* dengan mengkonversikan data (*plain text*) menggunakan *hash function* atau algoritma. Hasil konversi tersebut menghasilkan nilai *hash* yang bersifat unik dan konsisten. Jika sebuah data di-*hashing* dengan menggunakan algoritma yang sama, maka hasil konversi atau nilai *hash*-nya akan tetap sama. Namun, apabila nilai *hash* ingin dikembalikan menjadi data aslinya, maka tidak bisa, karena *hashing* merupakan teknik satu arah yang berarti data aslinya tidak dapat dikembalikan (*irreversible*). ### #3 - Tokenization Sejarah mengenai konsep tokenisasi berawal dari perusahaan bernama TrustCommerce yang pada tahun 2001 memperkenalkan konsep tersebut untuk melindungi informasi pembayaran rahasia kliennya, Classmates.com. \[4] Rob Caulfield, pendiri TrustCommerce, memiliki pemikiran bahwa potensi risiko penyimpanan data pemegang kartu sangat besar jika terjadi pelanggaran sistem, sehingga hal ini akhirnya memantik TrustCommerce menciptakan TC Citadel® – solusi dari TrustCommerce yang dapat pelanggan gunakan untuk memakai token sebagai pengganti data pemegang kartu lalu TrustCommerce akan menangani pemrosesan pembayaran untuk merchant. Sebelum berbicara tentang definisi *tokenization* di dalam penerapan kontrol keamanan terhadap data, mari kita pahami dulu terminologi mengenai token. **Token adalah data yang tidak memiliki arti dan kesinambungan dengan data asl**i. Token bertugas sebagai *placeholder* terhadap data asli sehingga data tersebut tetap bisa digunakan apabila tersimpan di *database* dalam bentuk token. **Token bersifat unik di setiap nilai yang dihasilkan dan berasal dari karakter atau angka yang acak.** Di dalam teknik pengamanan data, tokenisasi dapat diartikan sebagai proses melindungi data sensitif dengan mengganti sebagian atau semua data tersebut dengan karakter atau angka placeholder secara acak dan tidak terikat terhadap data asli yang disebut sebagai token \[5]. Untuk menggunakan token sebagai pengganti data sensitif, biasanya akan dilakukan *mapping* antara *value* data asli dengan token pada sebuah database yang *secure*. Cara tersebut biasa disebut dengan *vaulted tokenization*, sehingga terdapat tambahan lapisan teknologi yaitu sebuah *database*. Apabila diklasifikasikan berdasarkan tipe penerapan tokenisasi, terdapat 2 jenis teknik penerapan tokenisasi, yaitu: ***a. Vaulted Tokenization.** Vaulted tokenization* adalah jenis tokenisasi dengan menggunakan cara konvensional yaitu menggunakan *mapping* antara data asli dengan token pada sebuah *database* yang *secure*. Biasanya teknik ini memiliki sifat *irreversible* – kondisi dimana data asli tidak bisa dikembalikan melalui token.

Gambar 4 - Diagram blok arsitektur vaulted tokenization

Gambar 4 menunjukkan hubungan antara aplikasi, *tokenization server*, *vault database*, dan *application database*. Aplikasi yang mengandung data sensitif akan menghubungi server tokenisasi untuk melakukan *random generate token* yang kemudian token tersebut di-*mapping* di *vault* DB. Setelah itu akan dihasilkan data yang telah tertokenisasi sehingga tidak mengandung data sensitif lagi. Hasil token ini kemudian akan didistribusikan kembali oleh aplikasi menuju *app* DB atau layanan seperti pihak ketiga. ***b. Vaultless*** ***Tokenization**. Vaultless tokenization* merupakan teknik tokenisasi dengan tidak menggunakan *database* untuk menyimpan nilai pemetaan dari data sensitif. Cara ini menggunakan perangkat kriptografi melalui algoritma untuk mengubah data sensitif menjadi data non-sensitif. Sehingga aspek database akan hilang dengan metode ini, namun akan terfokus terhadap algoritma.

Gambar 5 - Diagram blok arsitektur vaultless tokenization

Gambar 5 merupakan representasi hubungan antara *stack* teknologi yang digunakan untuk mewujudkan *vaultless tokenization*. Pada gambar tersebut, aspek *vault database* sudah tergantikan menggunakan algoritma kriptografi. Algoritma yang biasanya digunakan untuk implementasi *vaultless* *tokenization* adalah *Format Preserving Encryption* (FPE) – jenis enkripsi yang mempertahankan karakteristik data aslinya. Dengan menggunakan cara ini, sifat tokenisasi yang awalnya *irreversible* dapat memiliki opsi *reversible* sebagai tambahan. ## Analisa ### #1 - Encryption Setelah memahami secara mendalam mengenai enkripsi, apakah enkripsi memiliki risiko keamanan? Jawabannya, Ya. Enkripsi jelas mempunyai kerentanan yang titik utamanya adalah kunci kriptografinya. > **“Lost Key = Lost Sanity”** Terdapat banyak risiko yang mengintai enkripsi terutama terhadap keamanan kunci kriptografinya. Apabila kunci kriptografi Anda hilang dan tidak ada jalan untuk mengetahui kunci apakah tersebut (*backup*, *multiple keys*, dan lain-lain), maka Anda tidak mempunyai keberuntungan untuk mengakses data kembali selain *cybercriminal*. Kehilangan kunci pada dasarnya adalah kehilangan data \[6]. Menjaga kunci-kunci kriptografi merupakan langkah yang penting, yang mana aset tersebut terkategori sebagai high-asset value. Namun, semakin banyaknya proses enkripsi dilakukan, maka semakin banyak kunci yang harus dijaga dan dirawat, sehingga akan lebih banyak kompleksitas untuk melakukan tracking terhadap aset-aset tersebut. Sesuai dengan pertanyaan-pertanyaan pada bagian *research questions* di artikel ini, teknik enkripsi ternyata masih memiliki sifat keterikatan *“tied”* antar data terenkripsi dengan data aslinya. Hal ini memantik solusi lain yang sifatnya tidak terikat terhadap data aslinya. Jika pada enkripsi menghasilkan data terkonversi yang memungkinkan untuk dikonversikan kembali ke data aslinya (*reversible*), bagaimana jika kita mencoba solusi lain yang bersifat *irreversible*? ### #2 - Hashing Lalu, apakah *hashing* memiliki risiko keamanan yang dapat menyebabkan kerentanan? Ya, pasti. Jika berbicara mengenai enkripsi, maka premis risiko keamanannya berada pada kunci kriptografinya. Sedangkan pada *hashing*, titik vital risiko keamanannya berada pada fungsi *hashing* yang digunakan. Mengapa? Karena apabila fungsi *hashing* atau algoritma tersebut sekali saja dapat diketahui oleh *attacker*, maka data asli kita sudah tidak akan aman. Walaupun *hashing* merupakan teknik satu arah, namun masih terdapat cara untuk mengetahui data aslinya. > **"Rainbow Table Attack"** ***Rainbow*** ***table*** ***attack***** adalah jenis serangan terhadap *****hashing***** dengan menggunakan prekomputasi yang melibatkan pembuatan *****rainbow*** ***table***** – sebuah tabel berukuran besar yang menyimpan pasangan antara nilai *****hash***** dengan data aslinya – dari suatu algoritma *****hashing***. Untuk mengerti lebih lanjut mengenai *rainbow* *table*, Anda bisa mengunjungi halaman berikut: [*How* *Rainbow* *Table*s *work* (kuliukas.com)](https://kestas.kuliukas.com/RainbowTables/). \[7] *Hashing* memang merupakan solusi satu arah yang dapat mengatasi masalah *reversible* pada enkripsi ketika kunci kriptografinya hilang atau tercuri, namun *concern*-nya masih sama seperti yang ada pada teknik enkripsi. *Rainbow* *table* *attack* merupakan risiko yang vital terhadap teknik *hashing* karena dapat mengembalikan nilai *hash* ke data aslinya, sehingga terdapat fakta bahwa nilai *hash* masih memiliki terikat *“tied”* terhadap data aslinya. ### #3 - Tokenization Dengan menggunakan *vaulted* *tokenization*, maka terdapat kemungkinan *attack* *surface* – daftar kemungkinan kerentanan pada sistem – yang baru, yaitu database. > **"Vault DB: Arise of risk and lack of manageability”** Menurut penulis, dengan menggunakan teknik *vaulted* *tokenization*, maka titik terkrusial dari arsitektur ini terletak pada vault DB yang merupakan tanggung jawab tambahan untuk kita. Hal ini dikhawatirkan akan *overwhelming* apabila melihat teknik pengamanan data terhadap database saat ini cukup kompleks. Selain itu, semakin banyaknya data yang ter-*mapping* pada database, maka semakin besar pula ukuran database yang dihasilkan yang kemudian bisa men-*trigger* mahalnya biaya, susahnya *maintenance*, serta menurunnya *availability*. Setelah pembahasan di atas, penulis akan membahas tentang penggunaan *vaultless* *tokenization*. Apabila diperhatikan lebih jelas pada contoh diagram blok sesuai Gambar 5, maka titik vital terhadap cara ini hanyalah algoritmanya. Titik vital ini tidaklah mudah untuk didapatkan karena algoritma yang digunakan pada *vaultless* *tokenization* merupakan resposibilitas dari *provider* *tokenization*. Melalui teknologi dan algoritma yang mereka gunakan, maka *scope of work* peretas akan lebih kompleks, sehingga diperkirakan bahwa peretas akan memerlukan lebih waktu dan tenaga untuk membobol algoritma. Jadi, kita tidak perlu melakukan me-manage dan melakukan maintenance terhadap algoritma tersebut. ## Intermezzo ### #1 - Format Preserving Encryption (FPE) Berhubungan dengan solusi kontrol keamanan melalui *vaultless* *tokenization*, FPE seringkali digunakan sebagai algoritma untuk meng-*generate* token. *Format Preserving Encryption*, seperti namanya, merupakan teknik enkripsi di mana format data terenkripsi tetap dipertahankan. Ketika plain text dienkripsi dengan FPE, *ciphertext* kemudian memiliki format yang sama dengan *plaintext* \[8]. Publikasi khusus NIST 800-38G, menentukan dua mode AES, FF1 dan FF3, untuk enkripsi yang memiliki karakterisik tetap mempertahankan format. Namun, FF3 sudah diputuskan bahwa tidak lagi cocok karena terdapat serangan *cyptoanalysis* terhadap algoritma tersebut. Anda dapat mempelajari rekomendasi NIST tersebut pada dokumen [*SP 800-38G, Block Cipher Modes of Operation: Format-Preserving Encryption* | CSRC (nist.gov)](https://csrc.nist.gov/publications/detail/sp/800-38g/final). \[9]

Gambar 6 - Diagram blok penerapan FPE dibanding enkripsi konvensional

Seperti yang diilustrasikan pada Gambar 6, algoritma enkripsi konvensional seperti AES secara signifikan mengubah tidak hanya format tetapi juga panjang *ciphertext*. Misalnya, nomor kartu kredit 16-digit (1234 5678 7654 3456) yang dienkripsi dengan AES, menghasilkan string alfanumerik yang panjang dan tidak dapat dikenali. Jika nomor kartu kredit yang sama dienkripsi dengan FPE, maka akan memberikan *string* dalam format dan panjang yang sama persis dengan teks aslinya (8987 4569 7654 5897). Begitupun contoh alamat *email* pada gambar tersebut juga terkonversi menjadi format yang sama apabila menggunakan FPE. ### #2 - Pseudonymisation atau Anonymisation? Merujuk pada definisid dari GDPR (*General Data Protection Regulation*), *pseudonymisation* adalah pemrosesan data pribadi sedemikian rupa sehingga data tidak dapat lagi dikaitkan dengan subjek data tertentu tanpa menggunakan informasi tambahan, selama informasi tambahan tersebut disimpan secara terpisah dan tunduk pada langkah-langkah teknis dan organisasi untuk memastikan non-atribusi ke individu yang diidentifikasi atau dapat diidentifikasi. \[10] Sedangkan *anonymisation* adalah upaya untuk melakukan penghapusan terhadap semua informasi pribadi yang digunakan untuk mengidentifikasi individu. Data asli diubah atau bahkan dihapus sehingga tidak dapat dihubungkan kembali dengan data aslinya. Cara ini digunakan untuk melindungi privasi individu dengan menghilangkan kemampuan untuk mengidentifikasi individu tersebut.

Gambar 7 - Grafik representasi data usability dan data security

Melihat definisi mengenai *pseudonymisation* dan *anonymisation*, penulis mendapatkan gambaran mengenai grafik hubungan antara *data usability* dan *data security* sesuai pada Gambar 7. *Data usability* adalah seberapa mudahnya aspek kegunaan dari sebuah data, sedangkan *data security* adalah seberapa tingginya aspek keamanan terhadap data. Jika dijabarkan melalui grafik unlinear tersebut, kita dapat memposisikan bahwa setiap jenis data dan upaya kontrol keamanan berada pada titik yang berbeda-beda, sehingga penggunaannya juga berbeda-beda – dalam artian tidak dapat diterapkan dalam satu contoh *usecase* yang sama. Namun, penulis mendapatkan bahwa kontrol keamanan paling “*humanis*” adalah *tokenization*. Pada gambar tersebut, *tokenization* terletak di cross-position antara *open breach* dan *anonymised*, sehingga dapat dikatakan solusi *tokenization* merupakan solusi yang menerapkan *pseudonymisation* . Keuntungan dari solusi ini antara lain: > * Opsi *reversible* dan *irreversible* tersedia dengan pilihan implementasi *vaulted* atau *vaultless* *tokenization*. > * Memberikan dukungan terhadap *data usabilty* dan *data security* secara imbang. > * Berdasarkan *risk* *assessment* pada analisa, memiliki *protection layer* yang kuat terhadap *data breach*. Sedangkan penerapan *clear text*, *hashing*, dan enkripsi berada pada posisi yang spesifik seperti *open to breach* hingga mendekati *fully anonymised*. Ini berarti bahwa apabila Anda ingin menerapkan kontrol keamanan yang jelas terhadap data Anda, maka anda perlu memberikan policy yang spesifik terhadap usecase yang Anda butuhkan agar penerapan kontrol keamanan tersebut sesuai. ## Use Cases Tabel I berikut dapat digunakan sebagai bahan acuan untuk menerapkan jenis kontrol keamanan terhadap *usecase-usecase* tertentu. Tabel 1 - Tabel *usecase* penerapan kontrol keamanan | Kontrol Keamanan | Usecase | Alasan mendasar | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Enkripsi | | Enkripsi cocok digunakan untuk data terstruktur maupun tak terstruktur yang memiliki sensitivitas tinggi. Penerapan enkripsi cocok digunakan terhadap data yang perlu dilakukan penyembunyian hingga *anonymisation*. | | *Hashing* | | *Hashing* cocok digunakan dalam operasi yang cepat dan penting seperti penyimpanan *password*. Hashing memberikan solusi keamanan yang kuat serta mendukung aspek *usability* dari sebuah data. | | *Tokenization* | | Tokenisasi lebih cocok digunakan dalam konteks di mana data asli perlu diidentifikasi secara eksklusif, seperti pada sistem pembayaran atau pengolahan transaksi. | ## Kesimpulan Jika kembali kepada konsep tokenisasi, token merupakan hasil nilai yang acak dan tidak memiliki arti. Apabila token bocor kepada peretas, maka token tersebut tidak akan berguna untuknya, ia juga tidak akan dapat menemukan tahap selanjutnya untuk melakukan eksploitasi terhadap data aslinya. Hal ini dikarenakan token tidak lagi “*tied*” terhadap data aslinya. Keterkaitan token dengan data aslinya tereliminasi melalui keberadaan *mapping database* atau algoritma kriptografi yang disediakan oleh provider *tokenization*. Jadi, dengan menggunakan *vaulted* maupun *vaultless* *tokenization*, pada akhirnya kedua cara ini dapat menjadi solusi terhadap *concern* riset yang mendasari artikel ini. > “Tokenization completely removes transaction data from the equation, and replaces it with a token. Even if a criminal somehow managed to “hack” a particular token, there’s no information there to reverse engineer. The risk of data theft is effectively eliminated.” – Cb911 \[5] ## Referensi 1. EC-Council, Certified Network Defender (CND) Version 2 w/ iLabs (Volumes 1 through 4) (2nd ed.), International Council of E-Commerce Consultants (EC Council), 2020. 2. Jatheon, “A Complete Guide to Encryption — Data at Rest, Data in Motion and Data in Use,” Jatheon Technologies, 2 May 2022. \[Online]. Available: ; 3. A. Rawal, Gaurav, H. Kanna dan G. Kaur, “Cryptography: Symmetric vs Asymmetric Encryption,” Journal of Embedded Systems and Processing, vol. III, no. 3, pp. 1-5, 2018. 4. TrustCommerce, “Where Did Tokenization Come From?,” TrustCommerce, \[Online]. Available: ; 5. Chargebacks911, “Tokenization: Maximizing Data Security for Merchants & Cardholders,” Chargebacks911, 3 January 2023. \[Online]. Available: ; 6. Aviture, “Data Encryption: Definition, Pros and Cons, and How It Affects You,” Aviture Inc., 5 January 2021. \[Online]. Available: ; 7. Unknown, “How Rainbow Tables work,” kestas.kuliukas.com, \[Online]. Available: ; 8. H. Mandge, “Format Preserving Encryption,” Dzone, 10 August 2021. \[Online]. Available: ; 9. M. Dworkin, “Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption,” NIST, 4 August 2016. \[Online]. Available: ; 10. GDPR, “Article 4 EU GDPR "Definitions",” GDPR, \[Online]. Available: . ### Tentang Penulis ![](https://1897137542-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNbk8bFw3pJck0jgXywso%2Fuploads%2FOF1Kdx7iTxfMCyKsutCX%2Fimage.png?alt=media\&token=08786d0d-2c6a-4249-bddf-fc07c2b9b76a) #### Mochammad Ronny Ardianto Infosec R\&D Engineer at Blibli.com ![](https://1897137542-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNbk8bFw3pJck0jgXywso%2Fuploads%2FaMce6Nlhcun0C4agIZia%2Fimage.png?alt=media\&token=4c7465b7-a02f-485a-9f87-d918ae6c0160) #### Andrew Sagitta Jauhari Infosec R\&D Engineer at Blibli.com