it-swarm-id.com

Bagaimana beberapa situs (mis. Bank online) hanya meminta karakter tertentu dari kata sandi tanpa menyimpannya sebagai plaintext?

Saya pikir Bagaimana sistem memberlakukan jumlah minimum dari karakter yang diubah ... akan menjawab pertanyaan saya, tetapi tampaknya ini adalah kasus yang berbeda.

Ketika saya masuk ke akun perbankan online saya, saya diminta untuk tiga digit acak dari PIN empat digit, dan tiga karakter acak dari kata sandi (panjang, acak) saya.

Dari pemahaman saya yang terbatas tentang semua ini, bank tidak dapat membuat hash kata sandi saya dari login ini karena mereka tidak memiliki seluruh kata sandi saya. Jadi apakah mereka menyimpan kata sandi saya dalam teks-jelas dan membandingkan karakter individu? Apakah ini keseimbangan kenyamanan/keamanan yang layak?

Diminta untuk mengajukan pertanyaan ini melalui posting blog ini: Siapa yang peduli dengan keamanan kata sandi? NatWest tidak

66
alexmuller

Sementara saya tidak tahu secara eksplisit bagaimana bank menangani persyaratan ini, proses alternatif dengan yang disebutkan oleh @rakhi adalah dengan menggunakan HSM dan enkripsi yang dapat dibalik.

Idenya adalah bahwa kata sandi lengkap akan disimpan dalam basis data yang dienkripsi menggunakan cipher simetris (misalnya, AES). Kemudian ketika karakter kata sandi diteruskan ke aplikasi mereka dimasukkan ke dalam HSM bersama dengan kata sandi terenkripsi.

HSM kemudian dapat mendekripsi kata sandi dan mengkonfirmasi bahwa 3 karakter seperti yang diharapkan, mengembalikan respons lulus/gagal ke aplikasi. Jadi, tidak ada kata sandi dipegang secara jelas (selain dari dalam HSM yang dianggap aman).

Ini akan cocok dengan cara bahwa PIN enkripsi dapat ditangani oleh jaringan ATM (misalnya, enkripsi simetris dan HSM)

30
Rory McCune

Setiap kali Anda menemukan kasus di mana mengetahui sesuatu tentang kata sandi Anda selain hash dari kata sandi lengkap diperlukan, Anda dapat mengasumsikan bahwa kata sandi tersebut tidak hash. Sementara PCI-DSS disebutkan, tidak ada peraturan yang saya tahu yang berlaku untuk bank yang mengenkripsi atau mem-hashing informasi kata sandi. PCI-DSS tidak mencakup informasi rekening bank Anda, termasuk masuk dengan PIN atau beberapa variasi dari itu.

Jika bagus, kata sandi disimpan menggunakan enkripsi. Jika mereka tidak begitu baik, memang bisa disimpan dalam plaintext.

Saya akui saya lebih suka trade-off di sini. Seluruh basis data kata sandi dapat terkena risiko serangan yang lebih besar jika dikompromikan, tetapi saya akan menangkal bahwa keamanan di bank harus lebih tinggi. Jika ada kompromi dari database yang dicurigai, semuanya harus diubah apakah hash atau dienkripsi pula. Salah satu contoh Dengan metode khusus ini, dibutuhkan banyak waktu lebih lama dan tingkat kerumitan yang lebih besar bagi penyerang untuk mendapatkan informasi yang cukup berguna untuk melakukan serangan dengan keylogger.

Sesuatu yang berhubungan secara tangensial: http://projecteuler.net/index.php?section=problems&id=79

17
Jeff Ferland

Skema NatWest menurut saya nilai yang meragukan. Dalam skema NatWest, serangan phishing mungkin dapat mencuri seluruh Anda PIN dan semua atau sebagian besar kata sandi Anda. Inilah cara kerja serangan phising.

  1. Situs phishing akan menampilkan layar login palsu, meminta 3 digit kata sandi PIN dan 3 karakter kata sandi).

  2. Pengguna akan mengetik jawaban mereka.

  3. Situs phishing sekarang akan menyajikan respons yang menunjukkan bahwa entri itu salah, dan Prompt pengguna lagi.

  4. Banyak pengguna mungkin akan menganggap bahwa mereka memasukkan sesuatu yang salah, dan coba lagi.

Jika phisher pintar, Prompt kedua dari situs phishing akan meminta serangkaian digit dan karakter yang berbeda. Jika pengguna mencoba yang kedua kalinya, maka situs phishing dapat mempelajari semua 4 digit dari PIN dan 6 karakter kata sandi pengguna.) (Perhatikan bahwa NatWest mengharuskan pengguna untuk memilih kata sandi yang mengandung 6- 8 karakter, jadi 6 karakter kata sandi dijamin semuanya atau hampir semuanya.) Pada saat itu, permainan sudah berakhir.

Akibatnya, tidak jelas bagi saya bahwa skema NatWest membeli apa pun untuk Anda.

