Bagaimana meyakinkan pengguna bahwa situs web dan kata sandi aman [ditutup]


15

Di situs web yang andal, saya selalu melihat klaim seperti "Semua data dienkripsi" atau "Semua kata sandi dienkripsi menggunakan enkripsi 128bit" dan lain-lain. Namun saya belum pernah menemukan klaim seperti "Semua kata sandi diacak."

Di situs web saya, saya akan menyimpan semua kata sandi pengguna dalam database setelah menggunakan SHA-512 (kemungkinan besar) hashing dengan garam acak. Saya ingin menambahkan snipet yang meyakinkan pengguna bahwa kata sandi mereka aman sehingga mereka tidak akan terhalang untuk menggunakan situs web saya karena memerlukan kata sandi. Saya ingin pengguna merasa aman tetapi saya tidak berpikir semua orang tahu apa hashing itu.

PERTANYAAN SAYA: Apakah boleh memberikan pesan yang mengatakan bahwa "Semua kata sandi dienkripsi dan aman" karena saya tidak berpikir bahwa rata-rata pengguna akan tahu apa perbedaan antara hashing dan enkripsi, dan lebih mungkin merasa aman hanya karena mereka melihat kata kenyamanan "enkripsi"? Atau adakah pesan alternatif yang harus saya berikan?

Di samping catatan, saya baru mengenal enkripsi dan kata sandi dan saya bertanya-tanya apakah ini akan cukup aman untuk saat ini ketika saya meluncurkan situs saya. Saya tidak ingin memberi tahu pengguna bahwa ini aman jika tidak. Informasi apa pun akan sangat dihargai. Terima kasih.


7
Secara pribadi saya tidak akan terlalu khawatir tentang komunikasi: menulis deskripsi teknis tentang apa yang Anda lakukan, terkubur di suatu tempat jauh di FAQ di mana orang yang berpikiran teknis akan menemukannya. Orang lain sebenarnya tidak peduli. Yang lebih penting: pastikan Anda melakukan hal yang benar (itu sulit jika Anda baru, tetapi setidaknya Anda mencoba!). Jangan membuat hashing Anda sendiri, gunakan sesuatu seperti bcrypt .
Joachim Sauer

4
Nah, hal yang benar adalah untuk menggabungkan login dan tidak mengganggu pengguna dengan nama pengguna dan kata sandi lainnya.
Jan Hudec

1
OpenID baik, tetapi nama pengguna / passwork juga ok. Saya tidak berpikir masalah Anda adalah meyakinkan pengguna bahwa situs Anda aman. Karena Anda tidak berpengalaman, itu seperti menjanjikan sesuatu yang tidak Anda miliki. Cukup terapkan standar umum - Anda tidak akan menghentikan peretas profesional datang, tetapi tidak ada yang bisa menyalahkan Anda juga.
Hoàng Long

3
@coredump Memang. Menggunakan SHA-512 untuk hashing kata sandi tidak baik. Itu tidak baik".
Thomas

3
Saya mungkin layak mengajukan pertanyaan tindak lanjut tentang Keamanan Informasi untuk memastikan Anda mendapatkan yang terbaik, saran terkini. (Itu tidak berarti Anda mendapatkan saran buruk di sini, hanya saja kami belum tentu profesional keamanan).
ChrisF

Jawaban:


22
  1. Pengguna tidak peduli.

    Satu-satunya waktu mereka peduli adalah ketika seseorang menarik uang dari rekening bank mereka dan tampaknya memiliki tautan yang beberapa hari sebelumnya, seseorang memperoleh akses penuh ke database Anda.

  2. Hampir di setiap kasus saya melihat pesan seperti itu, mereka menyesatkan. Yang paling lucu ada di situs web dengan label gaya "aman tingkat militer" di setiap halaman. Ada peringatan yang mengatakan bahwa sertifikat HTTP tidak valid. Ada injeksi SQL pada formulir masuk. Beberapa minggu kemudian, situs web diretas, lalu menghilang selamanya.

    Saya berhenti menghitung jumlah situs web yang mengklaim bahwa mereka menjaga keamanan informasi, sambil memiliki formulir "Pulihkan kata sandi saya", yang sebenarnya mengirim kata sandi asli melalui email.

    Ini seperti label "W3C valid XHTML". Mengapa mereka biasanya memakai website di mana bahkan halaman rumah mengandung setidaknya puluhan kesalahan dan kode seperti <DIV COLOR='red'>?

Jika Anda masih ingin meyakinkan pengguna, Anda dapat meletakkan sesuatu seperti:

Kata sandi Anda tetap aman. Ingatlah bahwa kami tidak dapat melihat kata sandi Anda dan tidak akan pernah mengirimi Anda surel yang meminta Anda untuk memberikannya.

