Habrozhitel yang terhormat! Para ahli yang terhormat! Saya mempersembahkan bagi penilaian Anda konsep baru identifikasi pengguna di situs web, yang, saya harap, dengan bantuan Anda akan menjadi standar Internet terbuka, membuat dunia internet ini sedikit lebih baik. Ini adalah versi konsep protokol otentikasi tanpa kata sandi, yang dirancang sebagai artikel gratis. Dan jika ide yang mendasarinya menerima penilaian positif dari Anda, pembaca yang budiman, saya akan terus menerbitkannya di reddit.com dan rfc-editor.org. Dan saya berharap bahwa saya akan dapat menarik minat pengembang browser terkemuka dalam implementasinya. Karena itu, saya mengharapkan kritik yang membangun dari Anda.

Perhatian: banyak teks.


Jadi pertanyaannya adalah. Apakah mungkin mengidentifikasi pengunjung situs secara jelas tanpa mengungkapkan data pribadi mereka dan melacak antara situs yang berbeda? Apakah mungkin, menyelesaikan masalah seperti itu, untuk menolak bentuk otorisasi yang paling primitif dengan login / kata sandi dan menggunakan cookie / localStorage?

Di satu sisi, situs harus mengenali klien secara berurutan, misalnya, untuk "mengembalikan" pengaturan, keranjang produk, iklan, artikel, dll. Di sisi lain, pengunjung ingin tetap anonim mungkin, tanpa mengungkapkan data pribadi mereka, dan mencegah situs pihak ketiga melacaknya. Dan yang terakhir dapat melakukan ini dengan bertukar di antara mereka sendiri data yang dikumpulkan.

Kedengarannya seperti tugas untuk memastikan bahwa serigala penuh, dan domba-domba aman. Apakah ini nyata?

Saya, sampai batas tertentu, saya pikir - sungguh.

Daftar isi

1 Konsep otentikasi tanpa kata sandi
1.1 Kunci dan token alih-alih login dan kata sandi
1.2 Struktur Token
1.3 header protokol HTTP
1.4 Bagaimana cara pelanggan mengidentifikasi situs?
1.4.2 Bagaimana saya tahu jika suatu situs mendukung protokol ini?
1.5 Bagaimana cara klien mengotorisasi situs?
1.6 Bagaimana menerapkan identifikasi pelanggan yang andal?
1.7 Otorisasi di situs melalui mata pengguna
1.8 Bagaimana perubahan kunci situs?
1.9 Bagaimana penerapan otorisasi lintas-domain?
1.10 Bagaimana cara menerapkan otentikasi lintas-domain?
1.11 Mobilitas Akun

2 Deskripsi teknis protokol
2.0 Algoritma Pembangkitan Kunci Domain
2.1 algoritma untuk menghitung token sumber
2.2 Algoritma perlindungan token selama transfer
2.3 Prosedur pertukaran garam antara browser dan server
2.4 Aturan untuk pembentukan bidang Konteks
2.5 Aturan untuk mendefinisikan bidang Pengirim dan Penerima
2.6 Rincian tentang Tabel Definisi Konteks
2.7 Skenario Protokol
2.8 Memproses token di server
2.9 Otentikasi lintas-domain

3 Rekomendasi Keselamatan
3.1 Perlindungan informasi utama dari akses tidak sah
3.2 Tentang kata sandi sebagai kunci domain
3.3 Risiko kehilangan / kompromi kunci dan meminimalkannya

4 Serangan pada skema otorisasi
4.1 Pelacakan Pengguna
4.2 serangan XSS
4.3 Serangan CSRF
4.4 Pelacakan menggunakan SSO
4.5 Kompromi Kunci untuk SSO
4.6 Token kompromi selama transfer
4.7 Meretas situs web dan token yang membahayakan

Kesimpulan

1 Konsep otentikasi tanpa kata sandi

1.1 Kunci dan token alih-alih login dan kata sandi

Untuk setiap domain, termasuk yang anak-anak, browser klien secara acak menghasilkan kunci 256-bit yang unik $$ . Kunci ini tidak pernah dikirimkan. Tetap konstan dalam sesi pengguna. Setiap sesi baru menciptakan kunci baru.
Berbasis kunci $$ browser menghasilkan token 256-bit ^* menggunakan algoritma khusus $$ untuk mengidentifikasi pengguna dengan domain tertentu. Token identifikasi $$ pengguna (selanjutnya hanya disebut sebagai token) berfungsi sebagai pengganti cookie sesi seperti PHPSESSIONID dan JSESSIONID.
Kunci $$ dapat " diperbaiki " oleh pengguna. Memperbaiki kunci akan memungkinkan pengguna untuk tetap berwenang di situs untuk waktu yang tidak terbatas dalam sesi browser yang berbeda dan mengembalikan otorisasi yang sudah ada sebelumnya. Ini adalah analog dari fungsi "ingat saya" .
Ketika komit dibatalkan, browser akan "lupa" kunci ini dan akan mulai lagi menghasilkan kunci acak untuk domain ini untuk setiap sesi baru (mulai dari yang sekarang), yang analog dengan "keluar" pengguna dari situs. Outputnya instan, tidak perlu memuat ulang halaman.
Pengguna dapat membuat kunci permanen untuk domain . Kunci permanen, serta yang tetap, akan memungkinkan pengguna untuk mengembalikan otorisasi sebelumnya. Bahkan, kunci ini menjadi pengganti koneksi login-kata sandi.
Pengguna mendapat kesempatan untuk mengontrol kapan browser untuk domain akan menggunakan kunci konstan, dan kapan - acak. Ini adalah analog dari fungsi masuk / keluar . Konsepnya disajikan dalam screenshot di bawah ini .
Metode untuk menghasilkan kunci domain persisten menyediakan mobilitas akun pengguna antara perangkat yang berbeda. Protokol mendefinisikan berikut ini:

• pembuatan kunci domain berdasarkan kunci master pengguna
• secara individual membentuk kunci domain berdasarkan pada sensor angka acak biologis
• mengimpor kunci yang ada dari file kunci dari perangkat lain

1.2 Struktur Token

Token adalah struktur 256-bit, direpresentasikan sebagai string heksadesimal:

Bagian identifikasi token (128 bit tertinggi) mirip dengan login. Dengan urutan bit ini, server dapat secara unik mengidentifikasi pengguna.
Bagian otentikasi token (128 bit yang lebih rendah) mirip dengan kata sandi. Urutan bit ini membantu server memvalidasi token.
Aturan validasi token dijelaskan di bawah ini .

1.3 header protokol HTTP

Tajuk yang digunakan oleh klien:

CSI-Token : <Token> digunakan untuk mengirim token ke server
CSI-Token : <Token1>; Changed-To <Token2> digunakan untuk mengubah token saat ini:

• saat mengotorisasi pada kunci permanen,
• saat mendaftarkan kunci permanen,
• saat mengubah kunci permanen.

CSI-Token : <Token> Permanen digunakan ketika memperbaiki kunci acak saat ini oleh pengguna.
CSI-Token : <Token> Logout digunakan untuk mengakhiri sesi saat ini secara prematur.

Header yang digunakan oleh server:
Dukungan CSI: yes memberi tahu klien bahwa server mendukung protokol otorisasi CSI.
CSI-Token-Action: sukses digunakan untuk memberi tahu browser tentang penerimaan token pengguna baru (tombol Change-To).
CSI-Token-Action: batalkan membatalkan prosedur untuk mengubah token (kembalikan ke token sebelumnya).
CSI-Token-Action: pendaftaran memberi tahu browser bahwa token pengguna baru masih dalam proses pendaftaran.
CSI-Token-Action: kesalahan verifikasi token sisi server tidak valid .

Akhirnya
CSI-Salt dikirim oleh browser dan server saat bertukar "garam" yang digunakan untuk melindungi token (bagian otentikasi). Lihat di bawah untuk detail lebih lanjut.

1.4 Bagaimana cara pelanggan mengidentifikasi situs?

Situs dapat menggunakan token untuk mengidentifikasi pengunjung situs. Pada saat yang sama, skema pembuatan token dan kapasitas 256-bit mereka menjamin token unik untuk setiap pasangan: domain pengguna. Domain lain akan melihat token pengguna lain. Bahkan jika dieksekusi dalam konteks situs target (via IFRAME, IMG, LINK, SCRIPT). Selain itu, algoritma pembuatan token khusus melindungi pengguna dari XSS, serangan SRF dan membuatnya mustahil untuk melacak pengguna tanpa sepengetahuannya. Tetapi pada saat yang sama, teknologi SSO tetap dimungkinkan dengan izin dan identifikasi lintas-domainnya.
Token ditransmisikan dalam header HTTP CSI-Token dengan setiap permintaan ke sumber daya domain apa pun (halaman, dokumen, gambar, skrip, gaya, font, file, permintaan ajax, ...):

Token dihitung ulang pada setiap permintaan HTTP (S) : halaman, gambar, permintaan ajax.
Untuk mengoptimalkan perhitungan, cache token oleh browser diizinkan, tetapi hanya selama durasi sesi dan hanya jika kondisi untuk memenuhi permintaan tetap tidak berubah.
Seperti disebutkan di atas, token dapat berfungsi sebagai pengganti cookie sesi seperti PHPSESSIONID dan JSESSIONID. Satu-satunya perbedaan adalah bahwa jika situs yang sebelumnya menghasilkan pengidentifikasi bagi pengunjung untuk melacak pengguna tertentu antara permintaan yang berbeda (setelah semua, ribuan permintaan dari pengguna yang berbeda datang ke situs pada saat yang sama), sekarang klien itu sendiri melakukan fungsi ini.
Identifikasi semacam itu cukup memadai untuk memungkinkan Anda melakukan pembelian di toko online, beriklan di situs yang sesuai, menulis di forum, di jejaring sosial, Wikipedia, atau artikel Habré.
Ya, pengguna tetap anonim untuk situs tersebut. Tapi itu bisa menjadi "akrab" anonim ke situs. Dan server dapat menyimpan token pengguna semacam itu di sisinya, bersama dengan datanya (akun pribadi dengan pembelian, preferensi, karma, roti, suka, dan bonus lainnya). Tetapi hanya untuk tetap dalam kondisi selesainya proses bisnis apa pun: pembelian, penyerahan pengumuman, dll. Ketentuannya ditentukan oleh situs itu sendiri.
Seperti yang Anda lihat, protokolnya sesederhana mungkin untuk situs yang tidak perlu mendaftarkan Anda sebelum memberi Anda kesempatan untuk mengambil tindakan apa pun. Tetapi mereka yang membutuhkannya akan sedikit lebih sulit. Tetapi lebih lanjut tentang itu di bawah ini.

1.4.2 Bagaimana saya tahu jika suatu situs mendukung protokol ini?

Situs harus lulus Dukungan CSI: ya http-header di bagian Header Respons dari responsnya:

