Apa yang akan Anda lakukan jika Anda menyadari penyedia hosting email Anda dapat melihat kata sandi Anda?

31

Kami menerima email tahun lalu dari penyedia hosting kami mengenai salah satu akun kami - itu telah dikompromikan dan digunakan untuk mengirimkan bantuan spam yang agak murah hati.

Rupanya, pengguna telah menyetel ulang kata sandinya ke variasi namanya (nama belakang adalah sesuatu yang mungkin bisa Anda tebak pertama kali.) Ia segera diretas dalam waktu satu minggu - akunnya mengirimkan banjir 270.000 email spam - dan sangat cepat diblokir.

Sejauh ini, tidak ada yang luar biasa. Yang terjadi. Anda mengubah kata sandi Anda menjadi sesuatu yang lebih aman, mendidik pengguna dan melanjutkan.

Namun, sesuatu yang menyangkut saya bahkan lebih daripada fakta salah satu rekening kami telah dikompromikan.

Penyedia hosting kami, dalam upaya membantu, sebenarnya mengutip kata sandi kepada kami dalam email berikut:

masukkan deskripsi gambar di sini

Saya heran. Kami akan segera memperbarui kontrak kami - dan ini terasa seperti dealbreaker.

Seberapa umum penyedia hosting dapat mengetahui kata sandi yang sebenarnya digunakan pada akun?

Apakah kebanyakan penyedia layanan hosting memiliki departemen penyalahgunaan account yang memiliki akses lebih dari repetisi garis depan (dan dapat mencari password jika perlu), atau orang-orang hanya tidak mengikuti praktek terbaik dalam sehingga memungkinkan bagi setiap staf mereka untuk akses pengguna kata sandi? Saya pikir kata sandi seharusnya hash dan tidak bisa diambil? Apakah ini berarti mereka menyimpan kata sandi semua orang dalam teks biasa?

Apakah legal bagi penyedia hosting untuk dapat menemukan kata sandi akun dengan cara ini? Sepertinya sangat luar biasa bagi saya.

Sebelum kita melihat perubahan penyedia, saya ingin diyakinkan bahwa ini bukan praktik umum, dan bahwa penyedia hosting kami berikutnya juga tidak mungkin mengatur semuanya dengan cara yang sama.

Berharap untuk mendengar pandangan Anda tentang ini.

security email password best-practices Kekuatan Austin '' Bahaya ''
sumber
4
Meskipun jelas sangat memprihatinkan, untuk semua yang Anda tahu ini adalah pukulan satu-dua dari perwakilan telepon yang merekam kata sandi baru dalam tiket (yang seharusnya tidak pernah mereka lakukan) dan perwakilan lain melihatnya di catatan tiket. Anda berada dalam hak Anda untuk menuntut jawaban, tetapi seperti berdiri Anda tidak tahu bagaimana password itu diambil.
Andrew B
1
Saya tahu pasti bahwa pengguna mengatur kata sandi melalui antarmuka web. Mereka menariknya dari catatan di server - tidak ada seorang pun di kantor telah berbicara kepada mereka tentang hal itu di telepon (selain itu, saya percaya penyedia ini memiliki dukungan email saja)
Austin '' Bahaya '' Powers
3
Apa yang akan saya lakukan? Mengangkat bahu. Apa pun yang Anda lakukan pada sistem yang dikendalikan oleh orang lain dapat dilihat oleh mereka. Jika Anda tidak ingin orang lain memiliki visibilitas ini ke sistem email Anda, jalankan dan host sendiri. Anda mungkin tidak menyetujui apa yang mereka lakukan dengan informasi yang mereka miliki, tetapi jika tidak ada kewajiban kontrak pada mereka untuk tidak melakukannya, yah, Anda menandatangani kontrak.
MadHatter mendukung Monica
19
Penyimpanan kata sandi plaintext buruk (seperti Time to find a new providerburuk!) - banyak orang yang melakukannya tetapi tetap saja: BURUK. Namun, mengirimkan kata sandi dalam email yang tidak terenkripsi ? SEMUA UANG SAYA . Itu menunjukkan pengabaian kasual untuk keamanan. Lari, jangan berjalan, ke penyedia baru dengan akal sehat ...
voretaq7
2
Saya ingin memperluas apa yang dikatakan @MadHatter: Banyak orang di sini berfokus pada gagasan "menyimpan kata sandi plaintext". Fakta sederhananya adalah bahwa jika saya menjalankan server POP / IMAP, server SSH, atau apa pun yang Anda gunakan untuk mengetikkan kata sandi, itu dapat dikonfigurasikan untuk mencatat kata sandi tersebut saat Anda mengetikkannya , terlepas dari apakah atau tidak Saya menyimpan barang-barang hash atau dalam teks yang jelas. Google dapat melihat kata sandi Anda dan Dropbox dapat melihat kata sandi Anda dan Facebook dapat melihat kata sandi Anda dan sebagainya. Anda bisa mempercayai penyedia Anda atau meng-host-nya sendiri.
larsks

