23

Kata sandi tidak boleh disimpan dalam teks biasa karena alasan keamanan yang jelas: Anda harus menyimpan hash, dan Anda juga harus membuat hash dengan hati-hati untuk menghindari serangan tabel pelangi.

Namun, biasanya Anda memiliki persyaratan untuk menyimpan n kata sandi terakhir dan untuk menerapkan kompleksitas minimal dan perubahan minimal antara kata sandi yang berbeda (untuk mencegah pengguna menggunakan urutan seperti Kata Sandi_1, Kata Sandi_2, ..., Kata Sandi_n ). Ini mungkin sepele dengan kata sandi teks biasa, tetapi bagaimana Anda bisa melakukannya dengan hanya menyimpan hash?

Dengan kata lain: bagaimana mungkin menerapkan mekanisme riwayat kata sandi yang aman?

security passwords

— Wizard79
sumber

2

Terkait: security.stackexchange.com/questions/4704/… (dan BTW situs itu mungkin merupakan lokasi yang lebih baik untuk pertanyaan ini). Sejauh 'perubahan minimal', saya tidak bisa memikirkan alternatif untuk menghasilkan semua opsi yang akan memenuhi syarat sebagai 'perubahan minimal' (Yang bisa menjadi BANYAK tergantung pada definisi Anda!) Dan membandingkan hash. Apa definisi 'perubahan minimal'?

— Kevin Vermeer

7

Menyimpan n kata sandi terbaru hanya berarti bahwa pengguna akan memilih urutan yang berjalan dari 1 hingga n + 1 .

— Joachim Sauer

11

Saya sangat skeptis bahwa kebijakan kata sandi semacam itu meningkatkan keamanan; IMHO, ini meningkatkan kemungkinan orang akan menggunakan kata sandi dengan catatan tempel. Tautan Kevin adalah diskusi yang bagus. @KevinVermeer - Anda sebenarnya dapat mengukur jumlah perubahan sebagai jarak Levenshtein ( en.wikipedia.org/wiki/Levenshtein_distance ), juga dikenal sebagai "edit jarak".

— Nathan Long

5

Jika keamanan Anda sangat ketat, maka Anda mungkin juga membuat kata sandi acak untuk pengguna, memaksa mereka untuk menggunakannya, dan mengubahnya secara berkala. Dengan begitu Anda memiliki kendali penuh atas kata sandi mereka.

— Reactgular

2

@ nathan: Menyimpan kata sandi pada catatan tempel sebenarnya aman. Tidak mungkin menyerang kata sandi kecuali Anda memiliki akses fisik ke catatan tempel - menghilangkan sekitar 99% ancaman. Letakkan catatan itu di dalam dompet atau dompet, dan pada dasarnya Anda perlu memberi mug orang itu untuk mendapatkannya - artinya pelanggaran keamanan diidentifikasi dan dapat dikurangi.

— mattnz

22

Simpan hash dan verifikasi kata sandi yang dimasukkan terhadap hash yang disimpan, dengan cara yang sama seperti Anda memverifikasi kata sandi saat masuk. Anda harus membuat kata sandi 'alternatif' dari kata sandi yang diberikan berdasarkan pola numerik untuk mendeteksi perubahan 'minimal' Anda.

Saat login, Anda memverifikasi kata sandi yang dimasukkan terhadap hash, tidak perlu menyimpan kata sandi dalam plaintext. Trik yang sama berfungsi saat mengubah kata sandi, cukup periksa kata sandi yang dimasukkan dan 'perubahan minimal' yang dihasilkan terhadap hash historis. Jika kata sandi baru memuaskan, pindahkan hash kata sandi saat ini ke kumpulan riwayat, dan ganti dengan hash baru untuk kata sandi baru.

— Martijn Pieters
sumber

Jadi, jika pengguna memasukkan Kata Sandi6 saya harus mendeteksi bagian angka, dan coba misalnya Kata Sandi4 , Kata Sandi5 , Kata Sandi7 , dan sebagainya. Apakah itu benar?

