Neden yeniden gönderilmeden (ve tekrar sunucuda toplanmadan) istemcide hiçbir web sayfasının şifresi kullanılmıyor?

46

İnternette oturum açma bilgisi gerektiren pek çok site var ve parola kullanımına karşı korumanın tek yolu, parolaların sunucuda toplandığına dair söz vermektir, ki bu her zaman doğru değildir.

Bu yüzden merak ediyorum, istemci bilgisayarında (Javascript ile) şifreleri olan bir web sayfasını sunucuya göndermeden önce, nerede yeniden şifreleneceklerini yapmak ne kadar zor? Teoride bu herhangi bir ekstra güvenlik sağlamaz, ancak pratikte bu, şifreniz sunucuda bulunmayan "dolandırıcı sitelere" karşı korunmak için kullanılabilir.

— Martín Fixman
kaynak

18

net olarak gönderilen bir karma şifre, eğer sunucu sadece

3

En iyi çözüm (imo) müşteri tarafı şifre yöneticisidir. Bu şekilde, şifreniz olarak rastgele bir karakter dizisi oluşturabilirsiniz ve sizi 'korumak' için sunucuya güvenmiyorsunuz.

— Dean Harding

2

@ Jarrod - bana öyle geliyor ki, farklı müşteri siteleri karma algoritmaları kullanan farklı web siteleri gibi, bu çizgi roman tarafından açıklanan saldırıyı engeller. Yaygın olarak kullanılan bir şifre, farklı karma algoritmalar aracılığıyla birçok farklı şifre haline gelir. Bu müşteri tarafı karma hesaplaması, karma bağlantıyı güvenli bir bağlantı üzerinden göndermek gibi diğer güvenlik türlerinin uygulanmasını engellemez.

— Steve314

2

@ Steve314 Amacım müşteri üzerindeki herhangi bir şey varsayılan olarak tehlikeye atılmış olmasıdır. Eğer müşteri üzerinde yapılıyorsa ve sunucuda ileri geri geçiriliyorsa clear, bu noktada sadece matematiksel mastürbasyon olabilir. Miras aldığım bir sistemi düzeltmek zorunda kaldım, bu sizin ve OP'nin tarif ettiği şekilde tasarlandı, Wireshark'lı gençler tarafından sürekli saldırıya uğradı. Sadece REALşifrelemeye koyup şifrelediğimizde ve sunucuya ve sunucudan tüm yükleri imzaladığımızda kilitledik , hesap manipülasyonu durdu ve bundan sonra bir daha asla olmadı.

5

Kendinizi hileli sitelere karşı koruma planınız gibi görünüyor, hileli sitelerden daha iyi güvenlik kurmalarını istemek. ?

— pc1oad1etter 9:12

46

Neden kullanılmıyor? Çünkü sıfır kazanç için çok fazladan iş var. Böyle bir sistem daha güvenli olmazdı. Hatta daha az güvenli olabilir, çünkü daha güvenli olma konusunda yanlış bir izlenim verir, bu da kullanıcıların daha az güvenli uygulamaları benimsemelerine neden olur (parola tekrar kullanma, sözlük parolaları vb.).

— Rein Henrichs
kaynak

2

Bu, şu ana kadarki en iyi cevap.

1

Blu-Ray ve DVD şifreleme gibi. Kilidini açmak için bir Anahtar bile gerektirmiyor. Sağladığı tek "koruma", DVD'ler ilk çıktığında, kopyalamak için bir diski satın almanın, filmin tam bir kopyasını satın almaktan daha pahalı olmasıydı. Tabii ki şimdi bir dolar için bir dvd satın alabilirsiniz ve daha da fazlası anahtarların şu anda kamuya açık olduğu gerçeğidir. Aynı şey Blu-Ray ile oluyor

— Michael Brown

2

İstemci tarafında bir şifre bulundurmanın güvenlik sağladığını düşünüyorum. Eğer dinliyorsam, şifrenizi değil, sadece özetinizi görebilirim. Sunucu (olması gerektiği gibi) bir meydan okuma gönderirse karma yeniden kullanılamaz.