Setelah melihat judul seperti itu, peramban akan memberi tahu pengguna bahwa ia dapat menyelamatkan dirinya di situs. Misalnya, simbol kunci di bilah alamat:

Mengklik pada kunci, misalnya, akan membuat kunci untuk domain www.youtube.com :

Pembentukan kunci baru tidak mengarah pada penggunaan otomatisnya.

Kunci permanen mulai digunakan hanya ketika diaktifkan oleh pengguna.

1.5 Bagaimana cara klien mengotorisasi situs?

Penting untuk dipahami bahwa token belum membuat pengguna diotorisasi di situs tertentu - hanya dikenali. Tetapi, seperti yang telah dikatakan, untuk saat ini Anda hanyalah "orang anonim" yang dikenali.
Jika situs perlu mengaitkan token Anda dengan Anda secara pribadi, pendaftaran di situs tersebut, sayangnya, tidak dapat dihindari. Tetapi dalam protokol yang diusulkan, ini dibuat sedikit lebih mudah.

Penting bagi pengembang untuk memahami: sebagian besar situs tidak memerlukan kuesioner. Hindari memaksa pengunjung untuk mendaftar. Dalam situasi paling umum, Anda dapat melakukan proses bisnis tanpa mengumpulkan pengunjung PD.

Mengisi formulir pendaftaran yang membosankan "dengan atau tanpa" tidak menyenangkan. Tetapi dengan protokol baru, membuat login dan kata sandi lain tidak lagi diperlukan. Hanya tombol Konfirmasi dan Simpan Saya:

Anda, tentu saja, harus terlebih dahulu membuat kunci permanen untuk situs tersebut. Tapi ini masalah beberapa klik mouse.
Dan, pasti, Anda akan diminta untuk mengkonfirmasi telepon atau alamat surat Anda. Tapi itu sudah tergantung situsnya.
Setelah otorisasi berhasil, server, melalui tajuk HTTP khusus, CSI-Token-Action akan memberi tahu browser bahwa ia telah menerima kunci baru. Lebih detail di bab II .

1.6 Bagaimana menerapkan identifikasi pelanggan yang andal?

Dalam situasi yang lebih serius (akun pribadi penyedia, hosting, bank) otentikasi dua faktor harus dan dapat dilakukan, dan bukti kepemilikan token dapat dilakukan melalui pra-pendaftaran dan konfirmasi identitas dengan cara lain: melalui email, SMS, atau bahkan dengan kertas yang memperbaiki token pengguna. (Ya, ya. Sertifikat dicatat di atas kertas, mengapa tidak token).

1.7 Otorisasi di situs melalui mata pengguna

Browser memberi tahu pengguna bahwa situs tersebut mendukung otorisasi CSI melalui ikon kunci di bilah alamat. Jika Anda melakukan beberapa tindakan di situs, Anda dapat meminta situs untuk mengingat Anda. Mulai saat ini, server akan mengenali pengguna bahkan di antara sesi yang berbeda:


Alih-alih memperbaiki kunci, pengguna dapat membuat kunci permanen untuk situs dan mendaftar di sana. Ilustrasi animasi:


Dan ketika pengguna memiliki kunci permanen untuk situs dan kunci ini terdaftar di sana, proses masuknya sangat disederhanakan:


Kekuatan terbesar dari protokol dimanifestasikan ketika pengguna membuat kunci untuk situs berdasarkan kunci utama. Dalam hal ini, masalah identifikasi Anda di situs di perangkat lain mudah diselesaikan . Animasi berikut menunjukkan ini. Diasumsikan bahwa Anda sebelumnya membagikan kunci utama Anda satu kali antara perangkat / browser Anda:


Untuk situs dengan otorisasi dua faktor, "pengenalan" mungkin terlihat seperti ini:


Keluar lebih mudah. Klik "Logout" di browser dan hanya itu:

Browser mengirim permintaan ke situs (pada halaman mana saja) dengan metode HEAD, di mana ia mengirimkan header CSI-Token <>; Logout.

Server, melihat tajuk seperti itu, membuat Logout. Jika itu adalah kunci tetap, maka situs menghapus semua informasi tentang pengguna (lebih dari kunci seperti itu tidak akan pernah muncul). Jika itu adalah kunci permanen, cukup istirahat sesi.
Setiap aktivitas lebih lanjut dari situs mengubah pengguna menjadi anonim yang tidak dikenal ke situs: memuat ulang halaman, mencoba membuat permintaan ajax, mengunduh file, dll. - Browser akan mengirim token yang dihasilkan berdasarkan kunci acak.

Anda dapat mengelola kunci di manajer kunci: mengubah kunci permanen, mengekspor kunci permanen ke file, mengimpor dari file dari perangkat lain. Atur "keluar otomatis" setelah menutup tab atau peramban. Atur durasi kunci tetap.

1.8 Bagaimana perubahan kunci situs?

Mengganti kunci permanen situs secara teknis sama dengan mengubah dari kunci acak ke kunci permanen. Ini dijelaskan secara lebih rinci dalam bab II .
Jika mengubah kunci permanen situs, browser memberi tahu situs tentang perubahan yang sesuai dalam token, mengirimkan header CSI-Token dengan kunci Changed-To di setiap permintaan berikutnya :

Situs harus memproses permintaan semacam itu dengan benar. Dan, jika token pengguna tertentu disimpan dalam database-nya, itu harus melakukan penggantian yang sesuai. Pada saat yang sama, situs harus menanggapi browser tentang perubahan token yang berhasil di pihaknya. Dia melakukan ini di header Header Respons dengan parameter: CSI-Token-Action: sukses , menunjukkan token yang diterapkan.
Situs memiliki hak untuk menolak upaya untuk mengubah token (misalnya, jika tidak ada token seperti itu dalam database-nya atau tidak menyimpannya sama sekali) dengan CSI-Token-Action: parameter yang dibatalkan.
Sampai browser menerima header CSI-Token-Action, itu akan menambahkan kunci Changed-To ke setiap permintaan CSI-Token ke situs.
Ini adalah analog dari "perubahan kata sandi" pengguna.

1.9 Bagaimana penerapan otorisasi lintas-domain?

Otorisasi lintas domain klasik menggunakan teknologi SSO memiliki banyak keuntungan bagi pengguna. Anda tidak perlu mengingat banyak kata sandi dari banyak situs. Tidak perlu mendaftar dan mengisi formulir suram. Beberapa server otorisasi menanyakan hak apa untuk memberikan situs yang meminta SSO.
Namun ada juga kekurangannya. Anda bergantung pada penyedia SSO. Jika server SSO tidak berfungsi, Anda tidak akan sampai ke situs target. Jika Anda kehilangan kata sandi atau akun Anda dicuri - Anda kehilangan akses dari semua situs sekaligus.
Untuk pengembang web, masalahnya sedikit lebih rumit. Dari awal, Anda perlu mendaftarkan situs Anda di server otorisasi, mendapatkan kunci, mempelajari cara bekerja dengan protokol ( SAML , OAuth , dll.) Dan pustaka yang sesuai, pastikan bahwa kunci tidak kedaluwarsa, bahwa server otorisasi tidak memblokir situs Anda karena alasan dan dll. Ini adalah biaya untuk fakta bahwa Anda tidak perlu menyimpan akun pengguna, melakukan formulir pendaftaran, login, dll. Kebenaran meningkatkan biaya pemeliharaan (dalam bentuk perbaikan kegagalan mendadak). Sekali lagi, jika server tiba-tiba tidak tersedia di situs, maka sayang sekali.
Skema otorisasi ini membuat SSO sedikit lebih aman, dan otorisasi untuk semua peserta lebih mudah. Tentang keamanan akan dibahas di bawah di bagian "Kompromi Kunci untuk SSO".

Lihat situs S, yang mendukung SSO Google. Misalkan Anda memiliki akun Google. Untuk masuk, Anda mengklik tautan "Masuk dengan Google", yang akan membuka tab otorisasi Google. Peramban akan memberi tahu Anda bahwa Anda memiliki kunci untuk Google. Dan Google akan memberi tahu Anda apa hak S. permintaan.
Jika Anda setuju, klik "Masuk" di manajer kunci. Halaman akan dimuat ulang. Google sudah akan menerima token yang valid, mengenali dan mengotorisasi Anda. Dan dengan permintaan antar-server, ia akan memberi tahu Situs S tentang informasi akun Anda sesuai dengan bidang yang diminta.
Halaman yang dimuat ulang akan berisi tombol "Next" yang mengembalikan Anda ke situs target.


Situs S dapat memutuskan untuk menyimpan data tentang Anda di basis datanya atau tidak. Masalah ini berada di luar cakupan skema otorisasi yang diusulkan. Namun lebih lanjut, di mana kami akan mempertimbangkan risiko kehilangan kunci untuk SSO, situs ini direkomendasikan untuk menjaga token pengguna dan pengidentifikasi dari SSO di sisinya, dan pengguna disarankan untuk membuat kunci permanen untuk S.

Kerentanan: Setelah otorisasi tersebut, situs S1, S2, S3, ... (tempat Anda masuk melalui Google) akan dapat mengenali Anda (oleh pengenal yang ditugaskan kepada Anda oleh Google) dan, sebagai hasilnya, melacak aktivitas Anda.

Opsi perlindungan: jangan bekerja secara bersamaan di situs jika Anda mendaftar melalui SSO dari penyedia yang sama. Jika memungkinkan, logout dari server otorisasi segera setelah otorisasi selesai ("keluar otomatis" untuk domain).

1.10 Bagaimana cara menerapkan otentikasi lintas-domain?

Semua ini tentu saja bagus. Sementara pekerjaan dilakukan pada satu browser - semuanya baik-baik saja. Tetapi bagaimana dengan realitas modern ketika seseorang memiliki dua ponsel, satu komputer yang berfungsi dan beberapa browser di atasnya, komputer di rumah, dan laptop lain? Ditambah tablet biasa untuk istri / anak-anak.
Kita harus entah bagaimana menyelesaikan masalah mentransfer kunci domain antara browser, perangkat. Dan juga menyelesaikan masalah sinkronisasi yang benar.
Salah satu mekanisme untuk menyelesaikan masalah ini adalah menghitung berbagai kunci domain berdasarkan kunci master umum tanpa kemungkinan pemulihan kunci master dari kunci domain yang dikenal.
Dengan membuat kunci pribadi K untuk domain D menggunakan kunci master M pada satu perangkat, pengguna akan dapat membuat kunci K yang sama untuk domain D dan pada kunci lainnya menggunakan kunci master M yang sama dan algoritma tunggal. Lebih tepatnya, ini akan dilakukan bukan oleh pengguna, tetapi oleh browsernya. Dengan pendekatan ini, cukup bagi pengguna untuk mendistribusikan kunci masternya di antara semua browser yang digunakan olehnya dan dia "mentransfer semua kunci" dari domain sekaligus. Pada saat yang sama membuat cadangan dengan cara ini.
Kenyamanan pengguna maksimal. Tetapi juga risiko maksimum dalam kasus kompromi dari kunci utama. Karena itu, yang terakhir harus dilindungi. Risiko kehilangan atau kompromi dari kunci utama, dan cara untuk meminimalkan risiko tersebut dijelaskan dalam bab "3 Rekomendasi Keselamatan" .
Menggunakan hanya satu kunci utama untuk menghasilkan semua kunci untuk semua domain tidak selalu merupakan pilihan yang nyaman. Pertama, apa yang harus dilakukan jika tiba-tiba kunci domain dikompromikan dan perlu diubah? Kedua, bagaimana jika Anda perlu membagikan kunci domain dengan orang lain? Misalnya antar anggota keluarga. Atau apakah itu akun akses surat publik perusahaan. Lalu bagaimana cara "mengambil" kunci Anda (karena sebenarnya telah dikompromikan)?
Oleh karena itu, pembuatan kunci domain individual menggunakan sensor angka acak biologis harus didukung oleh browser. Tetapi kemudian kami kembali ke pertanyaan tentang mobilitas kami dan masalah sinkronisasi, fungsi mengekspor dan mengimpor kunci di browser, dan membuat salinan cadangan.