— Wizard79

4

@ Lorenzo: Benar. Menghasilkan alternatif bisa serumit yang Anda inginkan, pastikan Anda menemukan tradeoff yang tepat antara kompleksitas dan risiko (jangan biarkan pengguna Anda menunggu 5 menit saat Anda memeriksa semua kemungkinan dengan menghilangkan kemungkinan menjadi risiko).

— Martijn Pieters

Saya tidak yakin menyarankan penambahan nomor pada akhirnya adalah saran yang bagus untuk dibuat bagi pengguna - itu hanya sedikit dapat diprediksi. Dan menjadi lebih eksponensial jika Anda memberi tahu pengguna untuk melakukannya.

— Wyatt Barnett

2

@ WyattBarnett: Tidak ada yang memberitahu pengguna untuk melakukannya. Intinya adalah untuk mendeteksi pengguna yang melakukannya dan mencegah kata sandi yang 'bertambah' digunakan.

— Martijn Pieters

Ah, salah baca sesuatu di sini. Maaf.

— Wyatt Barnett

28

Ketika pengguna mengubah kata sandi mereka, minta mereka memasukkan kata sandi sebelumnya. Anda sekarang memiliki akses ke dua kata sandi teks biasa, meskipun Anda tidak menyimpan kata sandi teks biasa dalam basis data Anda.

Lakukan verifikasi apa pun yang Anda inginkan pada kedua kata sandi ini. Ini tidak akan mencegah pengguna untuk berganti-ganti antara dua kata sandi (dengan akhiran - Anda dapat mencegah pergantian langsung sesuai saran dalam jawaban lain), tetapi itu akan mencegah kasus yang lebih mencolok.

— Brian
sumber

Nah ini tentu solusi cerdas jika Anda tidak memiliki persyaratan pengujian terhadap n password sebelumnya, namun saran menghasilkan alternatif tepat pada waktu yang lebih baik. Tetapi menghasilkan alternatif kedua kata sandi bahkan lebih baik!

— Wizard79

2

@ Lorenzo: Idenya adalah Anda melakukan tes langsung terhadap n kata sandi sebelumnya dan tes yang lebih kuat terhadap kata sandi terakhir. Ini kompromi.

— Brian

Iya nih. Jika kata sandi mereka saat ini potatoSalad1dan mereka ingin memperbarui potatoSalad2, Anda memberi tahu perubahannya terlalu kecil karena Anda memiliki kedua kata sandi teks biasa pada saat itu. Tetapi lebih jauh dari itu, Anda hanya memiliki hash, dan sifat hash adalah bahwa Anda tidak dapat mengatakan apakah dua hash memiliki teks biasa yang sama atau sangat berbeda sebagai input.

— Nathan Long

7

untuk menambahkan jawaban @ martijnPieter, perubahan minimal dapat diimplementasikan dengan melakukan brute force pendek berdasarkan kata sandi baru dan sebelumnya (yang Anda berdua telah tersedia)

misalnya Anda dapat mengulangi semua kata sandi dengan jarak tempuh 1 atau 2 dari kata sandi baru dan melihat apakah cocok dengan pass lama

tetapi Anda mungkin ingin mencatat bahwa ini dapat mengurangi kepercayaan pengguna bahwa Anda hashing passwords (karena Anda pada dasarnya mengatakan Anda bisa mendapatkan kembali kata sandi sebelumnya untuk menolak kata sandi baru)

— ratchet freak
sumber

Tetapi ada banyak urutan dengan jarak Hamming yang lebih besar seperti Februari2012 -> March2012 atau Jumat-09-28-12 -> Sel-11-27-12 (tanggal), Kata Sandi_Alpha -> Kata SandiBeta, Pass_1111 -> Pass_2222, Pass_qwer, Pass_tyui, Pass, _op [], atau Eleven -> Twelve (sistem penghitungan alternatif), atau FrankSmith -> FredJones -> FriarTuck atau angry -> animal -> apple (nama dalam direktori perusahaan atau kata-kata dalam kamus) yang diserang oleh penyerang dengan kata sandi sebelumnya dapat dengan mudah ditebak tetapi algoritma Anda akan mengalami kesulitan menghasilkan.