— Andomar

2

X4u'nun yaklaşımının, güvenlik gereksinimlerinin kablo üzerinden parola iletimi ile sertifika kullanmak arasında bir yerde olduğu bazı uygulamalar için çok uygun olabileceğini düşünüyorum. Sanırım bazı naylı söyleyiciler , standart sunucu tarafı kimlik bilgisi işlemine ek olarak , telin kabloya geçmeden önce şifrelemesinin yapıldığını göz ardı ediyorlar . Öyleyse soru şudur: x4u’nun önerisi, senaryodaki parolanın aktarılmasında güvenliği artırıyor mu, vermiyor mu? Ben öyle diyorum. Bunu gerçekleştirmenin anahtarı parola başına tuz kullanımında yatmaktadır.

— LOAS

6

MITM saldırılarını önlemenin doğru yolu uçtan uca şifrelemedir. TLS (https) var: kullan. Kendi şifreleme şemalarınızı icat etmeyin.

— Rein Henrichs

14

Teoride bu herhangi bir ekstra güvenlik sağlamaz, ancak pratikte bu, şifreniz sunucuda bulunmayan "dolandırıcı sitelere" karşı korunmak için kullanılabilir.

Bu sizi tam olarak nasıl koruyor? Tek yapmak istediğin gibi, anlamsız olan bir karma şifreye sahip olmak gibi geliyor. Çünkü karma şifre, şifre olur.

İnternette oturum açma bilgisi gerektiren pek çok site var ve parola kullanımına karşı korumanın tek yolu, parolaların sunucuda toplandığına dair söz vermektir, ki bu her zaman doğru değildir.

Aynı şifreyi birden fazla site için kullanmamaya ne dersin? Web sitelerinin teoride parola bulundurmasının nedeni, THY'nin ihlal edilmesi durumunda hesabınıza erişimi engellemektir. Aynı şifreyi birden fazla web sitesi için kullanmak aptalca.

Javascript kullandıysanız, tüm "hacker" ın yapması gereken, hashed-hashed-passwords'de aynı yöntemi kullanmaktır. Birikmiş bilgiyi aldıktan sonra, veritabanında bir hesaba erişimi engelleyen bir faktör olan şifreyi hesaplamak için tam zamanıdır.

— Ramhound
kaynak

1

Tarayıcınız her zaman aynı şekilde hash yaparsa, evet, hash'ınız her yerde bir şifre olarak kullanılabilir. Ancak, tarayıcılar siteye bağlamadan ve göndermeden önce siteye (belki de etki alanına göre) bir tuz atadıysa ne olur? Bence ilginç bir fikir.

— Tesserex

2

Müşterinin üzerinde ise, riske atılmışsa, müşterinin üzerindeki herhangi bir tuz açık görüşlüyse, bu mantıksız bir sorudur. @ Ramhound'un cevabını anlamıyorsanız, güvenli olması gereken kodu yazmamalısınız ve en baştan güvenlik ve şifreleme üzerine okumaya başlamalısınız.

3

Orijinal posteri alıntı yaparken, lütfen metni bu şekilde biçimlendirin (metni seçin ve editörün hemen üzerindeki alıntı simgesini kullanın)

— Marjan Venema

1

Jarrod, lütfen kendi tavsiyene uy ve gülünç iddialarda bulunmadan önce kendini biraz bilgilendir. Orta saldırıdaki bir adam, makul tuz uzunluğuyla güvenli hash fonksiyonlarına karşı işe yaramaz. Benim önerim, hiçbir şekilde 'belirsizlikten güvenlik' değildir, bu alanda uzmanlar tarafından şu anda bilinen ve kabul edilen şeye dayanarak aslında güvenlidir ve birçok protokolde aynı şekilde kullanılır. Bu benim icadım değil, sadece bir web sitesi girişine iyi anlaşılmış bir prosedür uyguladım. Yanlış varsayımlarınız, birçoğu tarafından da açıkça paylaşıldığı için herhangi bir madde kazanmaz.

