Apakah 'jika kata sandi == XXXXXXX' cukup untuk keamanan minimum?

20

Jika saya membuat login untuk aplikasi yang memiliki risiko keamanan menengah ke bawah (dengan kata lain, ini bukan aplikasi perbankan atau apa pun), apakah saya dapat memverifikasi sandi yang dimasukkan oleh pengguna dengan hanya mengatakan sesuatu seperti:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Tampaknya mudah untuk menjadi efektif, tetapi saya tentu tidak akan keberatan jika itu saja yang diperlukan. Apakah pemeriksaan sederhana pada nama pengguna / kata sandi cukup?

Pembaruan: Proyek tertentu adalah layanan web, verifikasi sepenuhnya sisi server, dan bukan open-source. Apakah domain mengubah cara Anda menangani hal ini?

security  passwords  validation 
— Morgan Herlocker
sumber
3
tergantung dari mana kata validPassword? jika hardcoded Anda tidak akan dapat mengkonfigurasi / mengubah kata sandi tanpa mengubah kode. Jika itu berasal dari file konfigurasi, itu akan terlihat oleh siapa saja yang mengaksesnya.
— Alb
1
"Apakah cek pada nama pengguna / kata sandi cukup" untuk melakukan apa?
— Chris
3
@opinion: sepertinya tidak mungkin ini lebih buruk daripada tidak memiliki login. Harap berikan alasan untuk klaim yang kuat.
— Morgan Herlocker
1
Terminologi Anda salah, saat Anda membandingkan kata sandi yang Anda verifikasi, tidak memastikan kata sandinya valid. Silakan luangkan waktu untuk memahami perbedaannya.
— billy.bob
1
Ini menyiratkan penyimpanan kata sandi teks biasa, yang tidak bertanggung jawab. Ini juga menyiratkan memperingatkan pengguna bahwa kata sandi itu salah, yang memberikan informasi yang terlalu banyak kepada penyerang potensial. Anda harus selalu ambigu, yaitu "Login atau kata sandi salah".
— Rein Henrichs

Jawaban:

26

Bukan tanpa SSL

Ini tidak aman jika kata sandi dikirim melalui jaringan dalam teks biasa. Hashing kata sandi di sisi server juga tidak aman jika kata sandi dikirim melalui jaringan dalam teks biasa.

Karena <input type="password"/>tag HTML mengirimkan kontennya dalam teks biasa, ini akan menjadi masalah tidak peduli bagaimana Anda menyimpan kata sandi di server, kecuali situs web Anda menggunakan SSL untuk mengirimkan kata sandi.

(Otentikasi HTTP, yang memunculkan kotak dialog di browser yang meminta kata sandi, mungkin atau tidak menjadi teks yang jelas, tergantung pada mekanisme otentikasi apa yang dimiliki server dan browser. Jadi itu bisa menjadi cara untuk menghindari ini tanpa menggunakan SSL.)

Tidak jika administrator situs dicurigai

Sekarang, seandainya Anda menggunakan HTTPS untuk melakukan situs web, ini bisa aman jika Anda mempercayai administrator situs Anda (yang dapat membaca kata sandi teks biasa), dan orang lain yang memiliki akses ke mesin untuk berperilaku baik. Sekarang, mungkin jelas bahwa mereka dapat melakukan apa pun yang mereka inginkan dengan situs web Anda (karena mereka mengelolanya), tetapi jika mereka dapat membaca kata sandi, mereka juga dapat menggunakan pasangan login / kata sandi yang dicuri di situs orang lain.

Cara yang membuat kata sandi aman dari administrator

Satu cara aman untuk menyimpan dan memeriksa kata sandi adalah sebagai berikut:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

Untuk fungsi hash, coba gunakan sesuatu yang kuat, dan sesuatu yang belum memiliki tabel pelangi yang bagus di alam liar. Anda dapat mengubah panjang garam jika perlu bekerja di sekitar meja pelangi.

Bergantung pada lingkungan tempat Anda berada, variabilitas dalam latensi jaringan Anda, dan apakah nama pengguna dimaksudkan untuk diketahui secara publik, Anda mungkin ingin agar jalur kode lain menghitung hash('0000'+entered_password)jika pengguna tidak ada, untuk mencegah penyerang dari menentukan nama pengguna mana yang valid berdasarkan waktu yang dibutuhkan menentukan bahwa kata sandi salah.