— Kevin Vermeer

@KevinVermeer kemudian memperhitungkan mereka yang ada di generator variasi Anda, dan menerima bahwa Anda tidak akan pernah mendapatkan semuanya

— ratchet freak

+1 untuk mengurangi kepercayaan diri. Ketika saya melihat sesuatu yang memberi tahu saya bahwa kata sandi saya terlalu mirip dengan yang saya gunakan tiga bulan lalu, saya langsung bertanya-tanya apakah mereka menyimpannya secara terbalik ... atau jika mereka memiliki programmer yang hebat. Skeptisisme biasanya menang.

— Tim Post

5

Ini benar-benar lebih merupakan tambahan dari jawaban cerdas @ Brian. Tutup juga ke @Martijn Pieters untuk menambahkan rincian tentang cara memaksa paksa kata sandi lama berdasarkan yang sekarang dan ke @ scratchet freak untuk "jarak hamming." Saya tidak menghapus jawaban saya karena saya pikir ini memberikan latar belakang yang menarik untuk mendukung mereka.

Penyimpanan kata sandi yang canggih membutuhkan penggunaan beberapa putaran hash kriptografis satu arah yang kuat (SHA-512 +) dengan garam unik (128-bit +) untuk setiap pengguna. Tetapi jangan tergoda untuk menyimpan informasi tambahan tentang setiap kata sandi. Semakin banyak informasi yang Anda simpan tentang setiap kata sandi, semakin Anda merusak keamanan algoritma hashing Anda.

Contoh

Pertimbangkan betapa mudahnya memaksakan kata sandi jika Anda tahu itu:

Panjangnya 7 karakter
Karakter 3-5 adalah huruf besar (4 lebih rendah)
1 dan 7 adalah angka
6 adalah simbol

Papan ketik AS memiliki 95 karakter yang dapat dicetak, sehingga mengetahui bahwa kata sandinya panjangnya 7 karakter menghasilkan 95 ^ 7 = 69.833.729.610.000 = 7x10 ^ 13 permutasi. Jika itu benar-benar acak, mungkin butuh waktu satu tahun untuk memecahkan ini pada prosesor 3Ghz tunggal. Tapi:

Hanya ada 26 huruf besar dan 26 huruf kecil
Hanya ada 10 digit yang menghasilkan 100 kemungkinan untuk dua angka tersebut
Hanya ada 32 simbol

Jadi (dikoreksi berkat @Hellion):

         26^4 (charcters 2-5 are known upper or lower-case)
        x 100 (characters 1 & 7 are digits)
        x  32 (character 6 is a symbol)
         ====
1,462,323,200 possible passwords.

Itu 50.000 kali lebih mudah retak! Menyimpan informasi yang baik untuk mencegah kata sandi yang sama dalam kasus ini telah menghabiskan waktu Anda untuk kata sandi 7-karakter dari setahun hingga beberapa jam. Decoding semua kata sandi Anda dengan desktop multi-prosesor yang kuat dengan kartu video yang bagus dan sedikit kesabaran sekarang sangat layak. Saya harap contoh sederhana ini menunjukkan bahwa semakin bermakna Anda dapat membandingkan kata sandi yang sama, semakin tidak aman hashing Anda.

Pentingnya Hashing Yang Kuat

Basis data dengan kata sandi dicuri secara teratur, dengan pembobolan besar dalam berita setiap bulan. Heck, baru bulan lalu keadaan SC kehilangan nomor jaminan sosial semua orang - ya! Berapa banyak lagi pelanggaran ini yang ditutup-tutupi?

Pikiran Penutup