Transfer melalui perangkat yang dapat diasingkan secara fisik

Kartu pintar dan token usb bisa sangat cocok sebagai penyimpanan informasi kunci yang aman (karena dibuat untuk ini). Otentikasi dua faktor melindungi kunci dari akses tidak sah dengan akses langsung ke perangkat.
Benar, kartu pintar memerlukan pembaca khusus (belum lagi driver), yang membatasi penggunaannya hanya untuk workstation yang dilengkapi dengan pembaca tersebut.
Dengan token USB sedikit lebih mudah. Hanya driver yang diperlukan. Tetapi Anda tidak dapat menempel token seperti itu di telepon. Dan meskipun untuk ponsel ada token yang dibuat dalam bentuk kartu SD, tidak untuk mengatakan bahwa solusi ini menambah mobilitas. Cobalah untuk menggambar kartu dari ponsel, tetapi masukkan ke kartu lain. Dan bukannya ini tidak mungkin. Masalahnya adalah itu tidak nyaman.
Dan jika tokennya rusak? Maka semua kunci Anda akan pergi ke Cthulhu Besar.
Jadi akan ada godaan dengan skema seperti itu untuk menggunakan beberapa perangkat duplikat. Tetapi kemudian Anda masih perlu menyelesaikan masalah sinkronisasi kunci jika Anda memiliki beberapa kartu pintar.
Dan, sejujurnya, perangkat tersebut tidak dilindungi dari keyloggers. Sekarang, jika kode pin akan dimasukkan dari kartu / token itu sendiri. Lalu satu hal lagi. Tetapi saya belum melihat sifat seperti itu.

Pro: kunci 256-bit acak dapat digunakan; keamanan tinggi melalui penggunaan otentikasi dua faktor; tingkat perlindungan tertinggi terhadap kerusakan langsung.
Cons: ketergantungan perangkat; membutuhkan biaya finansial; mobilitas rendah; kebutuhan untuk memesan kartu dan, sebagai hasilnya, menyinkronkan data di antara mereka; kerentanan terhadap keylogger tetap ada.

Sinkronkan melalui layanan online

"Teknologi cloud" sekarang didorong sedapat mungkin. Tampaknya mereka, bersama dengan blockchain, telah menjadi pengganti "teknologi pisang." Secara alami, ada keinginan untuk menggunakan platform Internet tertentu untuk pertukaran informasi utama. Semacam kartu pintar "online".
Apa? Anda masuk menggunakan skema kami secara anonim di situs tersebut; kirim kunci Anda yang dienkripsi dengan kata sandi di sana; Anda pergi dari perangkat lain ke situs yang sama dengan kunci / kata sandi yang sama; Anda mendapatkan kunci dari sana; Anda menyinkronkan perubahan pada tanggal pengeditan. Mirip dengan pengelola kata sandi, hanya ini yang online.
Hanya saja, tidak ada yang menjamin bahwa layanan online tidak akan diretas atau tidak akan menggabungkan kunci Anda, meskipun dienkripsi, "jika perlu". Siapa yang akan menerapkan layanan seperti itu secara gratis. Itu dia.
Meskipun, tentu saja, kata sandi melindungi kunci dari penggunaan langsung. Tetapi apakah kata sandi Anda tahan terhadap kekerasan "offline"? Itu pertanyaan lain.

Kelebihan: mobilitas kredensial tinggi; independensi perangkat dan browser; Anda hanya perlu satu kata sandi tunggal (walaupun mereka tidak meninggalkan kata sandi, itu sudah lebih baik).
Kekurangan: kurang aman daripada menyimpan kunci pada media yang bisa diasingkan. Bahkan, keamanan kunci didasarkan pada kekuatan kata sandi untuk pemilihan.

Anda tentu saja dapat menggunakan kunci utama untuk mengenkripsi kunci lain. Yang dengannya kunci domain lainnya dihitung. Sebagai pilihan.

2 Deskripsi teknis protokol

2.0 Algoritma Pembangkitan Kunci Domain

Protokol ini hanya mendefinisikan 2 metode untuk menghasilkan kunci domain.

• berdasarkan generator angka acak (lebih disukai biologis)
• berdasarkan kunci master 256-bit

Dalam kasus terakhir, kunci domain dihitung sebagai:

$$

dimana $$ - Kunci utama 256-bit, Domain - nama domain tempat kunci dibuat.
Selanjutnya, HMAC adalah algoritma kriptografi hash berdasarkan implementasi 256-bit dari fungsi hash SHA-2 .

Kompromi atau pengungkapan sukarela atas kunci domain tidak membahayakan kunci master asli.

Kunci master menyediakan mekanisme untuk mobilitas kredensial pengguna.

Jika kunci yang dibuat atas dasar "master" dikompromikan, atau token yang dihitung dari kunci tersebut (sebagai hasil peretasan situs) dikompromikan, maka kunci tersebut harus diubah. Anda bisa mengubahnya menjadi kunci 256-bit acak, atau menghasilkannya dari "wizard" yang sama, dengan tambahan versi:

$$

Selanjutnya, simbol $$ akan digunakan untuk operasi penggabungan string (byte array).

2.1 algoritma untuk menghitung token sumber

Token otentikasi pengguna dihitung dengan setiap permintaan sumber daya domain apa pun. Untuk menghitung token permintaan, data berikut diambil:

• Pengirim - nama domain pemrakarsa permintaan (bisa berupa halaman dengan iframe atau skrip dari domain orang lain yang melakukan pengambilan),
• Penerima - nama domain penerima (tempat permintaan dikirim),
• Konteks - permintaan konteks eksekusi,
• Perlindungan - urutan acak 32 byte (256-bit), jika Konteks kosong; jika tidak, kosong

Data ini digabungkan dan di-hash dengan 256-bit SHA-2 pada kunci K dari domain yang memulai permintaan :

$$

Token yang valid diperoleh saat Konteks tidak kosong. Untuk identifikasi yang tepat di situs target, syarat Pengirim = Penerima = Konteks harus dipenuhi.

Bidang Konteks, bersama dengan Perlindungan, digunakan untuk melindungi terhadap serangan XSS dan CSRF , serta dari pelacakan pengguna.
Penjelasan lebih rinci tentang aturan untuk menentukan Pengirim / Penerima / Konteks akan diberikan di bawah ini.

2.2 Algoritma perlindungan token selama transfer

Token klien asli ditransmisikan sangat jarang. Hanya ketika mentransfer token yang tidak terdaftar pada saat sesi dibuat.
Token dianggap tidak terdaftar jika: dibuat berdasarkan kunci acak (tidak tetap); tidak diterima oleh server setelah mengirim kunci Ubah Ke atau Permanen. Untuk detail lebih lanjut lihat “Memproses token di server” .
Browser dan server bersama-sama menghasilkan sepasang angka acak, yang disebut salt (Salt), dengan mana 128 bit lebih rendah dari token di-hash. Keduanya bertukar angka-angka ini sesuai dengan protokol. Untuk perinciannya, lihat “Browser Garap Prosedur Browser-Server” .
Dengan demikian, server situs melihat token berikut:

$$

dimana $$ - tinggi 128 bit, $$ - 128 bit lebih rendah dari token asli, $$ - Rangkaian senar. Dalam hal ini, token awal $$ seharusnya sudah diketahui ke server.

Idealnya, CSI-Salt harus berubah setiap kali browser meminta server. Namun, ini bisa menjadi persyaratan mahal dalam hal sumber daya komputasi. Selain itu, dapat "membunuh" kemampuan untuk mengirim permintaan paralel ke server.
Oleh karena itu, untuk mengoptimalkan perhitungan, diperbolehkan untuk menjaga nilai CSI-Salt tidak berubah dalam permintaan yang berbeda, tetapi tidak lebih dari satu sesi . Ini bisa berupa batas waktu (perubahan CSI-Salt setiap 5 menit), atau reaksi terhadap intensitas permintaan (perubahan CSI-Salt setiap 100 permintaan), atau setelah setiap rangkaian permintaan (pada saat jeda, client-server), atau versi campuran. Di sini keputusan diserahkan kepada pengembang browser.
Menjaga agar CSI-Salt tidak berubah terlalu lama melemahkan perlindungan token yang ditransmisikan, memungkinkan penyerang untuk mencegat token sementara pengguna yang sah telah menyelesaikan Logout dan menjalankan permintaan tidak sah atas nama korban.

2.3 Prosedur pertukaran garam antara browser dan server

2.3.1 Token berdasarkan kunci server ^[1] acak atau tidak terdaftar.

2.3.2 Token berdasarkan kunci yang didaftarkan oleh server ^[1] .

---

