Müşterinin şifre alma yeteneğine ihtiyacı varsa ne yapmalıyım?

Şu anda işyerinde bir uygulamayı devraldım ve dehşete kapılıyorum, veritabanında saklanan kullanıcı şifrelerinin kurum içi şifreleme işlevi kullanılarak şifrelendiğini ve bu şifrelerin çözülmesini de sağlayabildiğimi fark ettim.

Bu yüzden gerçekten yapılması gereken tek şey kullanıcı tablosunu kopyalamak ve şifreleme derlemesini kopyalamak (veritabanı üretim erişimine sahip olan herkes) ve sonra onlar için 100.000 e-posta adresine ve potansiyel şifreye erişebileceklerdir.

İşe neden bunun iyi bir fikir olmadığını açıklamaya çalışıyorum, ancak güvenlik kavramları teknik olarak düşünülmemiş oldukları için başlarının üzerinden geçiyor gibi görünüyor (hükümet için geçerli). Ayrıca, uygulama içinde yönetici kullanıcılarının, kendileri ile giriş yapmak ve bir şeyler yapmak için kullanıcının istediği şifreleri almaları için (kendilerinin dediği gibi) yapmaları için aslında mevcut işlevsellik vardır.

Bu yüzden güvenlik etkilerini anlamıyorlar. Ve daha güçlü bir güvenlik politikası uygulamak için (şifreleri toplamak kolay elde edilememeleri için), onlar için mevcut işlevleri kaldırmam gerekiyor.

Ne yapmalıyım? Şifre sistemini ilk başta oluşturmadım, bu yüzden eğer bir şeyler ters giderse suçlanmam mümkün olmaz. Öte yandan, kendimi iyi hissetmiyorum ve ayrıca 100.000 potansiyel e-posta oturumuna erişmek istemiyorum.

İhtiyaç duydukları işlevselliği güvenli bir şekilde uygulayın. Başka bir kullanıcı olarak giriş yapan yöneticiler, kullanıcının şifresini bilmeden uygulanabilir. Kendileri olarak giriş yapabilirler ve sonra bazı 'kimlik değiştirme' fonksiyonlarını kullanabilirler.

Bir şifre veri tabanını korumak bir iş meselesi değil, teknik bir meseledir. Bunu yapmamak bir hatadır. Eğer işletme güvenliği bir işlevsellik kazası olarak düşünüyorsa, güvenlik kaybedecektir. Onlara bu şekilde düşünmeleri için hiçbir sebep vermemelisiniz.

Sen gerçekten emin onları ikna etmek gerek değil onların sunucu ayrılır durumunda medeni sorumlu olması gerekir. Ne de ihmal ettiklerini anlayan bilgili bir kullanıcı tabanındaki boşluklara da ihtiyaç duymuyorlar.

Bazen bir tarafın yanlış olduğu, diğerinin haklı olduğu kesin durumlar vardır. Bu o zamanlardan biri.

Sony’ye yeni neler olduğuna bakın. Ayrıca, sitemiz yakın zamanda saldırıya uğradı ve onun inatçı olmayan bir felaket olmasını engelleyen şeylerden biri (nispeten) iyi bir tek yönlü karma işlevi (SHA512) kullanmamızdı. O zamandan beri kaba kuvvet / sözlük saldırılarını bile engellemek için (veya en azından onları yenilmez hale getirmek için) bcrypt'e geçtik. Ben basit bir şey bulmuyorum.

Bilgi: İnsanlar aynı şifreyi birçok sitede kullanıyor.

Patronunuz muhtemelen insanların her tür hizmet için (bankacılık veya Facebook ve benzeri) tek bir şifre (veya çok sınırlı bir dizi) kullandıklarının farkında değildir. Sisteminizde kullanıcılar parolalarını değiştirebiliyorsa, büyük olasılıkla başka bir yerle aynı parolayı kullanmaları muhtemeldir.

Patronunuz bu şifre erişiminin bir problem olmadığını düşünüyorsa, onlara bu gerçeği söylemelisiniz ve belki de farklı düşünmeye başlayacaklardır. Uygulamanız duvarın arkasında olsa ve herkese açık olmasa bile, diğer çevrimiçi servislerde güvenlik tehdidi oluşturabilir. Kullanıcı adları (özellikle e-posta olduğunda) tahmin etmek oldukça kolaydır. Patronun Facebook hesabına giriş yapmanın ve duvarlarına bir şey koymanın ne kadar komik olduğunu hayal edemiyorum.