Hal yang paling menakutkan bagi saya adalah ketika orang memilih kata sandi yang sama atau mirip untuk beberapa situs sehingga membobolnya memberikan penyerang akses ke semuanya. Saya ingin melihat metode yang terbukti mencegah situasi itu, meskipun saya pikir mencegah kata sandi buruk yang paling umum akan membantu lebih dari mencegah seorang pengguna menggunakan kembali kata sandi buruk mereka di situs yang sama. Yang terbaik yang bisa saya sarankan adalah kebijakan di seluruh perusahaan untuk menggunakan pengelola kata sandi aman yang menghasilkan kata sandi sangat acak untuk setiap pengguna Anda dan menyimpannya dengan aman.

— GlenPeterson
sumber

1

minor nit: kemungkinan kata sandi masih berlipat ganda, jadi (26 ^ 4) * 100 * 32 = 1.462.323.200. Jika kita mengasumsikan bahwa cracking (95 ^ 7) kemungkinan membutuhkan waktu satu tahun, maka cracking dalam jumlah yang lebih kecil ini kemungkinan akan memakan waktu sekitar 11 menit.

— Hellion

@ Halo - Ups! Terima kasih telah menunjukkannya. Saya sudah memperbaikinya.

— GlenPeterson

1

Pertama, Anda bisa menyimpan hash untuk kata sandi "n" terakhir, jadi Anda dapat memeriksa apakah kata sandi baru mereka menggandakan kata sandi sebelumnya. Anda juga memiliki teks biasa kata sandi mereka saat ini (karena mereka telah login atau memberikannya kepada Anda untuk mengotentikasi permintaan perubahan kata sandi mereka), dan kata sandi baru mereka, sehingga Anda dapat memeriksa perubahan minimal antara kedua kata sandi ini.

Jika (untuk Anda) sangat penting untuk membandingkan secara langsung kedua kata sandi ini dengan kata sandi "n" sebelumnya, maka Anda harus menyimpan kata sandi ini (dienkripsi) untuk dapat mengambilnya nanti.

Sementara itu dapat dilihat sebagai cacat keamanan untuk melakukan ini, metode enkripsi dapat diimplementasikan untuk memberikan keamanan yang memadai.

Simpan setiap kata sandi (terenkripsi), untuk kata sandi "n" terakhir.
Simpan tanggal dan waktu pembuatan kata sandi terbaru.
Simpan hash kata sandi terbaru.
Enkripsi semua kata sandi menggunakan hash (asin) kata sandi saat ini, dan cap waktu pembuatan kata sandi, dan mungkin sesuatu seperti nomor akun atau alamat email.
Batalkan enkripsi dan enkripsi ulang semua kata sandi setiap kali kata sandi baru dibuat.

Kemudian, kapan pun kata sandi diubah, Anda dapat membatalkan enkripsi semua kata sandi lama, dan melakukan semua tes perubahan minimal.

Sekarang, jika seseorang memiliki kata sandi orang ini, dan mengetahui semua perincian lainnya yang diperlukan, mereka dapat membatalkan enkripsi informasi ini untuk orang ini. Tetapi jika mereka sudah memiliki kata sandi orang ini, mereka sudah bisa masuk sebagai orang ini dan mengakses akun orang ini.

Juga, untuk kata sandi lama, kata sandi tersebut mungkin tidak harus disimpan dalam teks biasa. Mereka dapat disimpan dalam beberapa cara yang dikaburkan. Atau disimpan sebagai daftar karakter alfabet dalam kata sandi.

Saya tidak mengatakan ini adalah hal yang direkomendasikan untuk dilakukan dalam kasus umum, tetapi dengan asumsi tugas yang telah Anda jelaskan diperlukan dalam kasus Anda, maka ini adalah salah satu cara untuk menyelesaikannya dengan beberapa langkah keamanan.

— Kevin Fegan
sumber

Jawaban ini membuat beberapa saran buruk dalam hal keamanan. Kita seharusnya tidak dapat dengan mudah mendekripsi kata sandi, atau menyimpannya dalam "cara yang membingungkan" alih-alih mengenkripsi mereka dengan kuat.

— user45623

Cara menerapkan riwayat kata sandi yang aman

Contoh

Pentingnya Hashing Yang Kuat

Pikiran Penutup