— x4u

3

Tuz müşteri tarafından biliniyorsa ve berrak bir sunucudan gönderiliyorsa, ortadaki herhangi bir şey de bunu bilir. Asla, müşterinin tuzunu bilmediğin takdirde güvenli olmadığını söyle, karmayı geri almam gerektiğini söylemedi.

11

Çünkü hiçbir değere çok az şey katar. Bunun nedeni, eğer veritabanınız saldırıya uğradığında, bilgisayar korsanının geçerli bir parola listesine sahip olmayacağından, sadece hashlere sahip olacağından. Bu nedenle herhangi bir kullanıcıyı taklit edemediler. Sisteminizin şifre hakkında bilgisi yok.

Güvenli, SSL sertifikalarından ve bir tür kimlik doğrulamasından gelir. Kullanıcılarımın bir şifre sağlamalarını istiyorum, böylece karma değerini hesaplayabilirim.

Ayrıca, karma algoritma sunucuda daha güvenli bir alanda olacaktır. İstemciye koymak, onun gizli referans script dosyaları olsa bile, Javascript için kaynak kodunu almak oldukça kolaydır.

— Jon Raynor
kaynak

3

Bu en iyi cevap. Aktarım katmanında şifrelemelisiniz. Bunu yapmadan, geri kalan güvenli değildir. Evet, bir şifreleme işlevi yazabilirsiniz ... ancak bu işlev (kötü niyetli) son kullanıcılar tarafından görülebilir. SSL kullanın.

— pc1oad1etter

Bir karma algoritmanın güvenliği bunun gizli olup olmamasına bağlı olmamalıdır. Güvenlik için karma algoritmalar tek yönlü işlevler olmalıdır: kodunuz olsa bile geri almak zordur. Aksine, yalnızca şifreler için tasarlanmış iyi bilinen bir karma kitaplığı kullanmalısınız. Eğer iyi tanınmıyorsa, kesinlikle şüpheli ya da yanlış yönlendirilmiş.

— leewz

6

Çözüm bundan daha basittir. Müşteri sertifikaları Makinemde bir müşteri sertifikası oluşturuyorum. Bir web sitesine kayıt olduğumda, müşteri sertifikamı ve sunucunun sertifikasını kullanarak bir el sıkışma yapıyoruz.

Hiçbir şifre değiş tokuş edilmez ve birisi veritabanına sızsa bile, sahip olacağım tek şey müşteri sertifikamın ortak anahtarıdır (ek bir güvenlik düzeyi için sunucu tarafından tuzlanıp şifrelenmesi gerekir).

Müşteri sertifikası bir akıllı kartta saklanabilir (ve bir ana şifre kullanarak güvenli bir çevrimiçi kasaya yüklenebilir).

Hepsinin güzelliği, uzaktaki kimlik avı kavramını ortadan kaldırmasıdır ... asla bir web sitesine şifre girmezsiniz, sadece bu web sitesiyle el sıkışırsınızdır. Tek elde ettikleri özel anahtar olmadan işe yaramaz olan sizin açık anahtarınızdır. Tek duyarlılık, bir el sıkışma sırasında bir çarpışma bulmak ve tek bir web sitesinde sadece bir kez işe yarayacak.

Microsoft, Windows'ta Cardspace ile böyle bir şey sağlamaya çalıştı ve daha sonra açık bir standart olarak sundu. OAuth biraz benzer, ancak aracı bir “veren parti” ye dayanıyor. Öte yandan InfoCard'lar kendi kendine verilebilir. Şifre sorununa gerçek çözüm ... şifreleri tamamen kaldırmak.

OAuth olsa doğru yönde bir adımdır.

— Michael Brown
kaynak

5

