Alat pengembang · Encoder & decoder Base64
Bagaimana header autentikasi dasar HTTP dibuat dan didekodekan dengan Base64
· Cara kerjanya
base64 keamanan
Otorisasi: Header dasar hanyalah nama pengguna: kata sandi yang dijalankan melalui Base64. Postingan ini menunjukkan bagaimana nilai dibangun, cara mendekode nilai dari log permintaan, dan mengapa pengkodean tidak menyembunyikan apa pun.
401 yang tetap ada meskipun kredensialnya benar — nilai header yang diterjemahkan menjadi string yang agak salah
HTTP API mengembalikan 401 Tidak Sah dan mengharapkan Otorisasi: Header dasar. Nilainya adalah kata skema Basic, satu spasi, dan string Base64. Awalan yang hilang, awalan yang dikodekan, atau baris baru yang tidak disadari mengubah apa yang diterima server meskipun nama pengguna dan kata sandi yang terlihat terlihat benar.
Decode string itu dan terbaca nama pengguna: kata sandi (secara harfiah titik dua di antara dua). Byte nama pengguna: kata sandi dikodekan UTF-8 kemudian dikodekan Base64, menghasilkan nilai header. Jika kredensial adalah admin:s3cret, UTF-8 byte adalah 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (ASCII huruf ditambah titik dua), pengkodean Base64 menghasilkan YWRtaW46czNjcmV0, dan headernya adalah Otorisasi: Basic YWRtaW46czNjcmV0.
Resep dari RFC 7617: 'user:pass', UTF-8, Base64 — langkah tepat dan peran titik dua
Ini adalah HTTP Skema autentikasi dasar lengkap yang ditentukan dalam RFC 7617. Ini sederhana, terstandarisasi, dan tidak menawarkan keamanan dengan sendirinya: siapa pun yang membaca header dapat segera memecahkan kodenya untuk membaca kata sandi. Inilah sebabnya mengapa HTTPS wajib untuk autentikasi Dasar. Pengkodean adalah persyaratan transportasi, bukan fitur keamanan. Kata sandi dikirimkan sebagai UTF-8 byte, sama seperti data lainnya; Base64 hanyalah notasi yang digunakan dalam protokol HTTP.
Jika perlu mendekode header Dasar dari log jaringan, prosesnya mudah: hapus Basic, sisa dekode Base64, dan Anda memiliki nama pengguna: kata sandi. Titik dua adalah pembatas antara username dan kata sandi. RFC 7617 menentukan kredensial adalah user-id : kata sandi, dan titik dua pertama adalah pemisah. Jika kata sandi mengandung titik dua, titik dua kedua hanyalah karakter lain dalam kata sandi. Titik dua bersifat struktural karena penerima memerlukan satu batas yang jelas. Ia mencari titik dua pertama setelah decoding; semuanya sebelum mengidentifikasi pengguna dan semuanya setelahnya adalah kata sandi. Oleh karena itu, titik dua yang hilang menunjukkan format pasangan kredensial yang salah, bukan masalah alfabet Base64.
Contoh praktis: menyandikan admin:s3cret dan mendekode header dari log — kedua arah, termasuk bug baris baru
Jika nama pengguna adalah admin dan kata sandi adalah pass:word, kredensialnya adalah admin:pass:word, yang dikodekan ke YWRtaW46cGFzczp3b3Jk. Saat mendekodekannya, harus dipisah pada titik dua pertama saja, memberikan nama pengguna admin dan kata sandi pass:word. Memisahkan setiap titik dua akan salah membagi kata sandi. Parameter charset di RFC 7617 menyatakan kredensial UTF-8 dikodekan. Ini berarti karakter non-ASCII dalam nama pengguna atau kata sandi dikonversi menjadi UTF-8 byte sebelum pengkodean Base64.
Jika nama pengguna adalah café (beraksen e), UTF-8 byte adalah 0x63 0x61 0x66 0xC3 0xA9 (empat byte untuk huruf ASCII ditambah dua untuk karakter beraksen), dan kredensial lengkap café:kata sandi memiliki byte untuk kafe, lalu byte titik dua 0x3A, lalu kata sandi. Output Base64 mengkodekan semua byte dengan tepat. Decoder harus tahu cara menafsirkan byte yang didekodekan sebagai teks UTF-8, bukan Latin-1.
Kata sandi yang mengandung titik dua, spasi, dan non-ASCII — mengapa titik dua pertama terpecah, dan untuk apa parameter charset
Contoh praktis: mulai dengan admin:s3cret. Konversikan ke UTF-8 byte: a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. Dalam desimal: (97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64 mengkodekan 12 bytes ini: kelompokkan menjadi empat kelompok yang terdiri dari tiga (menghasilkan empat kelompok yang terdiri dari empat karakter Base64).
Nilai yang dikodekan adalah YWRtaW46czNjcmV0. Header otorisasi adalah Otorisasi: Dasar YWRtaW46czNjcmV0. Sisi kata sandi dapat berisi titik dua lainnya tanpa memindahkan batas pertama tersebut. Spasi dan teks non-ASCII juga bertahan ketika kedua rekan menyetujui pengkodean teks. ToolAcre dapat memverifikasi UTF-8 byte yang dipancarkannya, tetapi server lama yang mengharapkan jaringan karakter berbeda tetap menjadi masalah interoperabilitas di luar transformasi Base64.
Mengapa ini tidak aman tanpa TLS — decoding menunjukkan kata sandi kepada siapa saja yang melihat header
Untuk memecahkan kode header yang diterima, hapus Basic, Base64 dekode YWRtaW46czNjcmV0 untuk mendapatkan byte kembali, tafsirkan sebagai teks UTF-8 untuk mendapatkan admin:s3cret, pisahkan pada titik dua pertama untuk mengekstrak nama pengguna dan kata sandi. Kesalahan umum adalah mengikuti baris baru dari echo. Jika dijalankan echo admin:s3cret | base64 di shell Unix, echo menambahkan baris baru secara default, jadi kodekan admin:s3cret dengan baris baru (13 bytes sebagai gantinya 12).
Output Base64 berbeda: YWRtaW46czNjcmV0Cg== (padding dan karakter tambahan). Header otorisasi dengan nilai ini akan gagal karena kata sandi menyertakan karakter baris baru. Perbaikannya adalah menggunakan echo -n atau menyalurkan melalui printf atau alat yang tidak menambahkan baris baru. Encoder & decoder Base64 menghindari hal ini: mengkodekan persis apa yang Anda tempel, tidak ada baris baru yang tersembunyi. TLS mengubah ancaman transportasi, bukan format kredensial. Di dalam koneksi yang dilindungi, header dienkripsi dengan sisa permintaan; setelah perangkat lunak mencatat atau menampilkannya, nilai Base64 kembali memperlihatkan kredensial yang dapat digunakan kembali kepada siapa pun yang dapat memecahkan kodenya. Redaksi tetap penting di setiap titik pengamatan.
Kesalahan umum — baris baru dari echo, awalan 'Basic' yang hilang, dan pengodean ganda nilainya
Kesalahan lainnya adalah hilangnya awalan Dasar. Nilai header otorisasi tidak hanya valid di Base64; itu adalah nama skema (Basic atau Bearer atau lainnya) diikuti dengan spasi dan kemudian kredensial. Beberapa sistem gagal mengenali YWRtaW46czNjcmV0 sebagai kredensial tetapi berhasil dengan Basic YWRtaW46czNjcmV0. Jika men-debug 401, periksa apakah server mengurai header Otorisasi dengan benar.
Skema tidak peka huruf besar-kecil dalam standar HTTP tetapi banyak implementasi yang peka huruf besar-kecil; periksa dokumentasi API. Pengkodean ganda adalah mode kegagalan lainnya. Jika string enkode Base64 yang sudah dikodekan Base64, outputnya adalah string yang berbeda. Pengkodean YWRtaW46czNjcmV0 menghasilkan WVdkbWFXNDZjek5qY3JldA== (sama sekali berbeda). Beberapa sistem mungkin secara tidak sengaja menerapkan pengkodean dua kali: sekali selama penyiapan kredensial dan sekali lagi saat membuat header. Baris baru dari perintah shell sangat mudah untuk dilewatkan karena dapat dikodekan sebagai bagian dari kredensial daripada ditolak sebagai spasi di sekitar Base64. Header yang dihasilkan menerjemahkan dengan rapi menjadi kata sandi dengan byte tambahan, menghasilkan 401 yang terlihat seperti kegagalan otentikasi sisi server.
Apa yang tidak tercakup di sini — Skema Digest dan Bearer, serta permintaan kredensial browser
Decoder mengharapkan satu lapisan Base64, sehingga pengkodean ganda menyebabkan ketidakcocokan. Inilah sebabnya mengapa pencatatan nilai kredensial dalam bentuk Base64 (bukan teks biasa) dapat membingungkan: jika seseorang menerapkan decoding satu kali, mereka akan melihat nama pengguna dan kata sandi; jika diterapkan dua kali, mereka melihat kebingungan. Otentikasi intisari (RFC 7616) dan otentikasi Pembawa (untuk token OAuth) menggunakan skema yang berbeda, masing-masing dengan format kredensial yang berbeda.
Intisari memerlukan server untuk mengirimkan nonce, klien untuk menghitung hash, dan header untuk menyertakan hash plus nama pengguna, bukan kata sandi. Pembawa biasanya adalah JSON Token Web (JWT), yang dikodekan dengan url Base64 tetapi tidak diawali dengan nama pengguna. Otentikasi dasar lebih sederhana daripada keduanya tetapi sepenuhnya tidak aman tanpa TLS karena kredensial dapat dibaca di header. Intisari dan Pembawa menggunakan bidang header Otorisasi yang sama tetapi memberikan arti yang sepenuhnya berbeda pada nilainya. Permintaan kredensial browser menambahkan antarmuka pengguna dan perilaku caching di atas Basic. Artikel ini berhenti pada pembuatan dan pemeriksaan payload kredensial Dasar daripada membandingkan sistem autentikasi tersebut.
Kesimpulan: Otentikasi dasar adalah Base64, bukan perlindungan — bagaimana encoder & decoder Base64 memungkinkan Anda memeriksa nilai header secara lokal tanpa mengirimkan kredensial ke mana pun
Jika API mendukung beberapa skema autentikasi, pilih yang paling aman yang tersedia. Encoder & decoder Base64 dapat membantu men-debug kegagalan autentikasi dasar: menempelkan string kredensial (nama pengguna, titik dua, dan kata sandi), dan alat segera menghasilkan nilai Base64. Bandingkan hasilnya dengan pengiriman header, dan ketidakcocokan terlihat. Sebaliknya, tempelkan nilai header dari log jaringan, hapus awalan Dasar, dekode untuk melihat apa yang dilihat server.
Untuk pembelajaran, tempel admin:s3cret dan amati hasilnya, lalu ubah kata sandi untuk melihat bagaimana Base64 berubah. Memahami bagaimana header dibuat menjelaskan mengapa decoding memerlukan pengetahuan format RFC dan mengapa titik dua adalah elemen struktural, bukan Base64. Pemeriksaan lokal harus menggunakan kredensial yang dibuat, bukan kata sandi langsung yang disalin dari produksi. Enkode pasangan tersebut, pindahkan keluarannya kembali ke panel masukan, dan dekodekan. Tanda baca yang cocok dan karakter tambahan yang tepat membuktikan representasi bolak-balik sebelum header dikirim ke mana pun.