13
D.W.

Dalam pertanyaan serupa , komentar oleh @captaincomic telah ditautkan ke artikel ini: Sandi Sebagian - Bagaimana? (Dari Archive.org) Ini menjelaskan cara mengizinkan fungsi ini tanpa menyimpan kata sandi dalam bentuk yang dapat dipulihkan atau hashing masing-masing karakter secara terpisah - menggunakan skema berbagi rahasia Shamir.

Ini hanya berhubungan secara tangensial, tetapi David Aspinall (Universitas Edinburgh) dan Mike Just (Universitas Glasgow Caledonian) menerbitkan makalah tentang kata sandi parsial pada tahun 2013: "Beri Aku Surat 2, 3 dan 6!": Implementasi Kata Sandi Sebagian & Serangan .

Makalah mereka melihat serangan online di mana mekanisme penyimpanan backend tidak relevan, tetapi membuat komentar yang sesuai dengan pertanyaan Anda:

Untuk mendukung protokol parsial, implementasinya perlu menyimpan teks biasa untuk kata sandi, atau menyusun mekanisme untuk melakukan pemeriksaan satu arah pada semua kombinasi yang mungkin ditanyakan (yang bisa berupa jumlah besar untuk kata sandi panjang). Kami tidak menyelidiki mode serangan ini di sini.

6
sampablokuper

Tidak, yang mereka lakukan adalah hashing setiap karakter dan menyimpannya atau menyimpan kata sandi dengan jelas di mudah-mudahan perangkat yang aman mis. HSM.

Ini bukan pendekatan yang buruk; bank meminta pengguna memasukkan sejumlah karakter (mis. HSBC adalah 3 dari posisi acak). Itu berarti bahwa jika trojan, pencatat kunci atau situs phishing menangkap 3 karakter tersebut, mereka tidak memiliki kata sandi lengkap.

Hal ini juga memungkinkan bank untuk menggunakan kata sandi parsial untuk mengautentikasi pengguna melalui telepon dll tanpa mengandalkan pertanyaan rahasia atau kata sandi yang berbeda, lagi tanpa orang pusat panggilan mengetahui kata sandi lengkap

Beberapa masalah yang mungkin mengapa tidak banyak digunakan:

  • Yang utama adalah Anda tidak ingin menyimpan kata sandi secara jelas (sebenarnya peraturan seperti PCI-DSS melarangnya). Jadi pendekatannya adalah membuat hash satu arah dari kata sandi dan menyimpannya. Ketika pengguna memasukkan kata sandi, ini hash dan dibandingkan dengan hash yang disimpan, jika cocok dengan pengguna diautentikasi. Dengan kata sandi sebagian, Anda harus menyimpan kata sandi dengan enkripsi yang dapat dibalik yang bukan praktik terbaik atau menyimpan banyak hash, mis. untuk HSBC dengan ulang tahun plus setiap karakter kata sandi membutuhkan hash yang terpisah. Anda juga harus memaksakan panjang kata sandi maksimum sehingga Anda dapat mengalokasikan bidang dalam database untuk menyimpan semua hash (meskipun mungkin ada database yang lebih pintar dan teknologi aplikasi sekarang yang akan mengatasi ini)

  • Ini mendorong pengguna untuk memilih kata sandi yang lemah mis. jika saya memiliki kata sandi kompleks 8 karakter: tpEz% e2S. Mencoba mengingat apa karakter ke 2, 4 dan 5 yang sulit, yang mendorong pengguna untuk memilih kata kamus sederhana.

  • Juga jika tidak ada fitur jenis penguncian akun, secara eksponensial lebih mudah untuk menebak atau memaksa 3 karakter dari 8 karakter.

  • Keyakinan bahwa kata sandi lengkap tidak diketahui dapat salah tempat mis. jika kata sandinya adalah Fulham dan Anda tahu F, l, h, Anda mungkin bisa menebak kata sandi lengkap

  • Situs phishing yang hanya meminta tanggal 1, 3, 5 lalu mengatakan kata sandi salah dan berubah untuk meminta 2, 4, 6 juga bisa mendapatkan kata sandi lengkap karena pengguna mungkin akan memasukkannya sebelum mereka berpikir dua kali

  • Dari perspektif kenyamanan pengguna, itu berarti mereka tidak dapat menggunakan kata sandi ingat browser atau pengelola kata sandi seperti Lastpass atau 1Password

Sebagian besar bank menjauh dari mengandalkan nama pengguna dan kata sandi, mis. HSBC menawarkan token RSA untuk pelanggan bisnis, Barclays memiliki pembaca kartu pintar EMV, hampir semuanya menggunakan teknologi deteksi seperti otentikasi adaptif RSA untuk menetapkan dasar peramban, lokasi, profil penggunaan, kecepatan dll untuk otentikasi pasif dan deteksi penggunaan yang tidak sah.

2
Rakkhi