Müşteri sertifikaları bazı kullanım durumları için makul bir yaklaşım olsa da, bir web sitesi girişine kolayca eklenebilecek bir şey değildir. Kullanıcılar tarafından büyük miktarda işbirliği yapılmasını gerektirir ve kullanıcıların özel anahtarın ne kadar güvenli olduğuna bağlıdır. Özel bir anahtarın kullanılması hem güvenli hem de uygun olabilir ancak ikisi aynı anda olmayabilir.

— x4u

5

Buradaki yanıtların çoğu, istemci tarafı parola karmaşasının noktasını tamamen kaçırmış görünüyor.

nokta değil bir karma müdahale bir düz metin parolası müdahale daha daha güvenlidir, çünkü sen giriş olduğunu sunucuya güvenli erişim için.

Önemli olan , kullanıcı şifresini güvenli kılmaktır , bu genellikle bireysel siteye giriş erişiminden çok daha değerlidir, çünkü çoğu kullanıcı şifresini birden fazla site için tekrar kullanır (yapmamalıydı, ama gerçekte ki bunu yapmazlardı ).

ssl mitm saldırılarına karşı koruma sağlamak için harikadır, ancak sunucuda bir oturum açma uygulaması tehlikeye girerse, ssl kullanıcılarınızı korumaz. Eğer birisi bir web sunucusuna kötü niyetli bir şekilde erişmişse, çoğu durumda şifreler sadece sunucudaki bir betik tarafından şifrelenir, çünkü şifreleri düz metin halinde arayabilirler. daha sonra saldırgan benzer şifreleri kullanarak diğer (genellikle daha değerli) sitelerdeki şifreleri deneyebilir.

Güvenlik derinlemesine savunmadır ve müşteri tarafı hash basitçe başka bir katman ekler. Kendi sitenize erişimi korumanın önemli olduğunu, kullanıcılarınızın şifrelerinin gizliliğinin korunmasının diğer sitelerdeki şifrelerin tekrar kullanılması nedeniyle çok daha önemli olduğunu unutmayın.

— crutchy
kaynak

2

Kabul edilen cevap, amacınızı oldukça iyi paylaşıyor. "Çoğu yanıt" yazmıyor ve cevabınız gerçekten fazla bir değer katmadığı için, bu soruyu tekrar yönlendirmenin bir anlamı yok.

— Frank

Muhtemelen bir cevaptan çok bir yorumdur (kabul edilen cevap yorum dizisine nasıl ekleneceğini bulamadığım için özür diler) ve benim düşüncem kabul edilen cevapta paylaşılsa bile, göründüğü kadarıyla cevaplar açıkça görünmüyordu. Hala fırçalamak için. geri bildirim için teşekkürler

— crutchy 12

@ Kabul edilen cevap sınırlarını, okumayı zorlaştırmak için çok uzun olmanın ardından izleyin. bunun nasıl uygulanabileceği konusunda çok fazla ayrıntıya girmekte ve faydaları sonuna kadar incelemektedir. Bir TL'nin olması DR'nin farklı bir cevapta olması yararlıdır.

— Jules

2

@Jules: Bu yüzden düzenleme var.

— Robert Harvey,

1

Ne kafa karıştırıcı olduğunu düşünüyorum @JarrodRoberson artık güvenli ile kendine güveni olmayan ? MITM olursa, siteye erişimden vazgeçilmiştir, değil mi? Eğer şifresi yerine istemci sertifika kullanmak sürece, olurdu aşırı karmaşık sıradan kullanıcılar için. Gördüğüm gibi, istemci tarafı karma, her karma algoritma benzersiz olduğunu varsayarak, diğer sitelerde aynı şifrenin tehlikeye girmesini önler. Daha güvenli olmayabilir, ancak hiçbir şekilde daha az güvenli değil mi? Peki neden bu kadar zorluyorsun? Buna metadan rastladım ve bu şu ana kadar gördüğüm en iyi cevap.

— zypA13510

1

Bu kesinlikle mümkün ve aslında bir web sitesi için beklemenize gerek yok.

SuperGenPass'a bir bakın . Bu bir bookmarklet.

