it-swarm-id.com

Reset kata sandi - praktik apa yang harus diikuti oleh layanan web?

Banyak dari Anda mungkin pernah melihat Bagaimana Apple dan Amazon Security Flaw menyebabkan Hacking Epik Saya , di mana akun Amazon, Apple, Gmail, dan Twitter reporter Wired berhasil diretas Peretas mengikuti serangkaian langkah yang rumit, pada setiap langkah menggunakan proses pemulihan kata sandi di satu layanan web untuk mendapatkan informasi yang diperlukan untuk menyerang akun pelapor pada layanan web berikutnya. Penyerang dapat berhasil mengeksploitasi variasi di antara layanan yang berbeda ' persyaratan untuk apa yang mereka perlukan untuk melakukan reset kata sandi, untuk menghubungkan serangannya dan akhirnya berhasil melancarkan serangan katastropik pada reporter Wired yang malang.

Sehubungan dengan ini, praktik apa yang harus diikuti oleh layanan web, untuk melindungi fungsi pengaturan ulang kata sandi mereka dan mencegah terulangnya kegagalan seperti itu? Apa yang perlu dilakukan industri untuk memastikan ini tidak terjadi lagi?

26
D.W.

Saya sebenarnya telah mengerjakan beberapa ide di sekitar area ini, jadi inilah tumpukan pemikiran saya sejauh ini. Saya minta maaf sebelumnya atas jawaban yang konyol ini.

Mekanisme pengaturan ulang kata sandi harus dirancang dengan tiga tujuan utama:

  • Keamanan
  • Kegunaan
  • Keandalan

Untuk mekanisme yang baik, kita perlu mencapai keseimbangan di antara ketiganya.

Beberapa pernyataan yang ingin saya sampaikan sebelum memulai:

Benar, ke jawaban yang sebenarnya!


1. Otentikasi multi-faktor

Otentikasi multi-faktor (MFA) adalah salah satu metode paling aman untuk pemulihan akun, dan otentikasi manusia secara umum. Bagi Anda yang tidak terbiasa dengan MFA, ini bekerja berdasarkan prinsip bahwa Anda harus memiliki lebih dari satu kredensial untuk mengautentikasi:

  • Sesuatu yang Anda ketahui (mis. Kata sandi, jawaban rahasia)
  • Sesuatu yang Anda miliki (mis. Kunci, token perangkat keras, dll)
  • Sesuatu dirimu (mis. Sidik jari)

Perhatikan bahwa memiliki beberapa jenis, mis. dua kata sandi, atau kata sandi dan pin, tidak tidak dihitung sebagai MFA. Saya melihat Anda, situs perbankan online.

1.1. Sesuatu yang kamu tahu

Saat mengatur ulang kata sandi, cara umum untuk mengautentikasi pengguna adalah dengan menanyakannya beberapa pertanyaan . Sayangnya, pertanyaan-pertanyaan ini biasanya seperti "Sekolah apa yang kamu tuju?" dan "Siapa nama gadis ibumu?", yang sangat mudah bagi penyerang untuk mencari tahu melalui jejaring sosial. Selain itu, banyak pengguna tidak suka menjawab pertanyaan-pertanyaan ini ketika mendaftar, sehingga mereka hanya menekan banyak tombol dan membatalkan tujuan pertanyaan.

Untuk aplikasi web e-commerce, dan aplikasi web lainnya yang menyimpan informasi pribadi pribadi (mis. Alamat/nomor telepon), orang mungkin meminta informasi itu. Namun, perlu diingat bahwa informasi ini juga dapat ditemukan online.

Alternatifnya adalah dengan mengajukan pertanyaan kontekstual, berdasarkan pengalaman pengguna di situs. Misalnya, Hotmail meminta alamat email yang baru saja Anda komunikasikan, serta beberapa informasi lain tentang aktivitas di akun Anda. Ini cukup mudah beradaptasi di sebagian besar jenis aplikasi web, tetapi tidak selalu berlaku.

1.2. Sesuatu yang kamu miliki

Seringkali situs akan mendeskripsikan tautan tautan atau kata sandi satu kali ke alamat email Anda sebagai bentuk MFA. Saya menegaskan bahwa ini adalah asumsi yang salah. Pengguna berbagi kata sandi antar akun. Ini adalah fakta absolut, dan Anda tidak dapat mencegahnya. Dengan demikian, Anda harus berasumsi bahwa penyerang sudah memiliki akses ke alamat email pengguna. Kami akan membahas implikasi dari ini nanti.