Tapi sejujurnya, formulir "Reset kata sandi saya" menggantikan "Saya lupa kata sandi saya; kirimkan kepada saya melalui email" jauh lebih meyakinkan daripada kata-kata apa pun.

Petunjuk dari berbagai komentar:

  • Jangan menemukan kembali roda: gunakan OpenID. Dengan cara ini, Anda bahkan tidak menyimpan hash.

    Sumber: komentar oleh Jan Hudec .

  • Karena Anda seorang pelajar, sumber terbuka proyek Anda. Karena kekhawatiran Anda adalah: "Saya tidak ingin pengguna berpikir bahwa kata sandi mereka tidak aman karena beberapa anak di sekolah mendesainnya." , tidak ada yang lebih meyakinkan bahwa bisa memeriksa, dengan membaca kode sumber, bahwa itu ditulis oleh pengembang yang terampil yang peduli dengan keamanan.

    Sumber: komentar oleh Jan Doggen .


Terima kasih atas masukannya kalian. Masalahnya adalah saya seorang siswa yang merancang layanan untuk uni saya. Saya tidak ingin pengguna berpikir bahwa kata sandi mereka tidak aman karena beberapa anak di sekolah mendesainnya. Saya telah melihat banyak metode yang berbeda termasuk bcrypt dan saya belum memutuskan mana yang akan digunakan. Saya pikir itu akan cukup aman sekarang dan jika banyak orang mulai menggunakannya saya dapat menambahkannya jika diperlukan. Saya hanya berusaha untuk mendapatkannya di luar sana untuk saat ini. Terima kasih lagi.
user2698818

3
@ user2698818 Apa yang harus Anda lakukan adalah merancang keamanan, kemudian memposting pertanyaan yang menjelaskannya secara terperinci dan menanyakan 'apakah ini aman (cukup)'. Keamanan yang baik bisa sepenuhnya publik.
Jan Doggen

@ user2698818: ok. Sunting jawaban saya.
Arseni Mourzenko

6
@JanDoggen: baik, apa yang harus lakukan adalah menggunakan yang sudah ada sistem keamanan yang orang lain dirancang dan bertanya "apakah cukup aman". Lebih disukai di mana pertanyaan itu telah berdiri cukup lama dan telah mendapat perhatian dari beberapa ahli di bidang ;-)
Joachim Sauer

12

Jangan menyimpan kata sandi sejak awal! Ikuti contoh Stack Exchange dan biarkan pengguna masuk dengan identitas mereka di situs lain yang menyediakan otentikasi melalui OpenID . Implementasi tersedia secara bebas untuk kerangka kerja web yang paling umum.

Atau mungkin protokol lain. Jika itu adalah proyek in-house untuk beberapa institusi (seperti komentar Anda pada jawaban lain menyarankan), hampir pasti sudah ada LDAP, Kerberos (Windows Active Directory didasarkan pada dua juga; apache mendukung otentikasi HTTP terhadap mereka) atau layanan tersebut untuk login komputer. Hubungkan saja dengan itu.

Ini menyelamatkan Anda dari menyimpan informasi sensitif (Anda kemungkinan besar masih harus menyimpan izin, tetapi tidak terlalu penting) dan para pengguna harus mengingat nama pengguna dan kata sandi lain, sehingga secara keseluruhan menang-menang.


1
Tolong beritahu saya situs apa yang telah Anda buat sehingga saya bisa menghindarinya jika Anda menganggap izin tidak penting keamanan.
orlp

1
Bagaimana jika persyaratannya adalah menyimpan kata sandi. Juga pertanyaan yang secara khusus ditanyakan tentang menyimpannya.
Piotr Kula

3
@ppkinkin: Ada banyak pertanyaan sejenis "bagaimana saya menggunakan X untuk melakukan Y" di mana jawaban terbaik adalah "Anda menggunakan Z". Jika Anda tidak setuju, cukup berikan jawaban yang lebih baik ;-).
Jan Hudec

3
@ppkinkin Untuk menggunakan analogi: "Saya mencoba memecahkan batu dengan tangan saya, sarung tangan apa yang harus saya gunakan?" Periksa apakah mereka mengetahui adanya pahat sebelum menawarkan Gauntlets Kavaleri Jerman ke-19.
deworde