Yalnızca parola alanlarını tanır, web sitesi alanıyla yazdıklarınızı birleştirir, hash yapar, parolada yalnızca "kabul edilen" karakterleri alabilmesi için bir miktar düzenler ve yalnızca o zaman kabloda gönderilen karma parolanız olur.

İşlemde site etki alanını kullanarak, her zaman aynı parolayı tekrar kullansanız bile, site başına benzersiz bir parola elde edersiniz.

Son derece güvenli değildir (base64-MD5), ancak isterseniz sha-2 tabanlı bir uygulamayı mükemmel bir şekilde dağıtabilirsiniz.

Tek dezavantajı etki alanı değişirse, bu durumda web sitenizi şifrenizi sıfırlamanızı istemeniz gerekir, çünkü şifrenizi kendiniz kurtaramazsınız ... sık sık olmuyor kabul edilebilir takas.

— Matthieu M.
kaynak

Bu soruyu okuduğumda düşündüğüm şeydi; sitelerin kendi müşteri karma işlemlerini yapması neredeyse işe yaramaz, ancak bunu yapan bir tarayıcı uzantısı (etki alanına göre biraz tuz kullanarak) parola yeniden kullanımıyla ilişkili riskleri etkili bir şekilde geçersiz kılar. Tabii ki, eğlenceli kısım başka bir makineden giriş yapmaya çalıştığınızda geliyor ...

— Aaronaught

3

bu, artık şifreyi açık bir şekilde geçen herhangi bir programdan daha güvenli değildir. Şifreyi benzersiz kılar ancak hala şifreli değildir , ancak ortada bir sunucum varsa, karmaşık ancak yine de açık olan bir şifreyi alıp istediğim kadar kullanabilirim, değişmiyor. Bir hash, sihirli bir mermi değil, şifreleme bile yapmıyor, buna şifreleme hasheleri deniyor, ancak bu şifreleme oldukları anlamına gelmiyor. Şifrem ve müşterinin bildiği bir miktar tuz içeren passwordbir SHA-256 olması önemli değil password, ortadaki bir adam onu yakalayabilir.

@ Robrod Roberson: Elbette şifresini kullanabilirsiniz, fakat asıl meselemi hesaplarımın bir başkası için tekrar kullanamazsınız. Bu nedenle, bağlandığım web sitesinden biri şifre tabanını çaldırdıysa ve onları temiz bir şekilde sakladıysa, diğer hesaplarım güvendedir.

— Matthieu M.

@Aaronaught: aslında parladığı yer. Gönderilen şifre tamamen oturum açtığınız web sitesi alan adından ve seçtiğiniz bir ana şifre türetildiği için, yer imi elinizde olduğu sürece herhangi bir bilgisayardan (ve tarayıcıdan) giriş yapabilirsiniz. Bu yüzden bir sertifikadan biraz daha rahat.

— Matthieu M.

6

@ Jarrod: Bu, site için bir güvenlik önlemi değil , kullanıcı için bir güvenlik önlemidir . Herkes böyle bir şema kullandıysa, parolanın tekrar kullanılması sorun olmazdı. Bir MITM programı, söz konusu siteye erişmek için yalnızca o siteye erişim sağlamak için müşterinin şifreli şifresini kullanabilir . Gelişme burada yatıyor. Normalde tek bir şifreyi kırarak birçok hesaba erişmeyi beklersiniz , çünkü bu şifrenin tekrar kullanılması muhtemeldir; Bu durumda, çatlak şifre pratikte sadece bulundu sitesi veya veritabanı için geçerli olması sağlanır.

— Aaronaught

0

X4u'nun cevabını seviyorum, ama bence onun gibi bir şey tarayıcıya / html spesifikasyonuna entegre edilmelidir - şu anda cevabın sadece yarısı.