Proliferasi ponsel telah menjadikannya mekanisme hebat untuk otentikasi dua faktor, sebagai bentuk pemeriksaan out-of-band. SMS token reset mudah bagi pengguna untuk memahami dan menggunakan, dan penyerang yang memiliki akses ke telepon tidak mungkin. Namun, metode ini bukan tanpa cacat. Masalah terbesar adalah ketika pengguna kehilangan telepon mereka, atau penyedia perubahan. Ini sepenuhnya membatalkan telepon sebagai perangkat reset yang dapat digunakan. Masalah lain adalah bahwa pengguna tidak selalu membawa ponsel mereka.

Menggunakan aplikasi pada telepon pintar sebagian memperbaiki masalah ini. Jika pengguna mengubah penyedia mereka, aplikasi tetap ada di telepon. Mengizinkan pengaturan ulang berbasis SMS dan berbasis aplikasi memungkinkan ekspektasi keandalan yang wajar.

Sebagai alternatif, izinkan pengguna untuk mengaitkan akun penyedia info masuk (mis. OpenID) dan menggunakan masuk yang sah untuk akun itu sebagai bukti "sesuatu yang Anda tahu".

Mekanisme potensial lainnya:

  • Token fisik (mis. RSA SecurID , token USB) - tidak dapat digunakan di sebagian besar tempat, tetapi bermanfaat untuk bank, sistem perusahaan internal, dan situasi keamanan tinggi lainnya.
  • File - File yang dibuat secara acak yang diberikan kepada pengguna saat mendaftar. Hash disimpan dalam basis data. Setelah diatur ulang, pengguna diminta untuk memberikan file. Bukan kegunaan atau keamanan terbaik, tetapi berpotensi bermanfaat.

1.3. Sesuatu dirimu

Di sinilah segalanya menjadi menyenangkan dan sci-fi. Otentikasi biometrik adalah sesuatu yang telah menjadi lebih populer baru-baru ini. Cukup banyak laptop termasuk pemindai sidik jari, dan Anda dapat mengambil yang murah USB dengan biaya yang relatif kecil. Mekanisme biometrik populer lainnya adalah pengenalan wajah, melalui webcam. Keduanya sangat baik dalam hal keamanan ketika dilakukan dengan benar, tetapi mereka berdua memiliki beberapa masalah:

  • Sebagian besar implementasi bersifat probabilistik, dan karenanya tidak aman. Apa yang menghentikan penyerang dari memegang foto wajah Anda ke kamera?
  • Anda tidak dapat mengandalkan setiap pengguna yang memiliki pemindai sidik jari, dan mereka yang melakukannya tidak semuanya kompatibel satu sama lain. Selain itu, Anda berinteraksi dengan perangkat keras, sehingga membutuhkan aplikasi asli untuk berbicara dengan aplikasi web Anda.
  • Bidang biometrik relatif baru, sehingga tidak ada implementasi yang dipelajari dengan baik dengan model keamanan yang sepenuhnya dipahami.

Secara keseluruhan, model "sesuatu Anda" berfungsi untuk identifikasi langsung, tetapi tidak benar-benar layak untuk aplikasi web kecuali Anda memberikan pemindai sidik jari dan perangkat lunak yang sesuai kepada pelanggan Anda.

1.4. Praktik terbaik MFA

Otentikasi faktor tunggal tidak cukup. Seperti yang telah kita lihat dari semuayangbaru-baru inipelanggaran sulit untuk menjaga kata sandi tetap aman, dan bahkan ketika mereka ' Kembali hash mereka masih bisa rusak. MFA diperlukan untuk keduanya login dan pemulihan kata sandi. Otentikasi seluler untuk tujuan pemulihan menyelesaikan sebagian besar masalah, selama perangkat seluler masih dapat digunakan. Jika autentikasi seluler tidak memungkinkan, Anda harus memiliki proses verifikasi manual, di mana mereka harus meyakinkan manusia bahwa mereka adalah yang asli Sepakat.


2. Reset mekanisme

Ada banyak metode pengaturan ulang kata sandi yang berbeda di luar sana, banyak di antaranya tertinggal jauh dalam hal keamanan. Saya akan membahas beberapa yang saya lihat di alam liar, menjelaskan poin baik dan buruknya, dan mengusulkan beberapa yang lebih baik.

2.1. Email kembali kata sandi

Mekanisme yang paling mendasar adalah dengan hanya mengirim email kata sandi pengguna kepada mereka. Tolong jangan pernah melakukan ini . Ini mengerikan tak terkira . Pertama, ini mengharuskan Anda menyimpan kata sandi dalam teks-jelas, atau setidaknya dalam format yang dapat dibalik. Anda harus kata sandi hash dengan benar , dan ikuti praktik terbaik untuk pengasinan . Kedua, Anda mengemail kata sandi pengguna dalam cleartext, melalui protokol cleartext, melalui internet. Ada tingkat neraka khusus yang diperuntukkan bagi orang yang melakukan ini.

2.2. Menghasilkan kata sandi baru