1
Saya akan menghindari terlalu cepat untuk menyarankan OpenID. Ya, ini luar biasa, tetapi umumnya bekerja paling baik jika Anda mendukung beberapa penyedia OpenID / OAuth. Ada banyak forum teknologi, blog, tanya jawab dll. Anda harus masuk melalui penyedia OID Facebook dan tidak bisa menggunakan yang lain. Saya berada di jaringan kerja yang memblokir grosir domain Facebook, jadi saya tidak dapat bekerja dengan situs tersebut. Jika Anda akan mendukung OID, dan hanya akan menggunakannya untuk saat ini, pilih penyedia yang populer di kalangan audiens target Anda, dan tidak mungkin diblokir oleh sysadmin. Google dan Windows Live adalah pilihan yang baik.
KeithS

2

Pepatah:

"Ini aman."

adalah penilaian pribadi yang Anda buat tentang fakta atau proses teknologi tertentu, dan penilaian ini dibatasi oleh apa yang Anda ketahui tentang keamanan pada saat itu. Tetapi bisakah Anda menjamin tanpa keraguan bahwa enkripsi, metode penyimpanan, dll. Anda akan tahan terhadap segala jenis serangan, bahkan yang tidak Anda ketahui, atau belum Anda ketahui?

Artinya: Pernyataan ini dalam bahaya kedaluwarsa, bahkan mungkin tanpa Anda sadari.

Karena itu saya cenderung setuju dengan komentar di atas oleh @ JoachimSauer: Cukup jelaskan apa yang Anda lakukan, bagaimana Anda menyimpan informasi pengguna, dan beri tahu pengguna bagaimana ini seharusnya membuat layanan Anda aman. Kemudian biarkan pengguna menilai sendiri.


Tidak, "Ini aman" bukan "pribadi" atau pernyataan subjektif, tidak seperti "itu cantik", bagi saya . Ini sebenarnya adalah pernyataan kosong secara semantik , tanpa menentukan "dalam kaitannya dengan apa" atau "aman dari serangan apa" atau "pada tingkat apa dalam konteks mana". Jika seluruh pernyataan Anda terdiri dari "ini aman", itu sudah kedaluwarsa sebelum Anda selesai mengetik, dan sangat mungkin Anda tidak menyadarinya. Saya setuju pada bagian terakhir, ini semua tentang detail.
AviD

@AviD: Mungkin Anda terlalu banyak membaca kata-kata pilihan pilihan saya. Ya, mengatakan bahwa sesuatu "aman" tanpa memberikan rincian lebih lanjut tidak ada artinya. Tetapi saya yakin bahwa itu juga penilaian pribadi, karena tidak semua orang memiliki perasaan dan tuntutan yang sama untuk "keamanan": Apa yang A cukup aman merasa tidak aman bagi B. Jadi, mengatakan bahwa sesuatu "aman" menunjukkan bahwa orang yang membuat pernyataan "merasa aman". Dan itu bukan argumen dengan bobot yang sama dengan memberi seseorang fakta yang relevan, dan membiarkan mereka menarik kesimpulan sendiri.
stakx

Benar, "sehubungan dengan apa" yang saya maksudkan untuk persyaratan apa, profil keamanan, risiko, dll. Masih bukan penilaian pribadi, tapi mungkin yang Anda maksud dengan "pribadi" adalah apa yang saya maksudkan dengan "konteks". "Aman" adalah metrik sains yang keras, bukan "perasaan" plin-plan yang lembut. Tapi ya, seperti yang Anda katakan, jangan bilang itu "aman", katakan padaku apa yang Anda lakukan untuk membuatnya begitu.
AviD

@ViD: Oke. Saya tidak akan membahas argumen lebih jauh, kecuali untuk mengatakan bahwa keamanan adalah perasaan plin-plan juga. Tentu saja lebih dari itu, tetapi ketika pertanyaannya adalah tentang "meyakinkan" pengguna (lihat judul pertanyaan), maka perasaan plin-plan adalah yang terpenting pada akhirnya.
stakx

1

Ini benar-benar tergantung pada konteks situs web spesifik Anda.

Misalnya, jika ini adalah situs web konsumen, kemungkinan besar kebanyakan dari mereka hanya akan peduli dengan kata sandi mereka (mungkin), informasi keuangan / kesehatan (tergantung), dan informasi pribadi mereka seperti gambar (hahaha, ya benar ...) .

Jika ini adalah aplikasi bisnis, maka tingkat keamanan seluruh situs relevan, bukan hanya kata sandi. Demikian juga, itu tergantung pada siapa pengguna target Anda - sangat teknis / tidak begitu teknis, dll.

Semua konteks ini sangat menentukan apa yang harus Anda komunikasikan, dan tingkat jaminan apa yang diperlukan.

Misalnya, untuk konsumen non-teknis, cukuplah memiliki komentar umum yang sederhana, seperti:

Situs ini dibangun dengan menggunakan teknik keamanan canggih. Kata sandi Anda selalu dienkripsi, dan kami tidak akan pernah mengirim gambar Anda ke NSA.