Jawaban:

33

Ya, sudah biasa bagi ISP dan penyedia layanan email untuk menyimpan kata sandi Anda dalam teks biasa, atau format yang mudah dipulihkan ke teks biasa.

Alasannya berkaitan dengan protokol otentikasi yang digunakan dengan PPP (dialup dan DSL), RADIUS (dialup, 802.1x, dll.) Dan POP (email), antara lain.

Tradeoff di sini adalah bahwa jika kata sandi hash satu arah dalam database ISP, maka satu-satunya protokol otentikasi yang dapat digunakan adalah mereka yang mengirimkan kata sandi melalui kawat dalam teks biasa. Tetapi jika ISP menyimpan kata sandi yang sebenarnya, maka protokol otentikasi yang lebih aman dapat digunakan.

Misalnya otentikasi PPP atau RADIUS mungkin menggunakan CHAP, yang mengamankan data otentikasi dalam perjalanan, tetapi memerlukan kata sandi teks biasa untuk disimpan oleh ISP. Demikian pula dengan ekstensi APOP ke POP3.

Selain itu, semua berbagai layanan yang ditawarkan ISP semuanya menggunakan protokol yang berbeda, dan satu-satunya cara bersih untuk mengotentikasi semuanya ke database yang sama adalah dengan menyimpan kata sandi dalam teks biasa.

Ini tidak membahas masalah siapa di antara staf ISP yang memiliki akses ke database , dan seberapa baik itu diamankan . Anda masih harus mengajukan pertanyaan sulit tentang itu.

Seperti yang mungkin sudah Anda pelajari sekarang, hampir tidak pernah terjadi gangguan terhadap basis data ISP, sementara itu terlalu umum bagi pengguna individu untuk dikompromikan. Anda juga berisiko.

Lihat juga Apakah saya salah mempercayai bahwa kata sandi tidak boleh dipulihkan (hash satu arah)? di situs saudara kita Keamanan TI

Michael Hampton
sumber
2
Cukup banyak protokol mati APOP, dan MSCHAPv2 tidak perlu server untuk mengetahui kata sandi secara jelas - Saya tidak benar-benar berpikir ada banyak alasan bagi penyedia layanan untuk menjaga kata sandi yang jelas saat ini.
Shane Madden
1
@ShaneMadden Anda benar; ini adalah CHAP, bukan MSCHAP. Dan ya protokol-protokol ini hampir mati, tetapi penyedia layanan yang telah ada selamanya mungkin masih menggunakannya untuk layanan warisan.
Michael Hampton
Ya - walaupun saya ingin berpikir bahwa lebih dari penyedia layanan lawas memiliki LDAP tua yang penuh dengan {crypt}kata sandi yang tidak bersih (pendekatan yang diambil oleh orang-orang yang pernah saya lihat di balik layar di masa lalu) ). Padahal itu mungkin hanya angan-angan.
Shane Madden
1
Catatan kriptografi wajib, "tradeoff di sini adalah bahwa jika kata sandi hash satu arah dalam database ISP, maka satu-satunya protokol otentikasi yang dapat digunakan adalah mereka yang mengirimkan kata sandi melalui kawat dalam teks biasa. Tetapi jika ISP menyimpan kata sandi yang sebenarnya, maka protokol otentikasi yang lebih aman dapat digunakan. " umumnya tidak benar. Itu hanya benar karena tidak ada protokol yang memungkinkan skema otentikasi aman dengan kata sandi hash.
orlp
1
@nightcracker dibandingkan dengan jumlah data apa pun yang akan Anda transfer (dienkripsi juga, saya harap) sejumlah kecil data otentikasi seharusnya tidak terlalu mengganggu Anda
Tobias Kienzler
12

Ini, sayangnya, cukup umum dengan host anggaran dan tidak pernah terdengar bahkan dengan host yang lebih besar. Hal-hal seperti cpanel sering membutuhkan kata sandi teks biasa untuk dapat masuk ke berbagai layanan seperti Anda, dll.

Satu-satunya hal yang dapat Anda lakukan adalah menanyakan di muka jika kata sandi di-hash.