— Ken Bloom
sumber
1
Saran yang bagus :) Mengenai SSL, kami diminta untuk merancang sesuatu yang akan bekerja di alam bebas , dan hanya menggunakan kriptografi asimetrik untuk menyandikan kata sandi (memerlukan Javascript) dan kemudian mendekodekannya di server. Garam + hash kemudian muncul secara normal. Juga, karena kunci publik dikirim dengan halaman-web, itu dapat berubah sesering mungkin.
— Matthieu M.
1
@Matthieu M .: Ketika seseorang dapat memalsukan halaman web Anda, ia juga dapat mengubah kunci publik di sana menjadi yang ia tahu kunci pribadi terkait. Jadi ide Anda hanya membantu melawan serangan baca pasif, bukan terhadap man-in-the-middle
— Paŭlo Ebermann
@ Paulo: ya, saya setuju bahwa SSL tidak hanya tentang enkripsi, tetapi juga tentang sertifikat, sayangnya saya tidak menyebut gambar di sini, dan ketika orang mengatakan mereka ingin menggunakan halaman web dengan http://koneksi biasa ... itu membuat frustrasi: /
— Matthieu M.
@Matthieu: Apakah itu berarti Anda mengirim public_key sebagai bagian dari halaman web publik, menghitung encrypt(entered_password, public_key)klien, dan mengirimkan hasil itu ke server, yang berkinerja does_password_match?(user, decrypt(encrypted_password, private_key))?
— Ken Bloom
@ Ken: kurang lebih, enkripsi enkripsi Anda benar. Untuk mencocokkan kata sandi lebih banyak does_password_match(user, salt, decrypt(encrypted, key)), dengan garam tergantung pada pengguna. Seperti yang saya katakan, masalah yang jelas adalah kurangnya perlindungan manusia di tengah.
— Matthieu M.
52

Itu akan menyarankan, bahwa Anda menyimpan kata sandi dalam teks terbuka, yang merupakan tidak-tidak, bahkan dalam skenario keamanan rendah.

Anda sebaiknya memiliki:

if(hash(enteredPassword) == storedHash)

Anda dapat menggunakan hash sederhana seperti MD5 misalnya

— vartec
sumber
22
+1 untuk hashing kata sandi. Tapi saya setidaknya akan menambahkan garam juga. Jika tidak, karena pengguna akan menggunakan kembali nama pengguna & kata sandi antara sistem, melanggar aplikasi keamanan rendah Anda dapat memungkinkan penyerang untuk melanggar aplikasi keamanan yang jauh lebih tinggi. Peretasan HBGary baru-baru ini, misalnya, berhasil kompromi sistem CMS menjalankan situs web mereka dan mengubahnya menjadi akses root ke server mereka sebagian karena sistem CMS keamanan rendah tidak menambahkan garam ke hash arstechnica.com/tech-policy/ news / 2011/02 / ...
— Justin Cave
1
Setuju ... pertimbangkan yang berikut ini .. "strings JavaFile.class | grep -i password"
— Bill
Apa masalah dengan kata sandi dalam teks biasa jika hanya digunakan satu kali?
10
@Tim karena pengguna tidak akan menggunakan kata sandi hanya sekali. Penelitian secara konsisten menunjukkan bahwa pengguna menggunakan kembali kata sandi beberapa kali (mis. Theregister.co.uk/2011/02/10/password_re_use_study ) tidak peduli berapa kali mereka diberitahu untuk tidak melakukannya.
— Scott
3
@Tim: selain itu, cukup buka exe Anda, dll, dll, dalam editor teks, dan Anda mungkin akan melihat kata sandi Anda di sana.
— Gus Cavalcanti
14

Saya setuju dengan mereka yang menyarankan hashing, tetapi ada juga roda yang Anda temukan kembali di sini. Bergantung pada platform Anda mungkin dapat menemukan alat manajemen peran / pengguna yang mencakup semua hal manajemen pengguna dengan aman dan aman tanpa perlu terlalu banyak intervensi di pihak Anda.

— glenatron
sumber
Saya baru saja menemukan Penyedia Keanggotaan ASP.Net tetapi saya melihat mereka berpikir, "sudah berapa kali saya membuang waktu untuk mengimplementasikan sesuatu seperti ini?"
— glenatron
8

Keamanan adalah subjek yang sangat sensitif, terutama karena harus ada keseimbangan antara ketidaknyamanan pengguna Anda dan memastikan informasi mereka aman. Biasanya, rumus untuk berapa banyak keamanan yang Anda butuhkan adalah fungsi dari pentingnya data. Pendeknya:

