Pertanyaan ini telah ditanggapi, dalam bentuk yang sedikit berbeda, panjangnya, di sini:
Otentikasi tenang
Tapi ini mengatasinya dari sisi server. Mari kita lihat ini dari sisi klien. Namun, sebelum kita melakukan itu, ada pembuka penting:
Javascript Crypto Tidak Ada Harapan
Artikel Matasano tentang ini terkenal, tetapi pelajaran yang terkandung di dalamnya cukup penting:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
Untuk meringkas:
- Serangan man-in-the-middle dengan mudah dapat mengganti kode crypto Anda
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- Serangan man-in-the-middle sepele terhadap halaman yang melayani sumber daya apa pun melalui koneksi non-SSL.
- Setelah Anda memiliki SSL, Anda menggunakan crypto nyata.
Dan untuk menambahkan akibat wajar saya sendiri:
- Serangan XSS yang berhasil dapat mengakibatkan penyerang mengeksekusi kode pada browser klien Anda, bahkan jika Anda menggunakan SSL - jadi bahkan jika Anda memiliki setiap lubang palka, browser Anda crypto masih bisa gagal jika penyerang Anda menemukan cara untuk mengeksekusi kode javascript di browser orang lain.
Ini membuat banyak skema otentikasi TENANG mustahil atau konyol jika Anda berniat untuk menggunakan klien JavaScript. Mari lihat!
HTTP Basic Auth
Pertama dan terpenting, HTTP Basic Auth. Skema yang paling sederhana: cukup berikan nama dan kata sandi dengan setiap permintaan.
Ini, tentu saja, benar-benar memerlukan SSL, karena Anda memberikan nama dan kata sandi yang disandikan Base64 (reversibel) dengan setiap permintaan. Siapa pun yang mendengarkan di saluran dapat mengekstraksi nama pengguna dan kata sandi sepele. Sebagian besar argumen "Basic Auth is insecure" berasal dari tempat "Basic Auth over HTTP" yang merupakan ide buruk.
Peramban menyediakan dukungan HTTP Basic Auth yang dipanggang, tetapi itu jelek dan Anda seharusnya tidak menggunakannya untuk aplikasi Anda. Namun alternatifnya adalah menyembunyikan nama pengguna dan kata sandi dalam JavaScript.
Ini adalah solusi yang paling tenang. Server tidak memerlukan pengetahuan tentang keadaan apa pun dan mengotentikasi setiap interaksi individu dengan pengguna. Beberapa penggemar REST (kebanyakan strawmen) bersikeras bahwa mempertahankan segala bentuk negara adalah bid'ah dan akan berbusa di mulut jika Anda memikirkan metode otentikasi lainnya. Ada manfaat teoretis untuk kepatuhan standar seperti ini - didukung oleh Apache di luar kotak - Anda dapat menyimpan objek Anda sebagai file dalam folder yang dilindungi oleh file .htaccess jika hati Anda menginginkannya!
The masalah ? Anda caching di sisi klien nama pengguna dan kata sandi. Hal ini memberikan celah yang lebih baik bagi evil.ru - bahkan kerentanan XSS yang paling dasar dapat mengakibatkan klien mengirimkan nama pengguna dan kata sandi ke server jahat. Anda dapat mencoba mengurangi risiko ini dengan hashing dan salting password, tetapi ingat: JavaScript Crypto is Hopeless . Anda dapat mengurangi risiko ini dengan menyerahkannya ke dukungan Auth Basic Browser, tetapi .. jelek seperti dosa, seperti yang disebutkan sebelumnya.
HTTP Digest Auth
Apakah otentikasi Digest dapat dilakukan dengan jQuery?
Auth yang lebih "aman", ini adalah tantangan hash permintaan / respons. Kecuali JavaScript, Crypto tidak memiliki harapan , sehingga hanya berfungsi di atas SSL dan Anda masih harus men-cache nama pengguna dan kata sandi di sisi klien, membuatnya lebih rumit daripada HTTP Auth Dasar tapi tidak lebih aman .
Otentikasi kueri dengan Parameter Tanda Tangan Tambahan.
Auth lain yang lebih "aman", di mana Anda mengenkripsi parameter Anda dengan data nonce dan timing (untuk melindungi terhadap serangan repeat dan timing) dan mengirimkan. Salah satu contoh terbaik dari hal ini adalah protokol OAuth 1.0, yang sejauh yang saya tahu, merupakan cara yang sangat sulit untuk mengimplementasikan otentikasi pada server REST.
http://tools.ietf.org/html/rfc5849
Oh, tapi tidak ada klien OAuth 1.0 untuk JavaScript. Mengapa?
JavaScript Crypto Tidak Ada Harapan , ingat. JavaScript tidak dapat berpartisipasi dalam OAuth 1.0 tanpa SSL, dan Anda masih harus menyimpan nama pengguna dan kata sandi klien secara lokal - yang menempatkan ini dalam kategori yang sama dengan Digest Auth - ini lebih rumit daripada HTTP Basic Auth tetapi tidak lebih aman .
Token
Pengguna mengirimkan nama pengguna dan kata sandi, dan sebagai gantinya mendapat token yang dapat digunakan untuk mengotentikasi permintaan.
Ini sedikit lebih aman daripada HTTP Basic Auth, karena begitu transaksi nama pengguna / kata sandi selesai, Anda dapat membuang data sensitif. Ini juga kurang tenang, karena token merupakan "negara" dan membuat implementasi server lebih rumit.
SSL Masih
Namun, masalahnya, Anda masih harus mengirim nama pengguna dan kata sandi awal itu untuk mendapatkan token. Informasi sensitif masih menyentuh JavaScript Anda yang dapat dikompromikan.
Untuk melindungi kredensial pengguna Anda, Anda masih harus menjaga penyerang keluar dari JavaScript Anda, dan Anda masih perlu mengirim nama pengguna dan kata sandi melalui kabel. Diperlukan SSL.
Token Kadaluwarsa
Sudah umum untuk menerapkan kebijakan token seperti "hei, ketika token ini sudah terlalu lama, buang dan buat pengguna mengautentikasi lagi." atau "Saya cukup yakin bahwa satu-satunya alamat IP yang diizinkan menggunakan token ini adalah XXX.XXX.XXX.XXX". Banyak dari kebijakan ini adalah ide yang cukup bagus.
Perapian
Namun, menggunakan token Tanpa SSL masih rentan terhadap serangan yang disebut 'sidejacking': http://codebutler.github.io/firesheep/
Penyerang tidak mendapatkan kredensial pengguna Anda, tetapi mereka masih bisa berpura-pura menjadi pengguna Anda, yang bisa sangat buruk.
tl; dr: Mengirim token yang tidak dienkripsi di atas kawat berarti bahwa penyerang dapat dengan mudah menangkap token itu dan berpura-pura menjadi pengguna Anda. FireSheep adalah program yang membuatnya sangat mudah.
Zona Terpisah, Lebih Aman
Semakin besar aplikasi yang Anda jalankan, semakin sulit untuk memastikan bahwa mereka tidak akan dapat menyuntikkan beberapa kode yang mengubah cara Anda memproses data sensitif. Apakah Anda benar-benar mempercayai CDN Anda? Pengiklan Anda? Basis kode Anda sendiri?
Umum untuk perincian kartu kredit dan kurang umum untuk nama pengguna dan kata sandi - beberapa pelaksana menyimpan 'entri data sensitif' pada halaman terpisah dari aplikasi mereka yang lain, halaman yang dapat dikontrol dan dikunci sebaik mungkin, lebih disukai yang sulit untuk menipu pengguna dengan.
Cookie (artinya Token)
Dimungkinkan (dan umum) untuk memasukkan token otentikasi ke dalam cookie. Ini tidak mengubah salah satu properti auth dengan token, itu lebih merupakan hal yang mudah. Semua argumen sebelumnya masih berlaku.
Sesi (masih berarti Token)
Session Auth hanyalah otentikasi Token, tetapi dengan beberapa perbedaan yang membuatnya tampak seperti hal yang sedikit berbeda:
- Pengguna mulai dengan token yang tidak diautentikasi.
- Backend mempertahankan objek 'state' yang terkait dengan token pengguna.
- Token disediakan dalam cookie.
- Lingkungan aplikasi memisahkan detail dari Anda.
Selain itu, sebenarnya tidak ada bedanya dengan Token Auth.
Ini mengembara lebih jauh dari implementasi RESTful - dengan objek negara Anda akan semakin jauh di jalur RPC biasa di server stateful.
OAuth 2.0
OAuth 2.0 melihat masalah "Bagaimana Perangkat Lunak A memberi akses Perangkat Lunak B ke data Pengguna X tanpa Perangkat B memiliki akses ke kredensial login Pengguna X."
Implementasinya sangat sederhana hanya cara standar bagi pengguna untuk mendapatkan token, dan kemudian untuk layanan pihak ketiga untuk pergi "ya, pengguna ini dan kecocokan token ini, dan Anda bisa mendapatkan beberapa data mereka dari kami sekarang."
Namun, pada dasarnya, OAuth 2.0 hanyalah sebuah protokol token. Ini menunjukkan properti yang sama dengan protokol token lainnya - Anda masih membutuhkan SSL untuk melindungi token tersebut - itu hanya mengubah cara token tersebut dihasilkan.
Ada dua cara yang OAuth 2.0 dapat membantu Anda:
- Memberikan Otentikasi / Informasi kepada Orang Lain
- Mendapatkan Otentikasi / Informasi dari Orang Lain
Tapi ketika tiba saatnya, Anda hanya ... menggunakan token.
Kembali ke pertanyaan Anda
Jadi, pertanyaan yang Anda tanyakan adalah "haruskah saya menyimpan token saya di cookie dan manajemen sesi otomatis lingkungan saya mengurus detailnya, atau haruskah saya menyimpan token saya di Javascript dan menangani detail itu sendiri?"
Dan jawabannya adalah: lakukan apa pun yang membuat Anda bahagia .
Masalahnya tentang manajemen sesi otomatis, adalah ada banyak keajaiban terjadi di belakang layar untuk Anda. Seringkali lebih baik untuk mengendalikan detail-detail itu sendiri.
Saya berusia 21 tahun sehingga SSL adalah ya
Jawaban lainnya adalah: Gunakan https untuk semuanya atau perampok akan mencuri kata sandi dan token pengguna Anda.