leher panjang
sumber
28
Itu adalah tuan rumah dengan anggaran yang sangat rendah ... Saya tahu itu terlalu bagus untuk menjadi kenyataan. Ini membuatku gila. Ngomong-ngomong, terima kasih sudah menjagamu dengan sebuah jawaban. Pada awalnya saya pikir itu sulit, tetapi Anda naik ke kesempatan itu. Jawaban seperti ini membantu situs ini untuk mencapai ketinggian baru. Saya berpikir untuk menandai ini sebagai jawaban terbaik, tapi itu leher dan leher.
Austin '' Bahaya '' Powers
7

Mereka kemungkinan menyimpan kata sandi dalam teks biasa atau menggunakan semacam enkripsi yang dapat dibalik.

Seperti yang Anda duga, ini sangat buruk.

Entah karena kejahatan atau kelalaian karyawan, atau kompromi sistem mereka oleh pihak luar, kata sandi teks biasa yang disalahgunakan menimbulkan risiko serius - tidak hanya untuk sistem mereka, tetapi untuk sistem lain orang mungkin menggunakan kata sandi yang sama.

Penyimpanan kata sandi yang bertanggung jawab berarti penggunaan fungsi hashing satu arah alih-alih enkripsi yang dapat dibalik, dengan garam (data acak) ditambahkan ke input pengguna untuk mencegah penggunaan tabel pelangi .

Jika saya berada di posisi Anda, saya akan menanyakan kepada penyedia beberapa pertanyaan sulit tentang bagaimana, tepatnya, mereka menyimpan kata sandi, dan bagaimana, tepatnya, perwakilan dukungan mereka dapat mengambil kata sandi. Ini mungkin tidak berarti mereka menyimpan kata sandi dalam teks biasa, tetapi mungkin mereka mencatatnya di suatu tempat ketika diubah - juga risiko yang sangat besar.

Shane Madden
sumber
1
Saya akan mengajukan beberapa pertanyaan kepada mereka dan mengirim kembali ke sini jika mereka mengatakan sesuatu yang menarik. Kekhawatiran terbesar saya adalah mereka berpotensi 1) membaca email kami 2) dalam membaca email kami, melihat referensi ke akun email pribadi 3) jika pengguna menggunakan kata sandi yang sama untuk pekerjaan dan email pribadi, maka email pribadi mereka dapat dikompromikan juga.
Austin '' Bahaya '' Powers
@ Austin''Danger''Powers "berpotensi 1) membaca email kami " Setiap host dapat melakukan ini - tidak ada pengecualian (dengan asumsi konten email itu sendiri tidak dienkripsi oleh pengirim - tapi itu cerita yang berbeda).
orlp
Saya pikir itu biasanya hanya mungkin untuk dukungan tingkat atas. Jika melihat password adalah sesuatu setiap repetisi dukungan mereka bisa lakukan, maka risiko yang tidak jujur / bosan menyembul karyawan melalui email kami meningkat.
Austin '' Bahaya '' Powers
5

Semua jawaban lainnya bagus dan memiliki poin sejarah yang sangat bagus.

Namun, kita hidup di zaman di mana menyimpan kata sandi dalam teks biasa menyebabkan masalah keuangan yang sangat besar dan dapat menghancurkan bisnis. Mengirim kata sandi dalam teks biasa melalui email yang tidak aman juga terdengar konyol di zaman NSA menyedot semua data yang lewat.

Anda tidak harus menerima kenyataan bahwa beberapa protokol lama memerlukan kata sandi dalam teks biasa. Jika kita semua berhenti menerima layanan seperti itu, mungkin penyedia layanan akan melakukan sesuatu tentang hal itu dan akhirnya mencabut teknologi kuno.

Beberapa orang dapat mengingat bahwa suatu ketika ketika Anda ingin naik pesawat untuk terbang ke negara lain, Anda benar-benar hanya akan masuk ke pesawat dari jalan parkir. Tidak ada keamanan apa pun. Saat ini, orang-orang menyadari bahwa langkah-langkah keamanan yang tepat diperlukan dan semua bandara telah menerapkannya.

Saya akan beralih ke penyedia email lain. Pencarian di "penyedia email aman" menghasilkan banyak hasil.

Ada beberapa poin bagus di komentar. Mungkin mencari "penyedia email aman" akan masuk akal karena semua penyedia email akan membual bahwa mereka aman. Namun, saya tidak dapat merekomendasikan perusahaan tertentu dan mungkin juga bukan ide yang baik untuk melakukannya. Jika Anda mengidentifikasi perusahaan tertentu yang menanyakan pertanyaan sulit tentang keamanan terlebih dahulu adalah hal yang baik untuk dilakukan.