isSecuritySufficient = effortToBreak > rewardForBreaking

Kesalahpahaman umum tentang orang-orang yang melakukan hal-hal buruk adalah apa yang mereka kejar. Sebagian besar dari mereka keluar untuk menghancurkan kepercayaan . Anda harus selalu melakukan apa saja untuk melindungi kepercayaan pengguna Anda. Bagian dari itu adalah melakukan uji tuntas Anda untuk memastikan identitas mereka aman. Mereka mungkin tidak terlalu peduli dengan data yang mereka simpan, tetapi mereka benar-benar peduli dengan identitas mereka - bahkan pada ambang keamanan terendah.

Ada sejumlah opsi berbiaya rendah (untuk menerapkan dan berdampak pada pengguna). Salah satunya adalah hashing password minimal. Layanan apa pun yang menyimpan sesuatu yang sensitif seperti kata sandi dalam teks biasa layak untuk dipermalukan.

Prinsip Umum untuk Perlindungan Kata Sandi

  • Jangan pernah menyimpan kata sandi dalam teks biasa
  • Hash menggunakan fungsi hash aman seperti SHA-1 atau bahkan SHA-512 (bahkan MD5 terlalu mudah untuk menemukan hash yang cocok)
  • Gunakan nilai garam aplikasi. Garamnya adalah byte acak yang ditambahkan ke kata sandi untuk membuatnya lebih sulit ditebak. Garam harus dihasilkan pada saat dijalankan dan menggunakan informasi tentang mesin sebagai nilai awal daripada disimpan dan dirujuk dengan cara apa pun.
  • Gunakan nilai garam spesifik pengguna. Gunakan ini bersamaan dengan garam aplikasi Anda.
  • Enkripsi semua permintaan otentikasi yang masuk ke jaringan. Itu berarti menggunakan SSL untuk aplikasi web.

Karena Anda akan menggunakan SSL untuk otentikasi, minimal Anda ingin mengenkripsi semua halaman yang berhubungan dengan akun pengguna juga. Ini memungkinkan sebanyak mungkin identitas pengguna dilindungi.

Catatan tentang manajemen kata sandi : Pengguna akan lupa kata sandi mereka dari waktu ke waktu. Hal terburuk yang dapat Anda lakukan adalah mengirimkan kata sandi mereka dalam email. Jika Anda menerapkan prinsip-prinsip yang diuraikan di atas, Anda tidak akan bisa melakukannya. Jauh lebih baik untuk menyediakan cara untuk mereset kata sandi mereka menggunakan tautan yang dikirim ke alamat email terdaftar mereka. Tautan reset itu akan memiliki kode penggunaan satu kali untuk memastikan orang yang mengakses halaman itu adalah mereka.

— Berin Loritsch
sumber
1
Pada awalnya saya benar-benar dikejutkan oleh ide aplikasi garam + garam pengguna, tetapi semakin saya memikirkannya, semakin kurang yakin saya. Jika Anda menggunakan, misalnya, 4 karakter garam aplikasi dan 4 garam pengguna, maka perbedaan antara itu dan 8 karakter garam pengguna adalah hanya setengah garam itu akan sama untuk setiap pengguna. Tampaknya akan lebih aman untuk hanya meningkatkan ukuran garam pengguna, daripada menggunakan garam aplikasi. Juga, jika garam aplikasi didasarkan pada perangkat keras maka Anda tidak dapat memutakhirkan atau mengubah perangkat keras tanpa membatalkan semua kata sandi.
— David Conrad
Masalahnya adalah bahwa garam pengguna termasuk dalam baris database dengan kata sandi pengguna. Jika orang jahat tahu untuk apa garam itu (dan mereka tahu), dan mereka melihatnya di database, maka mereka tahu cara memecahkannya. Dengan memasukkan bagian dalam aplikasi yang dihitung (dengan cara yang sama setiap kali Anda ingat) alih-alih disimpan, itu membuatnya menjadi jauh lebih sulit untuk memecahkan tabel pengguna. Tentu saja Anda dapat melangkah lebih jauh dan membuat 1 bagian garam acak murni dan 1 bagian garam yang dihitung dengan keduanya merupakan spesifik pengguna.
— Berin Loritsch
Ah, begitu ya, jauhkan garam dari database. Itu masuk akal. Terima kasih.
— David Conrad
Saya tidak melihat masalah saat menyimpan garam per baris, asalkan unik per baris. Inilah hash: "fd84235a55bbfeb1585a3dd069d48127989c9753058b51b6ba2056fd6c5a0a91" (SHA256), ini garamnya: "671254bdf7944f8fa88e6c9913b948ee". Anda pikir Anda bisa mendapatkan kata sandi? Tidak ada meja pelangi untuk garam itu (bahkan jika Anda diberi garam), Anda terjebak memaksakannya.
— Bryan Boettcher
3

