98 lines
10 KiB
Markdown
98 lines
10 KiB
Markdown
---
|
|
title: Menyembunyikan email di internet
|
|
tags:
|
|
- blog
|
|
slug: menyembunyikan-email-di-internet
|
|
date: 2021-05-26T01:58:31.000Z
|
|
date_updated: 2021-05-26T02:03:58.000Z
|
|
excerpt: Email adalah identitas utama di internet, well, at least sebelum kita membahas tentang Web 3.0 nanti.
|
|
---
|
|
|
|
Email adalah identitas utama di internet, well, at least sebelum kita membahas tentang Web 3.0 nanti. Setiap layanan yang ada di internet pasti menggunakan email untuk mengautentikasi siapa kita di layanan tersebut.
|
|
|
|
Kasus *[data breach](https://haveibeenpwned.com/PwnedWebsites)*bukanlah sesuatu yang baru di internet. Data breach sederhananya adalah sebuah kondisi ketika pihak yang seharusnya tidak memiliki izin untuk mengakses data tersebut dapat mengaksesnya melalui jalan manapun dan biasanya menjualnya ke pembeli yang ada di internet.
|
|
|
|
Data yang dijual bervariasi, namun yang paling menarik & laku adalah data pengguna. Salah satu alasannya adalah karena data pengguna bisa digunakan untuk tujuan mendapatkan keuntungan, entah itu untuk melakukan scam; phising, carding, spam, dan lain sebagainya tergantung tujuan & data yang dikantongi.
|
|
|
|
Kasus terakhir yang lumayan besar di Indonesia yang gue peduli adalah ketika ~15jt data di [Tokopedia](https://haveibeenpwned.com/PwnedWebsites#Tokopedia) tercuri termasuk data TTL, alamat *email*, jenis kelamin, nama dan kata sandi yang seharusnya dalam bentuk *hashed.*
|
|
|
|
Ketika berbicara tentang keamanan & privasi khususnya di internet, kita harus mengetahui *threat model *kita sebagai pengguna. Kalau dari kasus pembobolan sistem Tokopedia, kemungkinan data gue (kalau ada) dipakai untuk melakukan *spam *dan *phising *jika memang si pembeli data ingin melakukannya.
|
|
|
|
Anyway, biasanya, dari data breach juga digunakan sebagai gerbang kedua untuk masuk ke gerbang utama: akses ke email kita. Tidak jarang pengguna internet menggunakan kata sandi yang sama; kata sandi yang tidak unik, dsb yang relatif mudah dipecahkan thanks to john the ripper.
|
|
|
|
Ketika akun kita berada dalam *data breach *tersebut, biasanya, penyedia layanan akan memberitahukan kita untuk mengganti kata sandi untuk mengurangi resiko penyerangan khususnya dalam pengambil-alihan akun.
|
|
|
|
Namun poin nya bukan disitu, melainkan data alamat email utama kita sudah terdampak, dan yang "melakukan sesuatu" terkait data bukan hanya orang yang dianggap jahat untuk melakukan kejahatan saja. Jika pembeli data tersebut adalah perusahaan yang menyediakan layanan untuk bisa mengidentifikasi bahwa 3 pengguna di berbagai layanan dengan data yang berbeda adalah 1 orang yang sama, dan berkat sihir *"machine learning" *yang salah satu sumbernya diambil dari data yang dijual tersebut, kasus tersebut termasuk salah satu dari *threat model *gue dalam berinternet.
|
|
|
|
Jangan anggap kasus tersebut hanyalah fantasi belaka, I know exactly this industry :))
|
|
|
|
## Private relay
|
|
|
|
Mozilla pada kapan lalu menyediakan layanan "private relay" melalui [Firefox Relay](https://relay.firefox.com/) dan Apple [pun melakukan](https://support.apple.com/en-us/HT210425) hal yang hampir sama namun melalui Sign in with Apple nya.
|
|
|
|
Bukan tanpa alasan mengapa 2 perusahaan yang *mengaku *sangat peduli dengan privasi menawarkan layanan tersebut ke pengguna nya demi melindungi lebih lanjut identitas pengguna khususnya di internet.
|
|
|
|
Private relay ini cara kerjanya relatif sederhana, intinya, hanya menyembunyikan alamat email tujuan asli dibalik alamat email yang diberikan oleh si private relay. Khusus untuk Apple, sejauh yang gue tau private relay di Apple ini skop nya per-aplikasi/domain, jadi alamat `f5cx@...` hanya dapat menerima email dari `@github.com` dan akan auto-reject bila mendapatkan email dari `@gitlab.com`.
|
|
|
|
Dari 2 layanan diatas, terdapat pro dan kontra masing-masing.
|
|
|
|
Untuk Apple, tentu saja ini terbatas hanya untuk pengguna Apple **dan **terkunci di tembok Apple.
|
|
|
|
Untuk Firefox, sejauh yang gue tau hanya bisa membuat 5 alamat private aja namun tidak terkunci di tembok Firefox untuk penggunaannya. **Namun**, Mozilla hobi mematikan layanannya **dan **berdasarkan dari [FAQ](https://relay.firefox.com/faq) nya, jika suatu saat Mozilla mematikan layanan tersebut, satu-satunya cara yang harus dilakukan adalah mengganti alamat email tersebut, karena kamu terkunci di tembok @relay.firefox.com nya Firefox, meskipun kasus tersebut dapat dihindari bila Mozilla menawarkan *custom domain*.
|
|
|
|
Sejak [SimpleLogin](https://simplelogin.io/) pertama kali diluncurkan, gue langsung tertarik untuk menggunakannya. Gue pernah pasang di server gue melalui instruksi di README nya yang sangat intuitif, SimpleLogin ini *Open Source* dan berlisensi MIT. Gue pernah kontak *founder *nya untuk menyediakan donasi via GitHub Sponsors karena pada saat itu gue masih ingin menjalankan SimpleLogin di server gue sendiri.
|
|
|
|
Setelah insiden [hilangnya data](https://github.com/docker/for-linux/issues/1237) karena Docker, gue memutuskan untuk menggunakan versi berbayar cloud nya yang ditawarkan oleh SimpleLogin pertahun sebagai bentuk sponsor.
|
|
|
|
Dan karena itu mengapa tulisan ini ada.
|
|
|
|
## Tentang SimpleLogin
|
|
|
|
SimpleLogin adalah layanan yang serupa seperti Private relaynya Firefox dan Apple, namun bersumber kode terbuka & berlisensi MIT. Setiap orang dapat menjalankan SimpleLogin di mesinnya sendiri jika memang ehm tidak menghargai waktu mereka.
|
|
|
|
SimpleLogin mendukung *custom domain* sehingga proses migrasi dari server gue ke layanan SimpleLogin sesederhana mengganti *record *MX, CNAME, dan TXT ke tempat mereka.
|
|
|
|
Dan juga SimpleLogin mendukung "catch-all" yang sangat berguna untuk gue yang tidak memiliki *backup *untuk import daftar email gue ke SimpleLogin yang menggunakan alamat domain yang sama.
|
|
|
|
Cara kerja SimpleLogin ini sesederhana hanya melakukan penerusan, tidak ada data email yang disimpan. Gue yakin dengan itu karena gue pernah menjalankannya di server gue sendiri, thanks to Open Source.
|
|
|
|
Hal yang menarik dari SimpleLogin adalah email yang di *forward *bisa di-enkripsi terlebih dahulu menggunakan Public PGP key kita. Ini salah satu contohnya:
|
|
|
|
Email by design tidak menyediakan pilihan enkripsi end-to-end—karena relatif sulit untuk mendeteksi spam—dan juga layanan email yang gue gunakan ([Migadu](https://migadu.com)) tidak menyediakan *encryption at rest*. Dan gue tidak ingin menggunakan POP3 hanya agar server Migadu tidak menyimpan data email gue untuk menghindari kehilangan data lagi.
|
|
|
|
Gue sudah lama tidak menggunakan layanan email dari penyedia email gratis karena beberapa alasan dan gue memilih Migadu (you should too!) karena setuju dengan "misi" yang mereka miliki.
|
|
|
|
Secara keseluruhan pendekatan gue adalah:
|
|
|
|
- Menggunakan email `...@relay.edgy.network` untuk layanan yang gue gunakan di internet yang mengarah ke SimpleLogin.
|
|
- SimpleLogin akan mengenkripsi lalu meneruskan email tersebut ke email asli gue yang memang hanya ditujukan untuk layanan yang ada di internet
|
|
- Migadu menerimanya dan dalam bentuk terenkripsi. Di level email client gue sudah setup untuk membuatnya auto-decrypt on demand.
|
|
|
|
Pendekatan gue terkesan overkill namun ini membuat aktivitas gue di internet menjadi sedikit terasa aman. Ketika ada data breach, nama; TTL dan berbagai data sensitif lainnya tetap tercuri—yang mungkin bisa digunakan untuk *identity theft—*namun data email utama gue tetap aman. Dan gue tinggal matikan itu alamat (gue satu akun satu alamat email btw) lalu mengganti alamat email & kata sandi dengan yang baru. Profit!
|
|
|
|
## Penutup
|
|
|
|
Di beberapa kasus gue masih membuka alamat email gue ke publik, seperti `oss@faultable.dev` yang gue gunakan di GitHub dan untuk melakukan *sign commit *juga.
|
|
|
|
Tidak ada yang spesial dengan alamat email tersebut, jika terkena pembobolan pun hanya berisi notifikasi dari GitHub dan SourceHut. Selain itu juga, alamat email yang di teruskan dari SimpleLogin sebenarnya hanyalah *alias *yang tidak memiliki kredensial, email utama gue masih menjadi rahasia yang hanya gue dan Migadu tau hahaha.
|
|
|
|
Selain itu ada juga `hi@faultable.dev` yang gue gunakan untuk berkomunikasi via email dengan pengguna random internet untuk jalur pribadi.
|
|
|
|
Gue tau & sadar kalau internet bukanlah tempat yang aman, gue pernah diposisi menggunakan topi hitam; putih, dan bahkan abu-abu. Sekarang bahkan gue bekerja di industri yang berurusan dengan data, dan gue tau apa yang dilakukan dengan data tersebut :))
|
|
|
|
Setiap orang pasti memiliki *threat model *masing-masing, seperti, mungkin beberapa ada yang merasa *insecure *ketika ada seseorang yang mengikuti dia di malam hari & ada yang merasa biasa aja.
|
|
|
|
Dan ketika berbicara tentang keamanan & privasi di internet, seharusnya kita sudah mengetahui akan *threat model *kita juga. Khusus untuk *software engineer *pasti sudah familiar-lah dengan *threat model *karena ketika merancang & mengembangkan peranti lunak, kita biasanya sudah memikirkan bagimana mana saja yang bisa menjadi celah keamanan; apa yang sudah dipersiapkan dan belum dipersiapkan, serta apa *worst case scenario *yang sudah terbayang.
|
|
|
|
Begitupula dengan manusia, harusnya memikirkan itu juga. Gue tidak membahas detail tentang OpSec disini karena ditulisan ini gue cuma ingin memberitahukan kepuasan gue menggunakan layanan SimpleLogin dan Migadu.
|
|
|
|
Email adalah salah satu data sensitif di dunia internet karena mengarah ke identitas seseorang. Setiap orang mungkin berbeda-beda dalam memelihara informasi sensitif, dan gue cuma membagikan cara gue dalam memelihara informasi sensitif di internet.
|
|
|
|
Jika suatu saat SimpleLogin menutup layanannya, gue tinggal *export *data yang ada di SimpleLogin dan memindahkan ke alternatif lain yang dirujuk SimpleLogin ataupun menjalankannya sendiri yang tidak memakan waktu 1 jam.
|
|
|
|
Jika suatu saat Migadu menutup layanannya, gue tinggal backup data-data email gue dan memindahkannya ke alternatif lain ataupun menjalankannya sendiri yang sedikit ribet.
|
|
|
|
Salah satu manfaat dari menggunakan *custom domain *bukan hanya di *self-branding*, melainkan di *ownership-ish *juga, karena internet, by mistake, menggunakan "domain" sebagai "sistem penamaan" thanks to human limit yang tidak bisa menghafal 3,706,452,992 alamat IP public.
|
|
|
|
Dan hey, domain tersebut sebenarnya kita hanya menyewanya saja bukan memilikinya secara utuh. Tapi itu pembahasan lain :))
|