oleksii
sumber
1
Salah satu alasan webmaster terakhir kami merekomendasikan penyedia ini adalah karena itu seharusnya "lebih aman" dari yang sebelumnya. Saya segera menemukan bahwa mereka tidak akan membiarkan karakter khusus tertentu dalam password yang kita digunakan untuk dapat digunakan, maka kemudian bahwa staf mereka memiliki akses ke password kita. Satu-satunya alasan mereka "lebih aman" adalah karena mereka memaksa kita untuk memenuhi persyaratan panjang / kompleksitas kata sandi minimum - masalah besar.
Austin '' Bahaya '' Powers
Semua orang menyebut layanan mereka "aman", tetapi ternyata itu tidak selalu berarti apa yang Anda pikirkan. Sistem seharusnya membuatnya tidak mungkin. Saya bekerja untuk ISP bertahun-tahun yang lalu, dan meskipun saya bisa mengatur ulang kata sandi email pelanggan, saya tidak punya cara untuk melihat apa yang sekarang. Orang-orang ini secara teoritis bisa membaca email kami tanpa sepengetahuan kami ... Saya tidak harus bergantung pada kepercayaan .
Austin '' Bahaya '' Powers
1
Apakah mereka memberlakukan persyaratan panjang maksimum ? Itu hampir selalu kenari untuk penyimpanan kata sandi plaintext.
Mels
1
"Cari di" penyedia email aman "menghasilkan banyak hasil." - ya dan berapa banyak situs yang menyimpan kata sandi dalam teks biasa akan muncul di bawah hasil tersebut karena mereka yakin diri mereka aman. Jangan memilih hosting untuk layanan yang ingin Anda amankan berdasarkan beberapa hasil pencarian.
Rob Moir
1
@RobM: Tepat. Apa gunanya bertanya pada penyedia jika mereka yakin layanan mereka sendiri aman? 100% dari mereka akan mengatakan "ya". Melakukan pencarian web untuk istilah umum seperti itu adalah buang-buang waktu saja. Tampaknya cara yang agak naif untuk mendekati seluruh masalah sebenarnya: " Apakah sistem Anda aman? Ok, fantastis. Terima kasih telah menjelaskannya. Dalam hal ini kami akan berlangganan layanan Anda tanpa ragu-ragu. "
Powers 'Bahaya' Austin
3

Rekomendasi saya adalah pergi, dan bertanya kepada orang-orang berikutnya apa kebijakan mereka terlebih dahulu!
Jika Anda merasa baik, Anda bisa memberi tahu penyedia lama mengapa Anda pergi.

Juga untuk menjawab pernyataan jawaban lain, hari-hari tabel pelangi telah berlalu. Mereka telah digantikan oleh GPU berdaya tinggi dan mengambil terlalu banyak ruang penyimpanan (hash biner jelas tidak kompres dengan baik; dan Anda tidak akan menyimpannya di ASCII). Lebih cepat untuk (menghitung ulang) hash pada GPU daripada membacanya dari disk.

Bergantung pada algoritma hash yang digunakan dan GPU, komputer peretas kata sandi modern dapat diharapkan untuk menghasilkan sekitar 100 juta hingga satu miliar hash per detik. Menurut ini , (yang agak ketinggalan zaman tentang apa yang menurutnya bisa dilakukan oleh komputer / superkomputer), itu berarti kata sandi 6-char dapat di-crack dalam hitungan detik. Tabel untuk hash char 7 & 8 di semua berbagai algoritme (MD5, SHA-1, SHA-256, SHA-512, Blowfish, dll.) Akan mengkonsumsi ruang disk yang banyak sekali (sadari bahwa Anda perlu menyimpannya di SSD , bukan piring magnet, untuk kecepatan akses) dan Anda dapat melihat mengapa serangan berbasis kamus menggunakan GPU akan menghasilkan kata sandi lebih cepat.

Artikel bagus untuk mereka yang datang ke tempat kejadian adalah Bagaimana saya menjadi seorang cracker kata sandi di Ars Technica.