Tidak apa-apa kecuali kata sandinya digunakan untuk hal lain. Masih ada risiko bahwa pengguna memutuskan bahwa ia dapat menggunakan kembali kata sandi, sehingga akan lebih baik dengan:

if(hash(enteredPassword) == hashOfValidPassword)

Jika itu untuk Anda sendiri atau seseorang yang sadar bahwa kata sandi disimpan dalam teks biasa, maka tidak masalah.

1
Seperti dalam komentar Justin Cave untuk jawaban vartec, gunakan garam, jadi if (hash (enteredPassword + salt) == hashOfValidSaltedPassword)- dan perhatikan bahwa +ini mungkin gabungan, bukan penambahan. Ini benar-benar menghalangi penggunaan tabel pelangi, yang merupakan tabel hash kata sandi yang mungkin.
— David Thornley
jika semua yang Anda periksa adalah hash, tidak bisakah mereka menjalankan hanya melalui string string yang mungkin sampai satu menghasilkan hash yang sama dengan hash yang disimpan? Ada banyak string yang bisa berhubungan dengan hash yang sama.
— Morgan Herlocker
@Prof Plum: Sangat sulit untuk menemukan tabrakan jika algoritma hashing baik. Ini adalah dasar dari kriptografi modern: mereka pada dasarnya adalah fungsi satu arah.
3

Apakah kode sumber tersedia? Bahkan jika tidak, saya cukup yakin kata sandi dapat ditemukan dalam instruksi mesin jika biner tersedia. Saya akan merekomendasikan melakukan checksum dan membandingkannya sebagai gantinya.

Jangan pernah mengabaikan keamanan bahkan jika itu tidak terlalu penting menurut Anda.

— Anto
sumber
2
Ya, ide buruk jika ini adalah proyek open source :)
-1 - Jika Anda berpikir memiliki sumber membuat perbedaan, Anda tidak tahu apa-apa tentang keamanan.
— mattnz
1

Benar-benar tidak. Baca ini , ini menjelaskan bagaimana peretas meretas situs web keamanan. Anda berencana menjadikan Anda sebagai tautan terlemah dalam rantai.

— dave
sumber
0

Telah dicatat dalam beberapa jawaban bahwa Anda tidak harus menyimpan kata sandi itu sendiri, tetapi sebuah hash - dan Anda harus menggunakan SSL.

Anda mungkin berkata, apa masalahnya? Jika aplikasi saya diretas, itu tidak penting. Yah itu adalah pola yang cukup umum bagi pengguna untuk menggunakan kembali kata sandi yang sama di semua situs. Jika seorang peretas untuk meretas situs Anda dan mendapatkan akses ke kata sandi pengguna, peretas akan dapat menyamar sebagai banyak pengguna di situs lain yang lebih penting bagi pengguna tersebut. Jadi meretas situs Anda bisa menjadi langkah pertama bagi seorang peretas untuk mendapatkan akses ke informasi perbankan bagi para pengguna.

Dan hanya hashing kata sandi tidak cukup. Anda perlu hash dengan garam. Hacker membalikkan tabel pencarian hash, jadi untuk hash yang diberikan, mereka dapat menemukan kata sandi yang cocok.

Jika Anda memilih untuk tidak mengimplementasikan fitur ini, Anda harus memberi tahu para pengguna tentang kurangnya keamanan ini, mendorong mereka untuk tidak menggunakan kata sandi yang sama dengan yang mereka gunakan di tempat lain.

— Pete
sumber
-2

Selama ini adalah sisi server .. Lalu ya.

Jika Anda menginginkan keamanan yang lebih baik, gunakan https dan enkripsi sandi hash di DB.

— Orang bodoh
sumber
3
Mengapa menganggap ini adalah aplikasi web?
— Chris
Poin bagus! Saya baru saja melakukannya.
— Moron
4
-1 bahkan jika itu adalah sisi server ini masih tidak ok.
— GSto
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.