(Dan, seperti yang orang lain katakan, Anda lebih baik bahkan tidak memiliki kata sandi sama sekali, gunakan beberapa standar seperti OpenID atau OAuth.)

Untuk bisnis yang sangat teknis, Anda ingin memiliki halaman lengkap detail teknis dan prosedural, seperti:

Kami telah menerapkan SDL penuh (siklus pengembangan aman) selama proses pengembangan dan penerapan kami.
...
Arsitektur keamanan kami adalah ... Ini memberikan manfaat dari ...
Kami memastikan pengkodean yang aman seperti ... oleh ... Kami melakukan ini dan pengujian tersebut.
Kriptografi kami mencakup algoritme ini ... dan ... Kami mematuhi peraturan industri mana pun yang Anda butuhkan, dan disertifikasi untuk ...
Keamanan kami diverifikasi oleh konsultan pihak ketiga yang independen ini.
...
Untuk perincian lebih lanjut, dan untuk meninjau kebijakan kami atau untuk mengatur audit independen, silakan diskusikan dengan departemen pemasaran.

Tentu saja, Anda tidak ingin memberikan terlalu banyak informasi terperinci, itu harus lebih banyak tentang prosesnya daripada kata sandi itu sendiri ... Dan tentu saja harus berjalan tanpa mengatakan bahwa kenyataannya harus benar-benar sesuai dengan apa pun yang Anda tulis di sana , konteks apa pun yang Anda hadapi.

Sebagai salah satu jawaban yang disinggung, sebagian besar pengguna tidak peduli, tidak akan mengerti apa pun yang Anda katakan kepada mereka, dan tetap akan mendaftar, bahkan jika Anda mengatakan bahwa Anda DO mengirim data pengguna ke NSA.
Ini bukan untuk mereka.
Mereka akan sama senangnya tidak memiliki kata sandi, biarkan saya memilih nama pengguna saya dari daftar dan login saya secara otomatis.

Jelas ini adalah untuk persentase kecil yang peduli - Anda harus memungkinkan pengguna cerdas untuk melakukan apa yang benar, memberi mereka informasi yang mereka butuhkan, dan memberi mereka pendidikan yang mungkin mereka minta.
Jika tidak, saat itu salah, 98% lainnya akan tiba-tiba bangun dan marah.
("Tentu, saya tahu bahwa saya tidak perlu kata sandi untuk melihat foto-foto saya, tetapi saya tidak berpikir bahwa orang lain juga bisa melihatnya !!")


0

Jika Anda ingin sistem Anda aman, kekuatan algoritme kata sandi tidak ada artinya - sebagian besar peretas dapat memecahkan kata sandi dalam waktu singkat, terutama jika kata sandi yang dipilih kecil atau terdiri dari kata-kata umum yang telah "diretas dan disimpan oleh peretas "Gunakan tabel pelangi dan sejenisnya. Baca artikel ArsTechnica tentang peretas kata sandi untuk banyak wawasan.

Yang perlu Anda lakukan adalah meyakinkan pengguna bahwa orang jahat tidak bisa mendapatkan hash mereka sejak awal. Satu perusahaan yang sadar akan keamanan tempat saya bekerja memiliki sistem web 3 tingkat di mana server web secara fisik tidak terhubung ke server database. Ketika bos saya ingin meletakkan situs webnya dan memiliki akses langsung ke DB (kode yang dirancang dengan buruk, 'kata Nuff) dia diberitahu bahwa dia tidak bisa memilikinya, dan ketika dia mendorong ... diberitahu bahwa tidak ada kabel di antara mereka . Dia harus mendesainnya sehingga melewati semua permintaan data melalui layanan tingkat menengah. Dan layanan-layanan itu tidak hanya diamankan, tetapi mengekspos permukaan minimal untuk diserang, dan dikunci. Dan DB tidak pernah mengekspos salah satu tabelnya untuk membaca, hanya prosedur tersimpan yang pada gilirannya dikunci sehingga hanya layanan terkait yang memiliki akses.

Itu tidak seburuk kode untuk seperti yang Anda pikirkan, setelah Anda tahu arsitektur dan pemisahan setiap tingkatan, itu cukup mudah untuk dikodekan.


0

Anda dapat mengembangkan situs paling aman di planet ini dan memiliki pengalaman pengguna yang sangat buruk. Pengguna akan menganggap bahwa situs Anda tidak aman.

Anda dapat membangun situs yang paling tidak aman di planet ini dan memiliki pengalaman pengguna yang luar biasa. Pengguna akan menganggap bahwa situs Anda aman. Setidaknya sampai muncul berita malam.

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.