Kullanıcı şifreleri, her zaman yalnızca sınırlı sayıda insanın erişebileceği en üst düzey gizlilik / gizli bilgiler olarak değerlendirilmelidir. Bu tür geçici bilgileri saklamaktan kaçınmak en iyisidir. Ve bunu yaptığınızda bile, bu bilgilere her bir erişim hakkınız vardır. Sadece birden fazla anahtarla açılabilen yüksek güvenlikli bir kasadan gizli bir kağıt almak gibi. Böylece insanlar kimin ve ne zaman erişebileceğini bilirler.

Hesap temsilcisi nasıl uygulanır?

Başvurunuzdaki hesap yetkilendirmesi farklı yapılmalıdır.

1. Yöneticiler kendileri gibi giriş yapmalı ve sonra
2. ya (ayrıcalıklı kullanıcı olduklarından)
   • sadece KullanıcıAdı veya
   • Giriş yapmak için listeden belirli bir kullanıcıyı seçin.

Kesinlikle UserName + Password kombinasyonuyla giriş yaparak yapılmamalıdır .

Yetkilendirilmiş oturum açmaya izin verecek şekilde yeni ekranın geliştirilmesi gerektiği doğru, ancak yine de doğru.

Yetkilendirilmiş oturum açma neden daha iyi?

Yönetici tarafından bazı işlemlerin bir kullanıcı adına yapıldığını açıkça belirten ek işlevsellik sağlayabilirsiniz (bu, şu anda bilemeyeceğiniz için, çünkü yöneticiler Tanrılar gibi davranırlar ve her kim ve giriş yapabilecek şeyler yapıyorlarsa) gerçek çalışan itibarı).

İnsanların hatalar yaptığını kabul etmek zorundasın. Yöneticiler de insandır. Ve eğer başkası adına bir hata yaparlarsa, onları suçlamaya çalışacaklar. Bundan% 100 eminim. Bu, yönetici olmayan kullanıcılar için daha güvenli hale getirecek, böylece gerçek dünyadaki saygınlığı diğer insanların hatalarından zarar görmeyecek.

Uygulamanın ne yaptığını söylemiyorsun. Pasaport uygulamaları ise, korunması gereken kimlik hırsızlığı bilgileri ile dolu ise, maksimum korumayı hak ediyor. Ancak "evdeki yolumdaki trafik kazalarını söyle" ise, şifre ihlalinin sonuçları nelerdir? Yazdığım bazı sistemlerin şifreleri bile yok - yalnızca e-postanızı veya öğrenci numaranızı veya insanların birbirleri hakkında sıkça bildiği başka bir tanımlayıcıyı girersiniz ve sistemin sahipleri kullanım kolaylığı ve kilitli olmamaya değer verir insanlar birbirlerini kimliğe bürünürse olası gizlilik ihlali nedeniyle ortaya çıktı. Ben de bununla bir sorunum yok. Örneğin bir konferansta tercih edilen oturumlar programımı ayarlamak için neden bir şifreye ihtiyacım var?

Eğer kod incelemesi için buraya getirilseydim ve bunu bana sen yükselttiyseniz, başlayacağımız yer orasıydı. Neyi koruyorsun? Bir kişinin diğer bir kişi olarak giriş yapmayı başarabilmesinin olumsuz sonuçları nelerdir? Herkesin sakladığı verilerin açığa çıkmasının olumsuz sonuçları nelerdir? Belki de korkunçlar. Benim için onları listelerdin. Öyleyse, insanların "parolamı bana e-postayla gönder" seçeneğine tıklayamamasının yerine "şifremi sıfırla" yı tıklatmanın sonuçları nelerdir? Siteyi kullanmayı bırakırlar mı? Peki ya kişi olarak giriş yapan personel? Bu zamandan tasarruf, para, kayıp satış mı yoksa ne?

Maliyet / fayda öyküsünün son parçası ve yalnızca şu anda maruz kaldığınız negatiflerle işlevsellik kaldırdığınızda alacağınız negatifler arasında gerçekten büyük bir fark varsa elde edebileceğiniz bir şey, düzeltmenin maliyetidir. Bin dolarlık maruz kalma şansını almak için bir milyonu harcar mıyım? Hayır. Diğer yoldan ne haber? Şansa bağlı, sanırım, ama ilk cevabım evet olurdu.