Beberapa situs menghasilkan kata sandi acak baru, memotongnya, lalu mengirimkannya lewat email kepada pengguna. Ini bukan ide yang baik karena beberapa alasan, meskipun sebagian besar dari mereka dapat dikurangi dengan cara tertentu. Masalah yang paling mendasar adalah bahwa Anda mengirim email kata sandi yang dapat digunakan ke pengguna dalam plaintext. Masalah lain dengan metode ini meliputi:

  • Banyak pengguna yang malas, beberapa akan mengatur ulang dan hanya memberitahu browser untuk mengingat kata sandi acak.
  • Banyak situs tidak memaksa Anda untuk mengubah kata sandi saat pertama kali menggunakan kata sandi.
  • Penyerang yang memiliki akses ke akun email memiliki akses ke kata sandi, terlepas dari mekanisme apa yang Anda gunakan untuk mengotentikasi pengguna.

2.3. Tautan reset

Ini adalah salah satu mekanisme yang lebih baik (dan, untungnya, lebih populer). Ini melibatkan mengautentikasi pengguna, lalu mengirimi mereka email sebuah tautan reset satu kali. Setelah tautan reset digunakan, pengguna diminta untuk mengatur kata sandi baru. Setelah selesai, tautan tidak valid. Keamanan lebih lanjut dapat diberikan dengan memasukkan waktu kedaluwarsa pada tautan, dan memastikan bahwa tautan tersebut tidak valid setelah kata sandi diset atau setelah sesi pengguna habis.

Kejatuhan metode ini adalah ketika kita mengingat asumsi awal kita. Akun email pengguna tidak aman. Itu tidak dihitung sebagai "sesuatu yang Anda tahu". Meskipun jendela waktu penyerang pendek, mereka masih bisa menerobos masuk. Tentu saja, semua ini semakin batal jika (atau, lebih tepatnya, kapan) pengguna lupa kata sandi email mereka.

2.4. Jangan pernah meninggalkan situs

Ini adalah grail suci, sungguh, tetapi hanya dapat digunakan bersamaan dengan otentikasi multi-faktor yang kuat. Setelah pengguna mengautentikasi diri mereka sendiri dengan menggunakan kombinasi pertanyaan keamanan, pengecekan out-of-band (mis. Ponsel), file kunci, biometrik, verifikasi manusia, dll. Mereka segera dialihkan ke formulir perubahan kata sandi. Ini sepenuhnya memotong kebutuhan untuk menggunakan alamat email sama sekali.

Jika Anda benar-benar percaya bahwa menggunakan alamat email untuk mengirim tautan diperlukan, pertimbangkan untuk menawarkan opsi setel ulang no-email yang meningkatkan jumlah cek yang harus dilewati.


3. Kesimpulan

Sulit menyeimbangkan keamanan, kegunaan, dan keandalan pada saat terbaik, tetapi situasi ini berhadapan langsung dengan pengguna yang telah sudah membuktikan diri mereka tidak dapat diandalkan. Saya tidak mengatakan ini dengan segala macam alasan, tetapi kita semua bisa salah.

Sangat penting untuk menjaga sistem reset kata sandi dapat digunakan dan sederhana, tanpa berhemat pada keamanan. Sebelum menerapkan proses otentikasi 3-faktor besar-besaran pada setiap aspek aplikasi web Anda, pikirkan tentang apa yang Anda lindungi. Jika Anda hanya sebuah perusahaan kecil yang menjual barang secara online, Anda mungkin bisa lolos dengan 2-faktor dasar pemulihan. Jika Anda pengecer besar, bank, atau situs jejaring sosial, Anda harus menggunakan 2-faktor yang kuat untuk pemulihan (masing-masing beberapa jenis), dan 2-faktor pada login dari sumber yang tidak dikenal.

Dalam sebuah kalimat: sederhanakan, pikirkan tentang audiens Anda.

27
Polynomial

Masalah dengan "peretasan epik" adalah bahwa banyak akun (Twitter, gmail) ditautkan ke satu akun (icloud) yang kemudian dikompromikan, memungkinkan peretas untuk meminta dan mencegat tautan setel ulang kata sandi untuk akun tertaut.

Jika Anda ingin melindungi terhadap skenario seperti itu (di mana akun email yang digunakan sebagai referensi untuk akun lain dikompromikan) karena tidak ada cara lain selain menggunakan otentikasi 2faktor, seperti yang ditawarkan oleh Google . Jika kata sandi sementara yang diperoleh melalui rekayasa sosial akan dikirim ke ponsel pemilik akun icloud, semua ini tidak akan terjadi.

7
twobeers

Menurut pendapat saya, tidak ada lagi yang bisa dilakukan oleh layanan web untuk melindungi fungsi pengaturan ulang kata sandi karena satu alasan sederhana, yaitu pengguna.

Mari kita pertimbangkan apa yang saya temukan sebagai bentuk reset kata sandi yang paling umum: pertanyaan rahasia. Ada 2 skenario yang biasanya dimainkan.

