jCryption + CRAM是SSL的一個很好的選擇？

我想知道如果jCryption +挑戰響應身份驗證機制是SSL的一個很好的選擇。jCryption + CRAM是SSL的一個很好的選擇？

我知道SSL是非常好的，但我正在做一個項目，其所有者不想購買SSL證書，我想找到一個解決方案，以提供最佳的安全方法，可能是無需使用SSL即可獲得。

任何想法？

來源

2011-11-22 Cristiano Santos

使用ssl，用您自己的證書運送產品。 – rook

不，它不是。

就在我頭頂的時候，我可以想到很多原因：HTTP頭仍未加密，密鑰交換容易受到中間人攻擊，並且您將高度信任在客戶端代碼中。

只需使用a free SSL certificate from Startcom。

來源

2011-11-22 23:12:29 josh3736

但傳遞給客戶端的唯一密鑰是公鑰，它在每個POST/GET時都會更改。我忘了說網站應該只支持JS功能。 –

@CristianoSantos：客戶端不可能知道它收到的公鑰是可信的（這實質上是SSL證書的作用）。攻擊者可以更改從服務器發送的公鑰併發送客戶端*他的公鑰 - 一種經典的[MITM]（http://en.wikipedia.org/wiki/Man-in-the-middle_attack）攻擊。 – josh3736

嗯，對。我沒有想到......只是爲了完成這個主題，是否有可能知道客戶端收到的公鑰是否可信，而不使用SSL？ –

在jCryption的信息部分：

jCryption在它的當前狀態沒有更換SSL，因爲沒有認證，但jCryption的主要目標應該是一個很容易和快速安裝插件，其中提供基本級別的安全性。

這是不言而喻的。這個插件不是以任何方式取代SSL，也不是。目標不是高科技安全。

如果您想要以任何方式信任的安全性，只需購買SSL證書即可。或者如果你願意，你可以自己製作。

來源

2011-11-22 23:11:26 Blender

我看到了。這就是爲什麼我的問題將CRAM與jCryption結合在一起。如果POST/GET數據僅使用一次公鑰/私鑰進行加密，並且登錄會話的密碼由於CRAM而仍然被加密，那麼在安全風險方面它有多糟糕？ –

你可能有興趣在這篇文章中：

Javascript Cryptography Considered Harmful

來源

2011-11-23 01:04:02 Bruno

您可以嘗試使用Challenging Authentication-Agreement Protocol (CAAP)。我建議您在CTR模式下使用RSA和Serpent算法，並在每條消息中附加一個HMAC-SHA-512認證碼。這可以用最少的知識來安全地實施。雖然一個很好配置的SSL系統可能會更容易和更安全。

如果這不是面向公衆的服務器，您可以隨時在自己的組織內部啓動自己的證書頒發機構。這樣SSL證書不會讓你成爲胳膊和腿。

來源

2011-11-23 01:15:52

不適合替代SSL。 – rook

jCryption是否提供使用RSA和AES的CAAP？ –

據我所知，沒有廣泛分佈的軟件實現CAAP。至少不是在這個名字下。 –

jCryption + CRAM是SSL的一個很好的選擇？

回答

相關問題