Nicholas Shanks
sumber
Jika paragraf kedua Anda benar, itu artinya pengasinan menjadi tidak berguna. Apakah ini pendapat pribadi Anda atau berdasarkan fakta?
Tobias Kienzler
@TobiasKienzler Memang, salting menggunakan nilai yang disimpan dalam output dianggap sangat tidak berguna, tetapi salting menggunakan nilai pribadi tetap menjadi pertahanan yang layak terhadap serangan kamus. Ini bukan pendapat pribadi saya, ini adalah pengamatan (dibuat oleh orang lain) tentang perilaku cracker kata sandi saat ini. Saya juga memperbarui sedikit jawabannya.
Nicholas Shanks
2
Dengan nilai pribadi maksud Anda pepper ? Pokoknya, sifat-sifat yang diperlukan dari fungsi hashing yang baik adalah a) mereka sangat memakan waktu, atau bahkan lebih baik b) mereka dapat diterapkan secara berantai dalam jumlah besar secara sewenang-wenang untuk meningkatkan waktu yang dibutuhkan. Jadi, sementara saya setuju bahwa hash / garam yang ketinggalan jaman bisa dipecahkan, yang dengan kompleksitas yang cukup meningkat tidak. Terkait: Kata Sandi Hashing, tambahkan garam + lada atau cukup garam?
Tobias Kienzler
@TobiasKienzler Ya, saya tidak yakin seberapa spesifik saya bisa bersamamu :) Namun, jelas, situs-situs tersebut harus menggunakan bcrypt()hari ini, tapi ini lebih lanjut tentang memecahkan hash dari yang tidak.
Nicholas Shanks
1
Nah dalam kasus itu saya setuju, tetapi hash buruk / usang / lemah (misalnya MD5) hanya bisa dimaafkan dalam konteks keamanan yang relevan.
Tobias Kienzler
1

Ini Terjadi pada Saya!

Beberapa tahun yang lalu identitas saya dikompromikan ketika penyedia hosting saya (yang juga penyedia email saya saat itu) mengalami pelanggaran keamanan. Saya terbangun karena tidak dapat memeriksa email saya karena kata sandi saya telah disetel ulang. Dengan kontrol email saya, mereka berusaha mengatur ulang kata sandi saya di Amazon dan PayPal. Anda bisa menebak apa yang terjadi selanjutnya, bukan? Biaya kartu kredit palsu!

Untungnya saya dapat mengetahui apa yang terjadi relatif cepat, menghubungi penyedia hosting saya di telepon, dan dengan susah payah memvalidasi identitas saya meskipun informasi akun dan pertanyaan keamanan sedang diubah (semua dalam rentang beberapa jam). Selama percakapan ini, perwakilan layanan pelanggan dapat memberi tahu saya sejarah kata sandi saya, ketika telah diubah, dan untuk apa. Hanya itu yang perlu saya dengar untuk mengetahui bahwa saya benar-benar perlu mengganti penyedia layanan.

Tidak Ada Alasan Seharusnya Terjadi Pada Anda, Perusahaan Anda!

Saya curiga tentang ketelitian perusahaan ini dalam hal keamanan, hal-hal yang saya perhatikan di sana-sini selama bertahun-tahun berurusan dengan mereka. Tetapi saya selalu meyakinkan diri saya bahwa itu bukan masalah besar atau mungkin saya salah. Saya tidak salah, dan Anda juga tidak!

Jika saya bertindak ketika saya pertama kali curiga mereka tidak menganggap serius keamanan bahwa mini-nightmare tidak akan pernah terjadi. Memikirkan apa yang bisa terjadi jika akun perusahaan yang berharga dikompromikan? Anda akan turun dengan mudah jika mereka hanya mengirim SPAM. Perusahaan tempat saya bekerja saat itu juga menggunakan penyedia ini dan kami menjadikannya prioritas kami untuk beralih secepat mungkin.

Percaya dengan nalurimu! Jangan menyerah pada migrasi karena kemalasan atau karena pengaturan yang ada "berfungsi dengan baik". Bagian yang paling memberatkan dari pengawasan keamanan yang menggantung rendah seperti menyimpan kata sandi dalam teks yang jelas, mengkonfigurasi server tidak benar, dll adalah bahwa mereka berbicara dengan ketidakmampuan umum dan / atau kemalasan dalam budaya teknis mereka, dan itu adalah budaya yang saya tidak ingin misi perusahaan saya sangat penting kontrak layanan di dekat.

Matt Surabian
sumber
0

Saya dapat melihat penjelasan alternatif, di mana kata sandi Anda sebenarnya di-hash di server penyedia Anda.

Ketika penyedia menghubungi Anda hanya sehari setelahnya, ia mungkin (dan ini adalah perkiraan) menariknya dari log server karena skrip pengubah kata sandinya mengirimkan data melalui metode GET.

Kedengarannya lebih sederhana daripada penyedia Anda memiliki basis data yang penuh dengan catatan kapan, siapa dan bagaimana mengubah kata sandinya. Anda tahu pisau cukur Occam ...;)

Peta Sittek
sumber