1) Jawab pertanyaan dengan jujur ​​- banyak pengguna memilih rute ini. Sayangnya, jawaban untuk sebagian besar pertanyaan rahasia sangat mudah untuk Digali dari internet. Informasi seperti sekolah pertamamu atau nama gadis ibumu bukan rahasia. Penyerang dapat dengan mudah menggali informasi seperti itu dengan melakukan pencarian online sederhana. Ini membuat pertanyaan rahasia sama baiknya dengan tidak berguna.

2) Jawab pertanyaan dengan sampah, kemudian lupakan jawabannya - kebanyakan orang yang saya kenal melakukan ini, termasuk saya. Ini secara efektif menjadikan pertanyaan rahasia tidak berguna karena tidak dapat digunakan untuk mengkonfirmasi keabsahan permintaan pengaturan ulang kata sandi.

Cara terbaik untuk menangani pertanyaan rahasia adalah dengan menjawab dengan sampah, tetapi tulis di suatu tempat sehingga Anda tidak lupa. Sebagian besar pengguna tidak akan melakukan ini, terutama karena fakta bahwa mereka tidak peduli dengan keamanan sampai terjadi sesuatu.

Apa sajakah cara umum lainnya untuk memicu pengaturan ulang kata sandi?

Email - banyak layanan menautkan akun Anda ke email "pemulihan". Namun, apa yang terjadi jika Anda lupa kata sandi pada email pemulihan? Ini adalah rantai yang tidak pernah berakhir.

Banyak metode yang lebih aman seperti otentikasi dua faktor merupakan masalah bagi pengguna. Layanan web harus mempertimbangkan kegunaan vs keamanan. Lagipula, apa gunanya memiliki layanan web yang tidak dapat dibongkar jika tidak ada yang menggunakannya?

Kelemahan utama dalam artikel itu adalah bahwa penulis memiliki beberapa akun yang ditautkan ke satu email, yang memungkinkan penyerang untuk kompromi semua akun online-nya dengan mudah. Cobalah, sebisa mungkin, untuk mendesentralisasi identitas online Anda. Namun, ini menjadi tanggung jawab pengguna.

Meskipun kami ingin berpikir bahwa keamanan harus menjadi perhatian utama layanan web, kami harus mempertimbangkan sudut pandang kegunaan. Keamanan secara keseluruhan tidak akan membaik sampai pengguna akhir menyadari betapa pentingnya hal itu dan mengambil langkah untuk melindungi diri mereka sendiri. Lagi pula, hanya ada begitu banyak penyedia layanan yang dapat melakukannya.

6
user10211

Dalam praktiknya, mereka menggunakan emailnya untuk meretas segalanya. Jadi menjaga keamanan email Anda, terbaik sendiri, dengan deteksi intrusi cerdas, dan terlindung dari pemulihan kata sandi, akan mencegah peretasan dalam kasus ini.

Hal yang sama berlaku untuk data Anda di cloud. Enkripsi pintar dan perlindungan sistem, seperti manajemen kunci penting bagi Anda untuk tetap aman plus cadangan jarak jauh dan snapshot, jadi sederhananya tidak mungkin untuk daisy chain.

Dokumen dan komunikasi dua kunci ini, harus aman, karenanya tidak cocok untuk cloud untuk penggunaan profesional, karena seseorang akan menghapusnya dan hanya itu. Jadi yang terbaik adalah menggunakan domain bisnis/pribadi, yang dapat Anda pulihkan secara hukum.

Setelah dilindungi secara hukum, fisik, dengan otomatisasi pintar, Anda dapat menggunakannya untuk penggunaan bisnis, dan jika Anda diretas, pada dasarnya harus mengetahui pemulihan kata sandi melalui email, pada dasarnya di webmail Anda, Anda harus memfilter pemulihan kata sandi ke kotak surat lain yang Anda perlu mengakses melalui ssh, agar aman.

Bagaimana dengan apel? Ini terjadi ketika Anda menggunakan perangkat keras untuk anak-anak dengan remote control Apple. Ini adalah solusi yang bagus untuk iPod, tetapi tidak bekerja di dunia PC nyata. Bagaimana semua orang merasa terganggu ketika Microsoft mengumpulkan data, tetapi sekarang Apple memiliki semua aplikasi di bawah kendali dan tidak apa-apa sampai batas tertentu, tetapi terutama untuk kesenangan dan hiburan di rumah, bukan pekerjaan profesional. Lompatan keamanan OSX sangat besar, dan itu tidak mengejutkan sama sekali bahwa OSX diretas dengan cara lintas platform.

Untuk email yang aman, yang terbaik adalah memiliki domain di perusahaan terkemuka, jadi tidak bisa diretas juga.

2
Andrew Smith