ps - Kanada hükümeti, URL’de kimlikleri olan bir pasaport başvurusu sitesi ile canlı yayın yaptı: URL’yi farklı bir kimlikle düzenlerseniz, rastgele diğer bazı vatandaşların yarı doldurulmuş halini gördünüz. Ve müşteri hizmetleri için müşterileri olarak giriş yapan ve genel mutluluğu amaçlayan müşterilerim var, bu yüzden şifrenin ardındaki veriler gerçekten yabancılar için önemliyse buna katlanmam.

Yasaya aykırı olabilir ve onları dava açmaya açabilir. Kullanıcıyla ilgili herhangi bir kişisel bilgiyi elinde bulunduruyorlarsa veya sistem, kullanıcı olarak diğer sistemlerle etkileşime giriyorsa, sistemin herhangi bir Devlet veya Federal Gizlilik Yasalarına veya yasalarına uyup uymadığını kontrol etmeniz gerekebilir. yani. Sarbanes / Oxley, California OOPA vb.

Potansiyel yasal sorunların yanı sıra, herhangi bir yöneticinin istediği zaman tüm tabloyu taşınabilir bir veri çubuğuna bırakabileceğini ve herhangi bir kullanıcı olarak giriş yapıp tahribata yol açabileceğini veya verileri satabileceğini belirtebilirsiniz.

Tüm yöneticilerin güvenilir olduğunu varsaysanız bile, yönetici şifresinin güvenliğini bozar.

Ayrıca işlemleri kendileri yapmak için bir kullanıcının şifresine de ihtiyacınız yoktur. Bir sudobenzeri özelliği uygulayabilirsiniz .

FIPS ve FISMA gereklilikleri parolalar için geri dönüşümlü şifrelemeyi yasaklayacağından ve ana departman onları aya indireceğinden federal bir hükümet sistemi olamaz.

Ve daha güçlü bir güvenlik politikası uygulamak için (şifreleri toplamak kolay elde edilememeleri için), onlar için mevcut işlevleri kaldırmam gerekiyor.

Önceki şirketim için, bu sorunu aşmak için parola sıfırlama e-postaları gönderme yeteneği için mücadele ettim. Ve reddedilmeye devam ettim. Sonunda gelgit karşısında kaka kürek sıkıldım, o yüzden ayrıldım. Bu aynı zamanda bazı banka web sitelerinin sorduğu aptalca soruların "2 faktörlü kimlik doğrulama" olarak sayıldığını düşünen sivri saçlı bir patrondu. Onunla tartışmak bir Dilbert karikatürü gibiydi (PHB gibi şekillendirilmişti).

Ayrıca, uygulama içinde yönetici kullanıcılarının, kendileri ile giriş yapmak ve bir şeyler yapmak için kullanıcının istediği şifreleri almaları için (kendilerinin dediği gibi) yapmaları için aslında mevcut işlevsellik vardır.

Bunun bir finans kurumunda uygulandığını gördüm. Müşteri destek alanındaki insanlar kendi kimlik bilgileriyle giriş yaparlar ve eğer bunu yapma hakları varsa müşteri olarak giriş yapmış gibi davranırlar. Bu, onları müşteri olarak oturum açmadı, müşteriyi kimliğine büründü . Bu şekilde, müşteri hizmetleri temsilcisi para çekmeye karar verdiyse, müşterinin günlüklerinde yaptığı gibi göstermez: Müşteri hizmetleri temsilcisinin bunu yapmaya çalıştığını gösterir (en kısa sürede kovulması için bir uyarı gönderir) rentacop katlarına yapabilirdi).

Kötü bir şekilde yapıldığında, müşteri destek personelinin, son kullanıcının ciddi finansal veya yasal yükümlülüklerle sonuçlanabilecek bir faaliyette bulunduğunu göstermesini sağlar.

En son çalıştığım federal web sitesi, son kullanıcılardan (yaklaşık 400 kullanıcı bulunan) yılda 1/4 milyar ABD doları topladı, bu nedenle kayıt işlemlerinin çok sıkı olması gerekiyordu ve yalnızca yetkili son kullanıcının dokunmasına izin verildi tüketim vergisi ödedikleri malları bildirdikleri web sayfaları.