İşte bir kullanıcı olarak sahip olduğum bir problem - Veritabanında saklandığında şifremin diğer ucunda şifrelenip şifrelenmeyeceği konusunda hiçbir fikrim yok. Sunucuyla aramdaki satırlar şifrelenmiş olabilir, ancak hedefe ulaştıktan sonra şifreme ne olacağı hakkında hiçbir fikrim yok - belki düz metin olarak saklanır. Veri tabanı yöneticisi, veri tabanını satabilir ve siz bilmeden önce bütün dünya şifrenizi bilir.

Çoğu kullanıcı şifreleri yeniden kullanır. Teknik olmayan insanlar çünkü daha iyisini bilmiyorlar. Teknik insanlar, çünkü bir kez 15. şifreye girdiğinizden, yani çoğu kişi, onları yazmadıkça, onları hatırlama şansına sahip değil (ki hepimiz de kötü bir fikirdir).

Eğer Chrome veya IE veya ne kullanıyorsam kullanayım, bir şifre kutusunun bir sunucu tarafından üretilen tuz kullanılarak anında şifrelenmiş olacağını ve şifrenin kendisini etkin bir şekilde sildiğini söylerse - o zaman bir kullanıcı olarak tekrar kullanabileceğimi biliyordum. daha az riskli bir şifre. Şifrelenmiş kanalları hala istiyorum, iletim sırasında herhangi bir saçak düşmesini istemiyorum.

Kullanıcının şifresinin sunucuya gönderilemeyeceğini bile bilmesi gerekir - yalnızca karma. Şu anda X4U'nun çözümünü kullanarak bile, bunun teknolojinin kullanımda olup olmadığını bilmediğinizden, durumun böyle olduğunu bilmenin yolu yok.

— Chris Nevill
kaynak

1

tarayıcıya entegre edilir ve kimlik doğrulaması yapılır ve http'de ileri bir adım attığını ve şifreyle şifrelenmiş, ekstra bilgiler içeren ve sunucuda doğrulanmış olanları göreceksiniz.

— gbjbaanb 11

-1

Üzerinde kurulu olduğu sunucuları kontrol edemediğiniz bir çerçeve, CMS, forum yazılımı vb. Bir şey oluştururken kullanmanın iyi bir yöntem olduğunu düşünüyorum. Yani, YES, girişler ve giriş yapma etkinlikleri için her zaman SSL kullanmanızı tavsiye etmelisiniz, ancak çerçevenizi / cms'inizi kullanan bazı siteler buna sahip olmayacaktır, bu yüzden bundan faydalanabilirler.

Diğerlerinin de belirttiği gibi, buradaki yarar, MITM saldırısının başkasının sizin gibi bu özel siteye giriş yapmasına izin vermeyeceği, ancak saldırganın aynı kullanıcı adını / şifresini bir arada kullanamayacağıdır. Muhtemelen hesabınız olabilecek başka düzinelerce siteye giriş yapın.

Böyle bir düzen, rastgele bir tuzla veya siteye özgü ve kullanıcı adına özgü tuzların bir kombinasyonuyla tuzlanmalıdır, böylece şifreyi alan bir kişi, diğer sitelerde (aynı karma planını kullanan siteler bile) aynı kullanıcı adı için kullanamaz. ), aynı siteye girebilecek diğer kullanıcılara karşı da aynı şifreye sahip olamaz.

Diğerleri, kullanıcıların kullandıkları her site için benzersiz şifreler oluşturması veya şifre yöneticileri kullanması gerektiğini önerdi. Bu teoride sağlam bir tavsiye olsa da, hepimiz bunun gerçek dünyaya güvenmenin delice olduğunu biliyoruz. Bunlardan birini yapan kullanıcıların yüzdesi küçüktür ve yakında herhangi bir zamanda değişeceğinden şüpheliyim.

Dolayısıyla, bir javascript şifresi hastası, hem site sahibi hem de son kullanıcılar ihmalkarlık yapıyorsa, geçiş sırasında şifrelenen birinin (bu günlerde wifi ağlarında kolay olan) şifresini ele geçiren birisinin zararını sınırlamak için yapabileceği en düşük düzeydedir. güvenlik hakkında (muhtemelen bunlar).

— matthewv789
kaynak