^{[1] Token dianggap tidak terdaftar jika: dibuat berdasarkan kunci acak; tidak diterima oleh server setelah mengirim kunci Ubah-Ke atau Permanen dengan CSI-Token-Action: respons sukses.
[2] Waktu melalui perubahan CSI-Salt ditentukan oleh peramban itu sendiri. Ini dapat terjadi setelah serangkaian permintaan, setelah batas waktu, setelah sejumlah permintaan. – CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

Kami akan memanggil kami satu domain, yang kita memuat halaman (ditampilkan di address bar browser Anda). Domain yang tersisa akan disebut eksternal . Bahkan jika ini adalah domain anak yang diberikan.

Kami menyebut sumber daya eksternal jika itu diunduh dari domain eksternal. Kami akan memanggil sumber daya internal jika itu diunduh dari domain kami. Sumber daya dapat berupa skrip, gambar, permintaan ajax dan file lainnya.

Sebuah skrip dianggap eksternal jika diunduh dari domain eksternal. Script yang ditempatkan di tag <script> yang dibuat, dibuat oleh skrip eksternal, juga akan dianggap eksternal. Skrip yang terletak di tag <script> yang dimodifikasi dinyatakan eksternal jika dimodifikasi oleh skrip eksternal, atau skrip eksternal ada di rantai panggilan saat isinya berubah. Bahkan jika pada saat yang sama <script> ini pada awalnya di halaman atau dibuat oleh skrip internal.

Kami akan memberi nama LINK, SCRIPT, IMG, tag IFAME, dan lainnya, yang mengharuskan browser memuat beberapa sumber daya segera setelah dipenuhi oleh tag parser - sumber daya DOM .

Kami akan memberi nama tag FORMULIR, A, META, dan lainnya, yang dapat memulai pemuatan halaman dalam kondisi tertentu (kirim, klik,batas waktu) - memulai tag.

Kami akan memanggil tag statis jika awalnya ada pada halaman ketika pertama kali dikeluarkan oleh server. Kami akan memanggil tag dinamis jika tag itu dibuat dalam proses menjalankan skrip.

Tag FORMULIR dinyatakan dinamis, meskipun bukan hanya tag itu sendiri yang telah berubah, tetapi juga nilai-nilai semua bidang INPUT yang terkait dengan formulir ini.

Kami akan memanggil tag dinamis kami sendiri jika skrip yang membuatnya milik domain kami, dan rantai panggilan dari instruksi yang menghasilkan tag ini tidak memiliki fungsi milik skrip eksternal. Kalau tidak, kami menganggap tag dinamis seperti itu tidak tepat .

Pemuatan halaman dipicu dengan memulai tag.Tag awal dapat diaktifkan secara langsung oleh pengguna, atau diaktifkan oleh skrip, dengan menjalankan perintah klik (untuk tautan), dan mengirimkan (untuk formulir), atau dengan skrip yang menghasilkan acara onclick / onsubmit yang sesuai.

Selain itu, tag pengaktifan dapat diaktifkan oleh browser. Contoh dari tag tersebut adalah META dengan parameter http-equiv = "refresh" content = "0".

^{Tabel P. Nilai konteks dalam berbagai kondisi pembukaan halaman}


Jika tag sumber daya diubah oleh skrip (misalnya, atribut SRC dari IMG), dan kemudian sumber daya dimuat secara otomatis oleh browser, maka kami percaya bahwa konten / sumber daya dipicu oleh parser, metode pemuatan adalah tag, tetapi status tag ini menjadi "dinamis".

^{Tabel R. Nilai konteks dalam kondisi berbeda untuk memuat konten / sumber daya}

---

^{[1] Tag awal
[2] Tag sumber daya
[3] Mewarisi halaman sendiri, Kosong saat membuka halaman domain asing
[4] Mewarisi saat mengarahkan server ke halaman mereka, Kosong saat mengarahkan ulang ke domain lain atau membuka halaman dari sumber eksternal (lihat ( klarifikasi )}


Tanda bentuk P1..PF, R1..RC akan digunakan untuk merujuk ke sel yang sesuai dalam tabel saat menganalisis situasi tertentu.

Perhatikan Referer dan Domain yang disorot di tabel pertama. Anda hanya dapat diotorisasi di situs ketika Anda sendiri membuka situs di alamat langsung, atau dengan tautan dari situs lain, dengan memuat ulang halaman berikutnya atas inisiatif Anda sendiri.

2.5 Aturan untuk mendefinisikan bidang Pengirim dan Penerima

Pengirim adalah domain dari halaman / skrip / gaya dari mana permintaan itu berasal. Halaman ini meminta gaya, gambar, skrip. Script meminta konten melalui ajax. Gaya dapat memuat gaya lain. Ini adalah pemrakarsa permintaan.

Penerima adalah domain yang benar-benar dituju.

Agar tidak ada pertanyaan yang tersisa, mari kita perhatikan contoh-contoh spesifik.

Biarkan ada situs site.net. Di halaman utama situs adalah:

• style site.net/css/common.css
• gaya common.css mengimpor fonts.google.com/fonts/Roboto.css gaya
• Gaya Roboto.css mengimpor font fonts.google.com/fonts/Roboto.ttf
• gambar mengarah ke img.site.net/picture1.jpg
• bingkai dimuat dari adriver.ru/frame
• skrip dari adm.site.net/admin.js

Biarkan dalam bingkai (dengan adriver.ru) terhubung:

• gaya dari adriver.ru/style.css
• gambar dari img.adriver.ru/img/01.png
• skrip dari adriver.ru/libs.js
• skrip dari api.adriver.ru/v1/ad.js

Nilai pengirim / penerima saat memuat sumber daya dengan parser DOM

Sekarang, mari kita lihat nilai Pengirim / Penerima ketika memuat konten dengan skrip selama eksekusi permintaan ajax.

Nilai pengirim / penerima saat memuat konten dengan skrip

2.6 Rincian tentang Tabel Definisi Konteks

Mari kita pertimbangkan secara lebih rinci opsi apa untuk membuka halaman (tab di browser) yang kita miliki, dan nilai Konteks apa yang akan diperoleh.

P1 - pengguna di halaman sebelumnya mengklik tautan atau klik tombol kirim pada formulir. Handler browser peristiwa standar untuk tautan / formulir mengarahkan pengguna ke halaman ini. Situasi normal Transisi aman antara halaman domain atau domain berbeda.

Saat beralih ke site.net dari domain google.com lain, Konteks akan sama dengan domain sebelumnya (google.com). Dan pengguna di domain site.net baru akan tidak sah (bahkan jika tab tetangga situs ini di mana pengguna diotorisasi terbuka).

Transisi independen berulang dari pengguna (tanpa bantuan skrip) melalui tautan ke situs yang sama akan mengarah lagi ke situasi P1 , tetapi Konteks sudah akan sama dengan domain site.net, karena menurut aturan Konteks = Pengarah.

Itu dibuat untuk melindungiSerangan CSRF .

P5 - pengguna pada halaman sebelumnya mengklik tautan yang dibuat / dimodifikasi oleh skrip yang diunduh dari domain halaman sebelumnya; atau pengguna pada halaman sebelumnya mengklik tombol kirim dari formulir yang dibuat / dimodifikasi oleh skrip (mengubah tag FORMULIR, termasuk bidang INPUT-nya). Handler browser peristiwa standar untuk tautan / formulir mengarahkan pengguna ke halaman ini.

P9 sama dengan P5 , hanya skrip yang eksternal, atau ada fungsi dari skrip eksternal di rantai panggilan (perlindungan dari pengeditan fungsi skrip skrip situs oleh skrip pihak ketiga).

PD - pengguna membuka halaman di alamat langsung. Pembukaan yang aman.

Pengguna harus membuka halaman dengan memasukkan URL di bilah alamat. Atau buka situs dari bookmark browser.

Membuka tautan dari pintasan desktop dari program lain, situasi lain di mana OS mengirimkan perintah ke browser untuk membuka tautan harus dianggap sebagai kasus PG (membuka tautan atas prakarsa browser). Bahkan jika pengguna menekan F5 untuk memuat ulang halaman, ini harus dianggap sebagai kasus PG . Hanya jika pengguna masuk ke bilah alamat dan menekan Enter akan dianggap oleh browser sebagai PD .

Ini dilakukan untuk melindungi serangan CSRF dari program lain.

Mengikuti tautan dari program lain akan mengarahkan pengguna ke situs yang diserang dengan token yang tidak valid dan Konteks kosong, yang akan disimpan bahkan jika pengguna menekan F5 (menyegarkan halaman). Anda tidak dapat login hingga pengguna membuka tautan apa pun ke halaman situs (situasi P1 ).

Dengan demikian, jika seorang penyerang dari program lain memutuskan untuk memberikan tautan ke halaman situs site.net yang menjalankan perintah kepada pengguna yang berwenang, ia tidak akan dapat melakukannya dengan mudah. Penting untuk memaksa pengguna mengklik tautan lain pada halaman ini, lalu memaksa pengguna untuk mengautentikasi di sana, dan hanya setelah itu ... Kemudian, pengguna kemungkinan besar akan berada di halaman lain dari site.net.

P2 - pada halaman sebelumnya untuk tautan atau formulir yang semula ditempatkan pada halaman tersebut, naskah asli halaman sebelumnya menghasilkan klik / ajukan acara. Tidak ada fungsi dalam rantai panggilan milik skrip eksternal. Browser mengarahkan pengguna ke halaman ini.

Jika halaman baru milik domain yang sama, Konteks diwarisi dari halaman sebelumnya. Jika halaman baru milik domain asing, Konteks akan kosong.

P6 sama dengan P2 , hanya tautan / formulir yang dibuat / dimodifikasi oleh skripnya sendiri.

PA sama dengan P2 , hanya tautan / formulir yang dibuat / dimodifikasi oleh skrip eksternal.

PE - skrip pada halaman sebelumnya memicu pembukaan halaman ini dengan command window.location.href atau window.open (...).

Jika skrip halaman site.net mengarahkan pengguna ke halaman domain yang sama, bidang Konteks akan diwarisi dari halaman pembuatan. Dalam hal ini, Konteks = site.net.

Jika halaman ya.ru dibuka, dan skrip memindahkan kami ke maps.ya.ru, maka Konteks halaman baru akan kosong. Dalam tindakan selanjutnya dari pengguna, Konteks akan hampir selalu tetap kosong, yang akan menyulitkan otorisasi pengguna di situs.

Protokol menyiratkan bahwa membuka satu situs dari yang lain adalah operasi yang tidak aman. Ini melindungi pengguna dari pelacakan tidak sah oleh situs-situs ini dan dari serangan CSRF.

P3 - mirip dengan P2 , hanya acara klik / kirim yang dipicu oleh skrip eksternal. Konteks menjadi kosong (urutan byte acak dikirim sebagai gantinya), yang melindungi situs pihak ketiga dari pelacakan situs (jaringan spanduk).

P7 - mirip dengan P6 , hanya tautan / formulir yang dibuat / dimodifikasi oleh skrip eksternal.

PB - mirip dengan PA , hanya tautan / formulir yang dibuat / dimodifikasi oleh skrip eksternal.

PF - mirip dengan PE , hanya skrip provokatif yang eksternal.

P4 - browser memuat ulang halaman sebagai hasil dari pemrosesan tag <META>. Tag awalnya pada halaman. Arahan ulang hukum. Konteks akan bertahan dari halaman asli. Seperti halnya dengan PE .

P8 - browser memuat ulang halaman sebagai hasil dari pemrosesan tag <META>. Tetapi tag itu dibuat / dimodifikasi oleh skripnya sendiri. Ini valid, tetapi Konteks akan tetap ada dari halaman asli. Seperti halnya dengan PE . Tidak mungkin untuk memikat token hukum pengguna dengan cara ini.

PC - mirip dengan P8 , hanya skrip eksternal. Situs yang dibuka akan menerima nomor acak sebagai Konteks.

PG - browser membuka tautan saat perintah dari OS. Bisa jadi, Anda mengklik tautan dari program lain, membuka pintasan di desktop. Ini mungkin perintah dari program lain, tanpa sepengetahuan Anda. Dalam kasus ini, sumber tidak dipercaya, dan bidang konteks akan tetap kosong selama manipulasi pengguna apa pun.

Ini dilakukan untuk melindungi serangan CSRF dari program lain.

Jika browser itu sendiri membuka tab yang disimpan sebelumnya, maka Konteks halaman diatur sama dengan nilai halaman ini pada saat menutup browser.

Selain itu, kategori ini mencakup semua situasi di mana browser diarahkan oleh server ke halaman lain (dari domainnya atau milik orang lain) sebagai hasil dari pemrosesan header HTTP Header. Jika pengalihan pergi ke halaman Anda sendiri, maka nilai Konteks diwarisi. Jika pengalihan pergi ke orang lain, itu diatur ulang.

Ini dilakukan untuk melindungi dari serangan pelacakan server web.

Omong-omong, aturan seperti itu dapat menyebabkan masalah dengan implementasi otorisasi lintas domain saat ini. Jika setelah otorisasi, server SSO mengarahkan pengguna kembali ke situs target, yang terakhir akan anonim di sana.

Untuk mencegah pengguna dari "kehilangan" otorisasi asli di situs target, perlu untuk mengirimkan informasi otentikasi antara permintaan server. Algoritme dapat sebagai berikut:

1. pengguna membuat dan mengaktifkan kunci permanen untuk situs target;
2. Pergi dari situs target ke server SSO sendiri dengan mengklik tautan yang sesuai;
3. mengaktifkan kunci permanen yang ada dari server SSO;
4. Setelah menerima kunci Changed-To, server SSO mengirimkan permintaan antar-server ke situs target;
5. pengguna mengklik tombol "Lanjutkan" pada halaman otorisasi, yang mengembalikannya kembali ke situs target;
6. untuk memenuhi aturan P1 , situs target menawarkan pengguna untuk mengklik tombol tautan lagi, mengarah ke sana (misalnya, ke halaman awal peserta yang diotorisasi).
7. pengguna mengklik tombol tautan, halaman memuat ulang, dan pengguna sudah diotorisasi di situs target.

Deskripsi algoritma sebenarnya terlihat lebih rumit daripada implementasinya. Implementasi UI mungkin terlihat seperti ini:

Memasukkan kembali situs target tidak lagi memerlukan otorisasi SSO dari pengguna. Cukup mengaktifkan kunci permanen.

Sekarang mari kita melihat lebih dekat pada opsi untuk memuat konten pada halaman, dan apa nilai Konteks akan diperoleh berdasarkan permintaan.

R1 - sumber daya dimuat oleh browser sebagai hasil penguraian halaman (browser bertemu dengan tag sumber daya). Nilai Konteks saat membuat permintaan untuk sumber daya diambil dari halaman Konteks yang berisi tag sumber daya.

Misalnya, jika site.net memiliki bingkai adriver.ru di mana gambar dari img.disk.com dimuat, maka ketika membuat permintaan HTTP ke img.disk.com, browser mengambil nilai yang dihitung sebagai Konteks untuk halaman situs.net

R4 sama dengan R1 . Hanya tag sumber daya yang dibuat / dimodifikasi oleh skripnya sendiri, sebagai hasilnya browser DOM Parser berfungsi. Misalnya, pada halaman site.net/index.html, skrip site.net/require.js kami sendiri memasukkan skrip khusus (<script src = ...> tag) site.net/min.js, yang memaksa browser untuk membuat permintaan pengunduhan file. main.js. Bidang konteks dalam permintaan ini akan ditetapkan ke nilai yang dihitung untuk halaman site.net.

R7 sama dengan R1 . Tetapi karena tag sumber daya dibuat / dimodifikasi oleh skrip eksternal, ketika sumber daya diminta, browser akan menghasilkan token berdasarkan Konteks kosong dan urutan 256-bit acak. Akibatnya, skrip eksternal penyerang evil.com/drop.js, disematkan pada halaman domain site.net yang diserang, mencoba memenuhi permintaan ke target site.net atas nama korban akan gagal, karena server akan menerima permintaan dengan token acak dan tidak akan dapat mengidentifikasi pengirim permintaan.

RA - parser mengunduh konten sebagai hasil analisis konten lainnya. Misalnya, stylesheet site.net/css/common.css, yang diunduh untuk halaman site.net/index.html, mengimpor stylesheet fonts.google.com/fonts/Roboto.css, yang memaksa browser untuk meminta fonts.google .com atas nama Referrer = site.net/css/common.css. Nilai konteks dalam hal ini akan sama dengan Pengarah. Selanjutnya, file gaya Roboto.css mengimpor font Roboto.ttf, yang memaksa browser untuk meminta fonts.google.com/fonts/Roboto.ttf atas nama Referrer = fonts.google.com/fonts/Roboto.css. Nilai Konteks akan sama dengan Referrer dalam hal ini, tetapi berbeda.

Misalkan, secara hipotesis, file Roboto.css (sumber daya eksternal) tidak mengimpor font / gaya, tetapi mencoba melakukan serangan CSRF dengan instruksi ini:

@import "https://site.net/api/payment?victim_params" 

berharap untuk memenuhi permintaan di site.net atas nama pengguna yang berwenang. Tetapi masalah bagi penyerang adalah bahwa site.net mengharapkan untuk menerima token dari pengguna:

$$

Kemudian, seperti halnya permintaan CSRF, browser akan membuat token:

$$

Dan permintaan ke situs akan datang atas nama situs anonim yang tidak memiliki hak akses untuk melakukan operasi ini.

RB - konten diunggah oleh skrip situs itu sendiri. Dalam hal ini, Konteks digunakan untuk menghitung token permintaan, yang sama dengan halaman yang berisi skrip. Untuk skrip site.net/1.js dari halaman Konteks site.net, itu akan sama dengan Konteks halaman itu sendiri.

Perhatikan bahwa Konteks halaman itu sendiri tidak selalu sama dengan nama domain halaman dan tergantung pada bagaimana awalnya dibuka.

Misalkan situs penyerang evil.com membuka halaman situs diserang site.net, di mana script site.net/util.js mengeksekusi permintaan dengan parameter yang melewati URL halaman. Penyerang berharap, dengan menyelipkan "parameternya" melalui URL, untuk memaksa skrip site.net/util.js sendiri untuk mengeksekusi permintaan ajax untuk melakukan tindakan penting atas nama korban.

Misalkan pengguna sendiri pergi ke evil.com melalui tautan langsung. Maka Konteks untuk evil.com akan menjadi evil.com. Lebih lanjut evil.com membuka skrip site.net/api/payment?victim_params dengan skrip , berharap melakukan serangan, tetapi bidang Konteks untuk site.net akan kosong (kasus PE / PF). Skrip site.net/utils.js, yang mengeksekusi permintaan ajax, akan memaksa browser untuk mengambil Context dari halaman site.net. Dan itu kosong bersama kita. Tetapi kemudian site.net akan menerima permintaan ajax dengan token ini:

$$

sedangkan untuk pengguna yang berwenang diharapkan:

$$

site.net akan melihat token yang tidak dikenal dan tidak akan dapat mengidentifikasi pengguna. Perlindungan berhasil.

Omong-omong, karena skema semacam itu, melakukan otorisasi lintas-domain melalui pop-up akan menjadi tidak realistis.

Untuk menerapkan SSO di bawah protokol, Anda harus membuka tab baru untuk halaman server otorisasi. Dan pada saat yang sama, pengguna harus membuka tab semacam itu. Opsi terbaik adalah membuka tautan yang sesuai kepada pengguna dari situs target.

Konten RC dimuat dengan skrip situs web eksternal. Dalam hal ini, Konteks digunakan untuk menghitung token permintaan, yang sama dengan bidang Perujuk Permintaan.

Terlepas dari kenyataan bahwa RA , RB dan RC melindungi terhadap serangan CSRF, mereka tetap mengarah pada generasi token konstan. Dan ini memungkinkan Anda untuk menerapkan otentikasi lintas-domain dan otentikasi pengguna lintas-domain (ketika Anda perlu menentukan bahwa beberapa permintaan ke server berbeda berasal dari pengguna ini). Apa yang bisa diimplementasikan untuk memberinya otoritas yang setara pada sekelompok domain terkait.

Jika halaman situs dibuka secara otomatis dari situs lain, Anda tidak akan dapat masuk ke sana, bahkan jika Anda memuat ulang situs ini sendiri. Karena Sumber akan mewarisi dari nilai nol. Peramban harus memberi sinyal kepada pengguna tentang fakta ini (Sumber = Acak):

Hal ini dilakukan untuk melindungi situs yang memaksa jendela sembul lainnya dibuka (sendiri atau skrip eksternal mereka), dan di situs yang terbuka, mereka akan mem-boot ulang atau membuat tombol "tutup" palsu di seluruh layar yang mengarah ke situs yang sama. Yaitu ini mencegah upaya melacak Anda, berharap mendapatkan token yang valid.

Setiap upaya oleh situs untuk meniru tindakan Anda dengan skrip eksternal , atau upaya oleh skrip eksternal untuk secara langsung atau tidak langsung membuat tag awal dan menyelipkannya kepada Anda, akan mengarah ke Sumber kosong dan penambahan byte acak pada saat menghitung hash token.

Trik dengan membuat atau memodifikasi tag <script> di halaman yang diserang di DOM tidak akan membantu. Bidang Sumber akan tetap kosong.

Tetapi dalam kondisi yang sama, skrip internal akan mengarah ke kueri dengan Sumber sama dengan nilai sebelumnya. Dan jika halaman asli memiliki Source = Domain, semuanya akan baik-baik saja. Pengguna akan tetap diizinkan untuk permintaan tersebut.

Tetapi dengan skrip yang diunduh dari sumber pihak ketiga (CDN), masalah mungkin muncul dalam beberapa kasus. Dan itu benar, karena Integritas kode CDN tidak dijamin. Jika Anda ingin tidak kehilangan otorisasi pengguna, simpan skrip di situs Anda dan unduh dari domain Anda. Ini seperti larangan menggunakan tautan http di laman https.

Kami menggambarkan situasi yang mungkin menyebabkan pengembang jatuh. Sebagai hasil dari tindakan pengguna, skrip Anda mengarahkan pengguna yang sah ke salah satu halaman situs (misalnya, ini dilakukan dengan formulir), yang mengharuskan pengguna tetap berwenang. Skrip Anda memanggil, misalnya, $ (form) .submit () menggunakan skrip jQuery yang diambil dari CDN. Dalam hal ini, browser melihat bahwa di tumpukan panggilan yang memicu acara kirim formulir, ada fungsi dari skrip eksternal. Untuk mencegah serangan XSS / CSRF , browser membuat bidang Sumber kosong, dan menambahkan byte acak ke generasi token (kasus P9 ). Akibatnya, pengguna pada halaman baru tiba-tiba menjadi tidak sah dan tidak dapat menyelesaikan operasi. Ini bisa membingungkan bagi pengembang yang terbiasa menggunakan CDN.

2.7 Skenario Protokol

Berikut ini adalah skenario kemungkinan utama dari pengguna yang bekerja dengan situs ini, yang memengaruhi semua situasi yang mungkin terjadi dan tahapan implementasinya (login anonim, "ingat saya", "lupakan saya", beralih menggunakan kunci permanen, otorisasi dan keluar, registrasi dan otentikasi dua faktor, ekspor / impor kunci, penggantian kunci, dll.)

Contoh konfigurasi akses token berdasarkan file .htaccess.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory> 

 cat /etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user 

2.7.1 Algoritma untuk menghitung token pengguna situs yang mungkin menggunakan kunci yang dikenal

Jika kita tahu kunci domain K, kita dapat dengan mudah menghitung token T yang “valid” dari pengguna yang akan datang dengan permintaannya. Untuk ini, diperlukan bahwa kondisi terpenuhi: pemrakarsa permintaan, penerima permintaan, dan konteks eksekusi harus cocok dan sama dengan domain. Dengan kata lain, jika kita memiliki nama domain vsphere.local, maka:

 Sender = Recipient = Context = vsphere.local 

Dari sini, token (mentah) asli dihitung sebagai:

$$

Setelah pengiriman, token asli akan lebih dilindungi. 128 bit yang lebih rendah dari token akan di-hash dengan garam yang dilewatkan di header permintaan CSI-Salt ^* . Dengan demikian, situs akan melihat token berikut:

$$

Di mana Hi adalah 128 bit tinggi, Lo adalah 128 bit rendah dari token asli.
Biasanya, untuk konsol manajemen tertutup pada jaringan perusahaan, konsol web tidak memuat skrip eksternal, bingkai, dll. Oleh karena itu, kondisi ini akan dipenuhi dalam banyak kasus.

---

^{* Untuk metode pembentukan garam, lihat bagian “Prosedur pertukaran garam antara browser dan server”.}

2.8 Memproses token di server

Mengirim token ke server (tanpa kunci)

Permanent

Browser mengunci kunci klien. Pengguna ingin situs mengingat pelanggan selama lebih dari satu sesi. Apakah akan menyimpan token pengguna dalam databasenya adalah keputusan server. Kami mengembalikan CSI-Token-Action: sukses atau CSI-Token-Action: batalkan ke klien.

Mengirim token dengan kunci Logout

Menunjukkan bahwa token saat ini tidak akan lagi digunakan oleh browser. Itu dikirim ketika pengguna mengklik "Keluar" di browser, atau menutup tab dan opsi ini dikonfigurasi (keluar otomatis saat menutup tab), atau menolak untuk menggunakan kunci tetap ("lupakan saya di situs ini").

Omong-omong, Autologin seharusnya tidak. Demi alasan keamanan.

Mengirim token dengan tombol Ubah-Ke

Mari kita sebut token T lama, yang baru - T '.

PENTING: sebagai token baru T ', nilai sebenarnya token dikirim (untuk pertama kali, untuk yang tidak terdaftar), sedangkan token lama dikirim hash (lebih rendah 128 bit).

---

^{* , .}

2.9 -

Seperti yang disebutkan sebelumnya, situs dapat berinteraksi dengan situs mitra lain atau sub-domain mereka untuk menyediakan pengguna dengan beberapa fungsi. Contoh paling umum adalah ketika di situs site.ru beberapa sumber daya diambil dari subdomain img.site.ru, bagian dari download.site.ru, dan bagian lain dari yang lain.

Dalam hal ini, situs site.ru harus dapat memberi tahu domain mitranya tentang siapa sebenarnya permintaan yang datang kepada mereka. Memang, jika Anda diotorisasi di site.ru, ini tidak secara otomatis membuat Anda diotorisasi di situs lain, termasuk sub-domain situs. Mereka akan melihat token lain dari Anda.

Mari kita lihat bagaimana token dihitung dan bagaimana ini bisa membantu kita.
Biarkan pengguna masuk ke site.ru dengan kunci permanen dan berikan token di sana:

$$

Semua permintaan datang dari halaman situs site.ru ke domain site.ru dan disebabkan oleh:

• tag sumber daya halaman (statis atau dinamis asli)
• skrip sendiri

akan memiliki token T ₁ (lihat aturan R1 , R4 , RB ). Ini adalah permintaan yang sah untuk site.ru.

Sekarang biarkan klien mengunduh file yang dibatasi dari halaman site.ru, tetapi tautannya mengarah ke download.site.ru. Dalam hal ini, subdomain akan menerima token berikut (aturan R1 , R4 ):

$$

Token download.site.ru yang sama persis akan menerima jika permintaan ajax dari halaman situs site.ru dieksekusi di atasnya ( RB , aturan RC ).

Domain domain lain akan menerima token:

$$

Tetapi, perhatikan bahwa jika kondisi untuk memenuhi permintaan tidak berubah, maka untuk bundel domain A, B, C yang diberikan, browser akan selalu menghasilkan token konstan. Jadi kita bisa melakukan identifikasi lintas domain. Contohnya seperti itu.

Dari site.ru kami membuat permintaan ajax untuk subdomain. Kami melewati ID pengidentifikasi! = T _{1 dari} pengguna, yang dikeluarkan kepadanya oleh site.ru. Subdomain untuk mendapatkan user ID ini sama token T _x . Setiap subdomain akan membuat banyak tokennya dengan ID pengguna. Subdomain akan berbagi informasi tentang ID pengguna dan hak-haknya dengan permintaan server-ke-server.

Banyak yang dilakukan sekali. Selanjutnya, subdomain akan dipandu oleh token mereka sendiri, seperti mereka juga akan permanen untuk kunci permanen site.ru.

3 Rekomendasi Keselamatan

3.1 Perlindungan informasi utama dari akses tidak sah

Protokol otorisasi yang diusulkan melindungi pengguna dari keyloggers yang mencuri kata sandi Anda, karena skema yang diusulkan sama sekali tidak menggunakan kata sandi.

Tetapi cara untuk melindungi kunci dari kompromi harus dipertimbangkan secara lebih rinci.

Kunci dapat dikompromikan oleh:

• menyalin informasi kunci oleh malware (akses jarak jauh)
• akses langsung ke file dengan informasi utama "offline" (akses langsung)
• pada saat distribusi antar perangkat

Dengan asumsi bahwa informasi utama disimpan pada kartu pintar (kami mempertimbangkan opsi ini di bagian "Mobilitas Akun" ), tugas melindungi informasi utama ditransfer ke chip. Benar, ada kerentanan terhadap keylogger yang dapat mencegat kode PIN yang dimasukkan; Yah, ketidaknyamanan untuk digunakan.

Selain kartu pintar, enkripsi simetris dapat digunakan untuk melindungi terhadap akses langsung ke informasi utama. Tetapi pertanyaannya adalah: kunci apa yang harus diambil untuk enkripsi?

Jika kunci ini dibuat berdasarkan kata sandi pengguna, maka, pertama, kami mendapatkan kerentanan terhadap pemilihan kata sandi "offline", dan kedua, pada kenyataannya, dari apa yang mereka tinggalkan, mereka sampai pada itu: "lagi beberapa kata sandi".

Pilihan yang lebih tepat adalah menjahit dengan cara khusus ^*kunci semacam itu ke rakitan browser (atau salah satu perpustakaan khususnya). Setiap pembaruan browser mengubah kunci dan lokasinya di file yang dikompilasi. Pendekatan ini tidak akan memberikan jaminan perlindungan 100%, tetapi akan sangat mempersulit tugas dekripsi. Pertama, penyerang perlu mencari tahu versi perakitan yang tepat, kemudian menemukannya, membongkar, dan mencari tahu bagaimana kuncinya dirakit.

Selain itu, kunci domain itu sendiri harus langsung disimpan dalam file terpisah, dan tidak bersama dengan konfigurasi untuk penggunaannya (mis. Hanya kunci dan tidak lebih). Maka dekripsi mereka dengan pemilihan tombol (dari rakitan yang diketahui) tidak akan mungkin, karena tidak mungkin untuk membedakan kunci yang didekripsi dengan benar dari urutan byte acak. Kemudian mencoba mengambil kunci master tanpa mengetahui versi yang tepat dari rakitan browser dan secara langsung membongkar kodenya akan menjadi mustahil sama sekali.

Anda dapat menggunakan opsi gabungan: enkripsi dengan kunci dari browser + enkripsi dengan kata sandi pengguna dari akun OS (jika OS API memungkinkan). Apalagi kuncinya selalu dihasilkan dengan cepat. Maka brute force offline akan menjadi lebih mahal.

Selain itu, setelah mengubah kata sandi pengguna di OS, kuncinya juga akan berubah. Dan jika Anda tidak melakukan pra-dekripsi pada kunci lama, maka ini akan melindungi terhadap situasi ketika administrator komputer mengubah kata sandi Anda untuk mengakses akun Anda dan melakukan tindakan atas nama Anda. Jenis situasi: berhenti dari pekerjaannya.

Pertama-tama Anda akan membuat salinan cadangan kunci (ekspor kunci ke file). Kecuali, tentu saja, Anda sudah melakukan ini sebelumnya ketika mendistribusikan kunci ke perangkat lain.

---

^{* Sebagai contoh, kunci 32 byte didistribusikan secara acak di bagian 64K dari file yang dapat dieksekusi. Dan hanya kode sumber yang tahu cara mengumpulkan kunci berharga dari byte ini.}

3.2 Tentang kata sandi sebagai kunci domain

Di salah satu versi awal protokol, kunci domain dapat dibuat berdasarkan kata sandi pengguna. Algoritma itu rumit, tidak termasuk kunci duplikat untuk domain yang berbeda untuk kata sandi yang sama.

Ini diposisikan sebagai cara yang nyaman untuk akun mobilitas. Masukkan satu kata sandi dan jangan khawatir tentang apa pun. Tapi kemudian ternyata yang berikut:

1. , «» , , . , -, .
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . Yaitu ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   , .
2. , .
3. , . Yaitu ( SHA-2).
4. , , , . .

3.3 /

Bagaimana jika saya kehilangan kunci master?

Ini dapat terjadi jika Anda mengubah kata sandi atau menginstal ulang OS. Apa risikonya?

Yah, Anda tidak akan sampai ke situs di mana Anda sebelumnya. Kehilangan riwayat belanja Anda di toko online, iklan di situs online, karma di forum. Itu tidak masalah.

Meskipun, siapa yang mencegah untuk melakukan prosedur registrasi ulang dengan token baru dan mengkonfirmasinya melalui nomor telepon yang ditunjukkan dalam pengumuman yang sama? Ternyata situs tersebut perlu melakukan pendaftaran ulang token (analog "pemulihan kata sandi")? Di mana tidak adanya bentuk "segala macam" yang dijanjikan?

Bahkan, sebuah situs yang perlu tidak hanya mengidentifikasi pengunjung, tetapi juga tahu siapa itu sebenarnya, harusmembuat formulir pendaftaran. Sebenarnya, formulir ini dapat digunakan untuk registrasi ulang. Anda menentukan data yang sama persis seperti sebelumnya (email, seluler). Konfirmasikan bahwa Anda memiliki data ini (surat, SMS). Sistem melihat bahwa akun semacam itu sudah ada, datanya 100% milik Anda, tetapi tokennya berbeda - ia menulis ulang token.

Tapi tetap saja, lebih baik tidak kehilangan kunci master.

Bagaimana cara mencegah kerugian? Buat salinan cadangan, lindungi dengan kata sandi dan simpan di media sekali pakai. Juga, sebenarnya, seperti yang dilakukan dengan kunci untuk bitcoin. Pada prinsipnya, Anda dapat menerjemahkan kunci utama ke dalam bentuk cetakan dan menyimpannya di selembar kertas. Untuk itu. Dan kemudian kembalikan dengan input manual. Tapi ini untuk orang yang cukup "paranoid" seperti saya.

Tetapi bagaimana jika kunci master dicuri dari saya?
Ini sudah serius. Meskipun rekomendasi yang dijelaskan di sini untuk menyimpan kunci master (tidak termasuk dalam protokol) melindungi mereka dari gangguan langsung, keylogger dan trojan, namun, risiko kompromi kunci master tetap ada. Sayangnya, perlindungan sempurna tidak ada. Kuncinya dapat dibajak langsung dari memori browser melalui kerentanan mesin javascript. Sebagai contoh. Atau apakah Anda kehilangan ponsel Anda ...

Jadi apa risiko mencuri kunci utama?

Penting untuk menerima informasi tentang Anda dan bahkan untuk mengambil tindakan atas nama Anda. Memperoleh kemampuan bagi penyerang untuk masuk di bawah Anda dan dalam mode baca untuk mendapatkan akses ke informasi sensitif. Tenang dan tenang.Atau unduh semua video pribadi Anda dari teman sekelas sekaligus. Tidak menyenangkan bagi Anda. Penggemar anjing laut bersukacita.

Di sini Anda perlu mendaftar ulang dengan cepat dengan kunci baru di situs-situs penting. Dan, jika sesuatu yang buruk terjadi, mendaftarkan token baru Anda di basis data penyedia layanan dengan cara resmi adalah satu-satunya pilihan yang tepat. Anda dapat memikirkan banyak metode pendaftaran: dari pemasangan kertas dalam surat resmi, hingga aplikasi melalui layanan dukungan teknis situs dengan konfirmasi identitas Anda dengan cara yang dapat diterima. Tapi ini hanya untuk situs serius, seperti perbankan online.

Cara meminimalkan risiko. Penggunaan kunci individual untuk domain (tetapi ini mengurangi mobilitas akun). Otentikasi dua faktor melalui saluran independen. Situs ini menunjukkan alamat IP dan perangkat di mana koneksi berasal dari terakhir kali, sehingga Anda setidaknya melihat kompromi.

4 Serangan pada skema otorisasi

4.1 Pelacakan Pengguna

Situs yang Anda percayai dapat menggabungkan informasi tentang Anda dengan situs lain tanpa malu-malu. Di Internet ada situs pengumpul yang mengumpulkan informasi tersebut dan menjualnya kepada semua orang. Metrik Yandex, analitik google - situs langka tidak memilikinya.

Agar dua situs berbeda dapat menentukan bahwa mereka bekerja dengan klien yang sama, dua teknik digunakan:

1. ( , ).
2. ( ) .

Ada sedikit kelemahan dalam Skema 2: bukan pengguna yang diidentifikasi , melainkan browser. Namun seringkali browser == client.

Tampaknya token paling cocok untuk digunakan dalam skema No. 2. Lagipula, jika pengguna mengizinkan dua situs (bertindak sebagai pasangan) untuk "mengingat" diri mereka sendiri, token permanen kami dapat bertindak seperti "sidik jari", bukan hanya browser, tetapi pengguna. Masalah untuk situs di sini adalah mereka akan menerima token yang berbeda .

Tetapi situs juga dapat mencoba menerapkan skema No. 1. Kemudian hal berikut akan muncul.

Situs 1 akan menerima kode H ₁ dari browser , dan situs 2, dieksekusi dalam konteks situs 1, akan menerima kode H ₂ . Tampaknya sekarang situs dapat membentuk pasangan (H ₁ , H₂ ) -.
3, 2, . 3 H ₃ , 2, 3 – H _2' != H ₂ (. ). , , .. .

, fingerprint . , .

: , . .

4.2 serangan XSS

XSS adalah jenis serangan yang melibatkan pengenalan kode berbahaya ke halaman situs web korban.com. Misalnya, melalui skrip afiliasi atau CDN yang diretas dari kerangka kerja populer.

Kode berbahaya dapat menggunakan otorisasi pengguna di situs untuk mendapatkan akses yang diizinkan atau mencuri data otentikasi pengguna. Kode berbahaya dapat dimasukkan ke dalam halaman melalui kerentanan di server web (trivial hacking), melalui jaringan afiliasi (sumber tidak dapat diandalkan), melalui kerentanan pada komputer pengguna (perayapan Trojan).

Perlindungan utama terhadap serangan semacam itu untuk skema otorisasi kami adalah aturan khusus untuk menghasilkan bidang Sumber saat menghitung token.

Kerentanan: untuk XSS yang disimpan (ketika skrip dimasukkan langsung ke situs yang diserang dan diambil darinya sebagai hasil peretasan server), perlindungan tidak akan berfungsi. Karena browser tidak akan dapat mengidentifikasi skrip seperti "eksternal". Masalah yang sama akan terjadi ketika seorang penyerang proksi lalu lintas klien-server.

4.3 Serangan CSRF

Korban mengunjungi situs evil.com, yang dibuat oleh penyerang. Atas namanya, permintaan (GET / POST / HEAD / PUT / DELETE) dieksekusi ke situs di mana pengguna sudah diotorisasi (misalnya, ke server sistem pembayaran). Permintaan itu sendiri melakukan semacam operasi jahat (misalnya, mentransfer uang ke akun penyerang). Menurut pengawasan pengembang, situs tidak memeriksa bidang Perujuk dan tidak meminta informasi verifikasi tambahan dari pengguna. Alhasil, serangan itu berhasil.

Skema otorisasi lokasi yang diusulkan menekan sebagian besar skenario serangan CSRF, karena algoritma pembuatan token. Setiap permintaan lintas situs akan menghasilkan situs yang diserang menerima token yang tidak valid dari pengguna. Akibatnya, dalam situasi ini, pengguna untuk situs yang diserang akan anonim anonim. Bahkan upaya untuk mengeksekusi permintaan GET yang tidak berbahaya dari situs penyerang ke situs yang diserang (mengunggah gambar) akan menghasilkan yang terakhir menerima token yang tidak valid.

Ini harus sangat menyederhanakan kehidupan pengembang situs.

4.4 Pelacakan menggunakan SSO

Dua situs S ₁ dan S ₂ , yang dipercayai pengguna dan memiliki kunci untuknya, memutuskan untuk menerapkan teknologi yang mirip dengan SSO untuk pelacakan pengguna. Tapi sejak itu Anda tidak dapat menyematkan satu situs ke situs lain (salah satu dari mereka akan menerima token yang tidak valid), Anda tidak dapat membuka situs mitra dengan skrip (untuk alasan yang sama), kemudian situs S ₁ memutuskan untuk menggunakan teknik yang rumit.

Pada salah satu halaman ia menempatkan tag A transparan, menutupi seluruh jendela. Tautan mengarah ke situs S ₂ , dan pengidentifikasi pengguna (dari S ₁ ) dan token H ₁ ditransmisikan dalam alamat . Pengguna tidak melihat tautannya. Dengan mengklik pada area mana saja dari situs S ₁ , itu memulai pembukaan tab baru di situs S ₂.

Saat ini, S ₂ tidak akan menerima token yang valid. Reload otomatis dengan tag juga tidak akan membantunya

 <meta http-equiv="refresh" content="0"> 

atau skrip.

Tapi S ₂ dapat membuat tag A di seluruh halamannya dalam bentuk tombol Tutup palsu:

Tautan ini pertama-tama akan memuat ulang situs, lalu menutupnya. Pada saat reboot, browser akan mengirimkan token H _{2 yang} sudah valid ke situs S ₂ (karena aturan 2.4 P1 telah diikuti: pengguna secara pribadi membuka kedua tautan). Akibatnya, S ₂ akan menerima informasi tentang tindakan penggunanya di situs S ₁ , mengaitkan token H ₁ dengan H _2-nya , dan mengirimkan H ₂ permintaan interserver ke S ₁ . Di masa depan, situs S ₁ dan S ₂ akan dapat bertukar informasi tentang pengguna dengan pertukaran server, seperti sekarang mereka dapat secara unik mengidentifikasi satu sama lain secara terpisah satu sama lain

.

Pengguna ponsel sangat rentan terhadap serangan ini, karena mencoba menutup halaman yang tidak perlu bisa secara tidak sengaja mengklik tautan palsu yang menempati seluruh layar ponsel.

Metode perlindungan: secara otomatis memutuskan sesi ketika tab ditutup. Kemudian situs S ₂ tidak dapat menerima token yang valid sampai pengguna sendiri login ke sana. Benar, ini tidak akan melindungi terhadap situasi ketika pengguna membuka tab dan masuk ke S ₁ dan S ₂ . Dan baru kemudian situs melakukan serangan seperti itu.

4.5 Kompromi Kunci untuk SSO

Biarkan akun pengguna di server otentikasi yang mendukung SSO dikompromikan. Kami akan mengevaluasi kemungkinan risiko dengan skema otentikasi kami.

Token untuk setiap situs dihitung secara individual berdasarkan kunci domain.

Mengompromikan satu kunci domain tidak secara otomatis membahayakan semua yang lain.

Sebagian besar situs di mana Anda sebelumnya masuk menggunakan SSO mungkin akan menyimpan token Anda dengan profil Anda dari server SSO di database mereka. Dalam skema kami, situs hanya akan menarik token dari database dan mengenali Anda. YaituServer SSO tidak lagi diperlukan di situs tersebut - ia menjalankan fungsinya pada tahap pendaftaran.

Dengan kata lain, Anda tidak secara otomatis kehilangan semua akses Anda sekaligus. Seorang penyerang akan diidentifikasi di situs yang sama dengan orang lain.

Upaya untuk melakukan kembali otentikasi lintas-domain tidak akan membantu penyerang juga: situs harus memblokir upaya untuk membuat akun baru dengan SSO Id-user lama dan token situs baru. Atau, upaya untuk menulis ulang token pengguna untuk ID yang ada dalam proses SSO harus diblokir. Fakta ini, harus menimbulkan kecurigaan yang wajar di sisi situs.
Token pengguna dapat diubah secara legal hanya dalam satu cara (lihat. “Skenario operasi protokol” ).

Resiko.Jika situs tidak menyimpan token dan profil Anda dalam basis datanya, tetapi sepenuhnya bergantung pada mekanisme SSO, maka penyerang hanya perlu melakukan otentikasi lintas-domain untuk masuk menggunakan nama Anda.

Meminimalkan risiko jika terjadi kompromi. Anehnya, tapi ini adalah pelestarian oleh situs token dan profil pengguna di pihak mereka. Upaya penyerang untuk melakukan otentikasi lintas-domain dapat menyebabkan konflik antara pengguna lama dan token barunya. Situasi itu sendiri, ketika pengguna telah mengubah token dengan cara apa pun selain yang ditentukan dalam protokol, harus dianggap mencurigakan atau ditolak sama sekali.

Risiko maksimum:otorisasi atas nama Anda di situs lain (di mana Anda belum pernah). Akses ke data profil Anda. Melakukan tindakan melanggar hukum atas nama Anda. Dan agar pemilik yang sah tidak dapat mengembalikan apa pun, penyerang dapat mengubah tokennya di server otorisasi dengan cara yang legal. Risiko ini, bagaimanapun, bertepatan dengan risiko saat menggunakan skema otorisasi tradisional.

Cara perlindungan. Penolakan untuk menggunakan SSO (terutama karena skema yang diusulkan disusun sebagai cara untuk menjauh dari skema otentikasi terpusat). Gunakan beberapa SSO (jangan menyimpan semua telur dalam satu keranjang!).

Jika SSO mendukung otentikasi dua faktor dengan otentikasi oleh atribut lain (mail, telepon), maka ada kemungkinan mendapatkan kembali kendali atas akun server otorisasi.

4.6 Token kompromi selama transfer

Jelas bahwa mekanisme yang diusulkan untuk hashing token selama transfer tidak memberikan jaminan 100% untuk perlindungan mereka. Seorang penyerang dapat mencegat lalu lintas korban pada saat transfer token yang tidak aman (pada saat pendaftaran utama kunci permanen), sebagai contoh. Dan kemudian menggunakannya.

Oleh karena itu, penggunaan SSL dianjurkan. Tapi jangan menggunakan HTTPS sebagai obat mujarab. Protokol ini juga terbuka, serta HTTP. Hanya sedikit lebih sulit.

Benar, transfer token terbuka yang jarang terjadi, serta penggunaan token individu untuk setiap domain, mengurangi risiko mengeksploitasi kerentanan. Meskipun demikian.

Bahaya lain adalah intersepsi dan penggunaan kembali token di sesi pengguna saat ini. Seperti yang saya katakan sebelumnya, idealnya, token harus diiris dengan garam baru di setiap permintaan klien. Namun, ini akan mematikan kemungkinan pemrosesan paralel permintaan di server dan membuatnya tidak mungkin untuk mengirim permintaan paralel dari klien. Menghitung dan memeriksa hash pada umumnya merupakan operasi mahal yang mengurangi kinerja.

Selain itu, token yang diteruskan di header tidak boleh tersedia dari Javascript. Mirip dengan Cookie dengan bendera HttpOnly. Bahkan ketika menerima permintaan ajax oleh skrip.

Metode operasi: memotong permintaan pengguna, mengekstraksi nilai token saat ini, mengirim operasi lain dengan token yang sama (seperti atas nama pengguna yang sama). Benar, sistem klasik berdasarkan cookie sesi juga rentan terhadap jenis serangan ini.

Metode perlindungan: konfirmasi operasi signifikan melalui saluran komunikasi lain, misalnya, melalui SMS atau surat; pra-registrasi token melalui saluran komunikasi lain (sertifikat kertas, sebagai contoh).

4.7 Meretas situs web dan token yang membahayakan

Situs peretasan terjadi terus-menerus. Bahkan situs besar dan terlindungi pun rusak. Ada banyak cara peretasan: dari suntikan sepele ke "tiriskan" orang dalam. Karenanya, kompromi token Anda di situs mana pun adalah peristiwa yang sangat mungkin terjadi.

Tetapi protokol yang diusulkan, sama saja, membuat acara peretasan situs menjadi hal yang paling tidak menyakitkan bagi Anda.

Kompromi token tidak mengarah pada kompromi kunci domain atas dasar yang dihitung. Selain itu, acara ini tidak mengarah pada kompromi token Anda yang lain . Dan jika demikian, maka akses ke situs lain tetap tidak dapat diakses.

Ini sangat menyenangkan ketika kunci dibuat untuk sebagian besar situs menggunakan kunci master: tidak mungkin untuk mengembalikannya dengan rekayasa terbalik.

Tetapi pada saat yang sama, tidak mungkin untuk menggunakan kunci domain yang tokennya dikompromikan, karena alasan yang jelas. Harus ganti kunci.

Kunci untuk domain tempat kebocoran resmi terjadi dapat dilakukan berdasarkan nomor acak atau berdasarkan kunci master, dengan penambahan nomor versi:

$$

Kesimpulan

Beberapa teman saya yang saya tunjukkan artikel pada dasarnya bertanya kepada saya pertanyaan yang sama: "Apa hal utama di sini?"


Oh, tidak ada chip utama! SayangTetapi ada sejumlah detail yang membuat protokol lebih menguntungkan daripada skema login / kata sandi tradisional.

1. Anda mungkin memperhatikan popup yang mengganggu ini di banyak situs.

“Situs kami menyimpan cookie! Kenakan helmmu dan waspada, karena kakak laki-laki itu memperhatikanmu! Klik "Ya", karena Anda masih tidak punya pilihan. "

Ini adalah popup lain untuk sekelompok yang sama-sama mengganggu dan sangat diperlukan. Dan semua ini berkat GDPR Eropa (analog dari hukum PD kami).

Jadi disini. Dalam skema kami, cookie tidak lagi diperlukan untuk tujuan identifikasi! Dari kata "sepenuhnya." Pengguna memutuskan apakah akan mengizinkan situs untuk mengidentifikasi itu, dan kapan dan berapa lama. Minus satu popup yang mengganggu, +1 ke protokol karma.

2. Pengembang tidak perlu lagi melakukan otorisasi dan formulir pemulihan kata sandi. Tidak perlu menerapkan algoritme SSO kompleks dan menguasai pustaka kompleks: OAuth, SAML, Kerberos, dll., Ikuti prosedur pendaftaran situs Anda, ubah kunci otorisasi, pantau keamanannya; dan jika ada yang salah dengan SSO, segera pahami: "apa yang salah, dan mengapa." Selain itu, server otorisasi dapat memblokir situs Anda karena alasan yang tidak diketahui. Cari tahu itu. Kemarin semuanya bekerja, tetapi hari ini ... Dan ini cukup untuk membaca token dari header dan memeriksa untuk melihat apakah ada satu di database kami. Sederhana = andal .



3. Pengguna tidak perlu memasukkan dan mengingat banyak kata sandi. Gunakan layanan situs pihak ketiga atau tidak diketahui oleh siapa dan bagaimana program tertulis. Anda tidak perlu takut akses ke komputer oleh pihak ketiga, keyloggers dan trojan. Cukup membuat salinan cadangan dari kunci master, melindunginya dengan kata sandi dan menyimpannya di suatu tempat di USB flash drive. Seperti dompet bitcoin. Apa yang bukan fitur?

4. Jika situs diretas, Anda tidak mengambil risiko apa pun. Nah, buat ulang kuncinya lagi. Sementara kata sandi bocor ke cracker situs dapat menyebabkan banyak masalah.

5. Protokol dibuat dengan mempertimbangkan pengalaman serangan jaringan yang diketahui. Arsitekturnya sudah termasuk perlindungan dasar terhadap XSS, CSRF. Sekali lagi, webmaster akan merasa lebih mudah untuk mengembangkan situs. Dan penggunanya - lebih tenang.

6. Independensi protokol dari penyedia layanan tertentu dan keinginannya. Protokol membuat Anda bebas.

7. Akhirnya, protokol yang diusulkan mengklaim standar terbuka masa depan . Dan standar, jika diadopsi oleh peserta, membebankan kewajiban untuk mengimplementasikan fungsi sesuai dengan spesifikasi , dan tidak untuk pagar pertanian kolektif dari keputusan otorisasi sendiri, sekali lagi menciptakan bentuk login, pendaftaran, pemulihan kata sandi, logout. Dan jangan main-main dengan hashing kata sandi atau injeksi SQL.

Dan yang paling penting, seperti standar terbuka, itu dapat dan harus diverifikasiahli independen. Sekalipun pembuat protokol versi asli "mengacaukan" secara terperinci, komunitas online dapat mengidentifikasi perbaikan ini tepat waktu. Nah, atau kirim protokol saya ke memo. Sial bagi saya, dan "dibawa-bawa" untuk semua orang.

- Saya pikir saya harus berhenti pada
E. Wiles ini

---

PS
Anda dapat membiasakan diri dengan pilihan artikel panjang penuh dalam format offline. Saat mengetik huruf di Habr, saya bisa membuat kesalahan ketik. Jika Anda memiliki komentar serius, lebih baik untuk memeriksa yang asli dan meninggalkan komentar artikel (ulasan) dalam file ini . Kirimkan perubahan Anda kepada saya ke mail sergey201991 [] gmail. Saya bukan gurita, tetapi saya akan mencoba menjawab. Saya akan menambahkan beberapa komentar yang cocok / menarik ke artikel ini. Bersama dengan jawaban mereka. Varian dari artikel komentar terpisah tidak dikesampingkan.

Ya, saya tahu bahwa protokolnya mungkin mengalami masalah:

1. tidak ada cara untuk masuk di bawah akun Anda di perangkat orang lain jika Anda tidak memiliki kunci, tetapi Anda sangat membutuhkannya; kata sandi lebih nyaman di sini
2. ; , SSO
3. «», - : - ( )
4. -

Mengenai hal. 1 - Saya benar-benar berpikir untuk kembali ke ide membuat kunci domain berdasarkan kata sandi, membuat perlindungan terhadap kekerasan dengan mempersulit proses pembuatan kunci: katakanlah, meningkatkan jumlah putaran hash menjadi 1000. Tetapi masalah dengan kemungkinan benturan kata sandi untuk pengguna yang berbeda pada satu Situs itu menghantuiku.

Mengenai hal. 2 - ini diperlakukan berdasarkan waktu. Anda harus terbiasa dengan antarmuka baru. Pada awalnya itu tidak akan jelas, maka itu akan menjadi sederhana. Memberi seorang pria tahun 80-an sebuah smartphone modern, ia juga tidak akan bisa menebak bagaimana cara mengelolanya.

Terima kasih banyak jika Anda membacanya sampai akhir!