Sony, en son güvenlik ihlali şirketlerinden biriydi. Sadece PS3 ağı değildi, aynı zamanda 25.000.000'den fazla isim, adres, kredi kartı numarası, kullanıcı adı ve şifreyi aşan toplamda MMORPG oyunları ağıydı. Hiç mutlu olmadığıma inanabilirsiniz (zaman dilimini istiyorum!).

Bunun gibi konularda Yazılım Mühendisliği Etik Kurallarına atıfta bulunuyorum . Benim yorumum, ilk önceliğiniz kamu çıkarını baltalamak değil ( buradaki gibi daha güvenli bir şekilde şifrelenmiş bir şifre olması durumunda değil) bir şirket Dell kiralama şirketi bunları bilmeden onların ev sahipleri casusluk diye dizüstü bilgisayarlar değiştirilmiş). Bundan sonra sorumluluğunuz müşterinize potansiyel riskleri bildirmek ve göz önünde bulundurmalarını sağlamaktır. Tabii ki asgari temel. Bunu, hala beklediğinizden ve izin verdiğinizden daha fazla hissettiğinize dair kendi kararınızı kullanmalısınız.

Tabii ki bir hükümet projesinden bahsettiğinizde, vatandaşların özel bilgileri bu uygulamalar nedeniyle risk altındaysa, o zaman kamu yararını baltalamaktadır.

E-posta listesini ve şifreyi çözülmüş şifreyi yazdırabilir ve kapak sayfasındaki büyük bir uyarı ile patronunuzun masasına koyabilirsiniz: "Gizli"

Yazı tipini küçültün, ancak kağıt israfına yol açmaz.

Onlara bugzilla'nın yöneticilerin şifrelerini kullanmadan insanları kimliğine bürünmelerini nasıl sağladığını da gösterebilirsiniz.

Her şeyden önce, sadece bundan kaçınmanın daha güvenli olduğunu belirten diğer cevaplarla aynı fikirdeyim ve sadece şifrelerin kendilerini değil, şifrelerin kendilerini veya şifreye geri dönebilecek herhangi bir şeyi saklayın.

Ancak, iyileşmeye izin vermek için az ya da çok zaman istediğiniz zamanlar vardır. Şifre durumunda, genellikle bir yöneticinin mevcut şifreyi kurtarmak yerine, gerektiğinde / gerektiğinde şifreyi değiştirmesine izin vererek kurtarmak istersiniz.

Bununla birlikte, bir başka olasılık, kullanıcının kendi şifresiyle şifrelenmiş sunucuda veri depolamasına izin vermendir. Bu durumda, sadece bir yöneticinin şifreyi değiştirmesine izin vermek yeterli değildir . Yeni parola verilerin şifresini çözmek için çalışmaz ve çoğu kullanıcı şifreli verilerinin şifreyi unuttuğunda / kaybolduğunda erişilememesinin kabul edilemez olduğunu görür. Bu durum için, makul derecede güvenli bir alternatif var ve gerçekten ihtiyaç duyulduğunda kurtarmaya izin veriyor.

Verileri şifrelemek için kullanıcının şifresini kullanmak yerine, verileri şifrelemek için rastgele bir anahtar oluşturursunuz. Daha sonra bu anahtarı birkaç yerde saklayın: bir kez kullanıcı şifresiyle şifrelenmiş ve bir yönetici şifresiyle şifrelenmiş başka bir yerde. Sonra kullanıcı (gerçekten değilse) kullanıcı şifresini kaybettiğinde ve artık doğrudan verilere erişemediğinde, gerçek şifrenin şifresini çözmek için yönetici şifresini kullanabilir ve verileri kurtarmak ve / veya anahtarı yeniden şifrelemek için bunu kullanabilirsiniz. kullanıcının yeni şifresi.

Tek bir yöneticiye tamamen güvenmek istemiyorsanız, bunu da yönetebilirsiniz. Örneğin, 5 kişinin yönetici anahtarına sahip olacağına ve bir anahtar kurtarılmadan önce en az üçünün karar vermesini isteyebilirsiniz. Bu durumda, şifrelenmiş parolayı idari amaçlarla sakladığınızda, beş yöneticiden her üçü için birer kez (bir defada birden fazla anahtar sakladığınızdan fazla yer kaplamaz) birden çok kez saklarsınız , ~ 256 bit hızında, verilerin birden çok kopyası yok). Bu kopyaların her biri, bu üç yöneticinin şifrelerinden her biri ile art arda şifrelenir.

Şifresini çözmek için, şifrelerini giren üç yöneticiyi tanımlamanız ve bu üç gruba uygun şifrelenmiş anahtarı seçmeniz, sonra da orijinal şifreyi elde etmek için üç şifrenin her birini kullanarak şifresini çözmeniz gerekir. Daha sonra verileri kendisinin kurtarması için kullanabilir veya kullanıcının yeni şifresinin şifresini kullanarak yeniden şifreleyebilirsiniz, böylece yine de verilerine erişebilirler.

Bununla birlikte, bunu yaptığınızda, gerçekten standart bir şifreleme algoritması kullanmanız ve (güçlü bir tercihle) standart, iyi bilinen ve ayrıntılı olarak incelenen bir uygulama kullanmanız gerekir.

Bu beni bir hükümet projesi için verdiği için endişelendiriyor. Bir kullanıcının kimliği altında bir işlem yapmak için şifresini geri almak, her türlü güvenlik denetiminden saçma sapan bir şey yapar. Bunun için görebilmemin tek nedeni sahte bir denetim izi oluşturmak.

Şifreler için geri dönüşümlü şifreleme kullanmaya gerek yoktur. Bir kullanıcı kimliğini kandırmak için meşru bir sebep varsa, şu şekilde yapılabilir:

• Geçerli şifre karma değerini sakla
• Bilinen bir değerle değiştirme
• (Sahte denetim-iz faaliyeti, örneğin denizaşırı hesaba fon transferi)
• Orijinal şifre karma değerini değiştir

Son adımdan rahatsız olurdum - sistemde kimliğe bürünmüş her kim olduğunu bilmeli. Belki de "Gerçekten bankamın bilgiye ihtiyacım olmadan hesabınıza erişmeme izin vermesi, çünkü gerçekten ihtiyacım olduğunu söyledim" diyerek işi ikna edebilirsiniz.

Daha iyi bir şifre sistemine inançları sorun değil. Bir yönetici / desteğin bir kullanıcı hesabını taklit etmesine izin vermek ve şifreleri düzeltmek için bir çözüm oluşturun. Güvenlik genellikle kolaylık için acı çekiyor. Rahat ve güvenli hale getirin.

Düzenleme: Parola güvenliği konusunu hiçbir zaman tam olarak asla kavrayamazlar, ancak işlevlerini kaybetmeyi anlarlar. Bu teklifi yapın ve gerekli değişiklikleri yapmak için onay alıp alamayacağınızı görün. Bir saat mi yoksa bir yıl mı süreceğini bilmiyorlar. Bu bir özellik değişikliği ve tam bir yeniden inşası değil.

Mevcut olayları (Epsilon veri sızıntısı ve Playstation Network veri sızıntısı) göz önüne alındığında, sorunların göze çarpan bir şekilde belirgin olacağı umulmaktadır.

Bununla birlikte, bazen bir geliştirici olarak politikayı etkileyemezsiniz.

Mevcut olayları tekrar düşünerek kolay olması gereken skandal ve masraf potansiyelini göstermek için elimden geleni yaparım. Fakat bu başarısız olursa, gerçekten ne yapabilirsiniz. Fazla değil. Protesto gösterisinden çıkın, dikkatleri çekme konusundaki güvenlik açığını gösterin. Hiçbiri harika seçenekler gibi görünmüyor.

Buna karşı tavsiyede bulunabilirim, ancak şifrelerinizin şifresini çözme yeteneğiniz mutlaka varsa, genel anahtar şifrelemesini kullanmalısınız. Bu şekilde, genel anahtarı kullanarak tüm şifreleri şifreleyebilirsiniz. Ortak anahtarla şifreleyerek ve karşılaştırarak şifreleri doğrulayabilir ve özel anahtarı başka bir yerde saklayabilirsiniz (üretim bilgisayarında değil).

Genellikle bir Yöneticinin kullanıcı şifresini görmesinin nedeni, kaybedecek olmaları durumunda kullanıcıya verebilir. Söyleyebileceğim kadarıyla, Windows Yönetici'nin de şifreyi görmesine izin vermiyor - peki neden başvurunuz? Herhangi bir kurum içi şifreleme kütüphanesinin kırılacağından emin olabilirsiniz, çünkü kimin yazdığını NSA için işe yaramadığından eminim.