A company I know is in discussions to firm up its password security policy across all its web application products.
我所知道的一家公司正在讨论如何在其所有Web应用程序产品中确定其密码安全策略。
Right now they are sending username / password authentication in POST forms over HTTP, and thus, they are being sent plaintext.
现在,他们通过HTTP在POST表单中发送用户名/密码身份验证,因此,他们正在发送纯文本。
The simplest solution to the problem is simply to require HTTPS for logon across all our applications, right?
解决这个问题最简单的方法就是要求HTTPS在所有应用程序中登录,对吧?
Well, there's some internal discussion about instead doing some kind of roll-our-own client-side encryption of passwords (password + salt, etc.).
好吧,有一些内部讨论,而不是做一些自己的客户端密码加密(密码+盐等)。
Is there an accepted HTTP-only solution?
是否有可接受的仅HTTP解决方案?
Opinions are like... well, everyone has an opinion, so I'm looking for credible security literature that can support your recommendation. Don't just google and send me to a blog post... I've already done that and further.
意见就像......好吧,每个人都有意见,所以我正在寻找可以支持你的建议的可靠安全文献。不要只是google并将我发送到博客文章......我已经做到了这一点并且进一步。
I have found OWASP's recommendations: http://www.owasp.org/index.php/Top_10_2007-A7#Protection
我找到了OWASP的建议:http://www.owasp.org/index.php/Top_10_2007-A7#Protection
As well as Microsoft's: http://msdn.microsoft.com/en-us/library/aa302420.aspx
以及微软的:http://msdn.microsoft.com/en-us/library/aa302420.aspx
EDIT: Giving your recommendation for using SSL isn't enough. I need some kind of supporting documentation. I KNOW that rolling our own client side encryption is bad. I need to be able to credibly sell that to co-workers and management.
编辑:提供使用SSL的建议是不够的。我需要某种支持文档。我知道滚动我们自己的客户端加密是不好的。我需要能够可靠地将其出售给同事和管理层。
Also, HTTP Digest has been mentioned. Seems nice, but Digest is ONLY for HTTP authentication, and not for data sent over POST.
此外,还提到了HTTP Digest。看起来不错,但Digest仅用于HTTP身份验证,而不适用于通过POST发送的数据。
10 个解决方案
#1
+1 to Mehrdad's answer. Going ahead with home-grown cryptography is risky.
给Mehrdad的答案+1。继续使用本土密码学是有风险的。
Speaking from experience here, after having seen vulnerabilities in home-grown client-side encryption solutions. Most of the vulnerabilities are due to the same reason - the data transfer was protected by encryption with a secret key, but the key itself was exchanged in an insecure manner.
从本文的经验谈起,在看到了本土客户端加密解决方案中的漏洞之后。大多数漏洞都是由于同样的原因 - 数据传输受到使用密钥加密的保护,但密钥本身是以不安全的方式进行交换的。
TLS/SSL solves the problem of not just secure key exchange, but also of secure data transfer.
TLS / SSL解决了安全密钥交换以及安全数据传输的问题。
TLS/SSL protects your sensitive information by using assymmetric key cryptography to exchange the symmetric key used to encrypt information back and forth, once the TLS/SSL session has been established. The symmetric key is generated at runtime, and is a shared secret between the client and the server; it is this key that is used to encrypt all other traffic once the session is ready for transfer of data.
TLS / SSL通过使用非对称密钥加密来保护您的敏感信息,以便在建立TLS / SSL会话后交换用于来回加密信息的对称密钥。对称密钥在运行时生成,是客户端和服务器之间的共享密钥;一旦会话准备好传输数据,就会使用此密钥加密所有其他流量。
The server's public and private keys are used only to exchange this shared secret. The only known way to compromise the shared key is to compromise the server's private key (so that the secret key can then be decrypted). In reality, it requires negligence or malice on the part of the server administrator.
服务器的公钥和私钥仅用于交换此共享密钥。危害共享密钥的唯一已知方法是破坏服务器的私钥(以便然后可以解密密钥)。实际上,它需要服务器管理员的疏忽或恶意。
If you roll your own encryption solution, you must exchange the symmetric key, in a secure manner. The easiest way to do so is to use TLS/SSL; the harder way is to implement your own assymmetric key exchange cryptography solution.
如果您使用自己的加密解决方案,则必须以安全的方式交换对称密钥。最简单的方法是使用TLS / SSL;更难的方法是实现自己的非对称密钥交换密码解决方案。
#2
I highly recommend against going with your own solution (in security sensitive environments). Go with SSL. It's a proven technology and it's easy to implement.
我强烈建议您不要使用自己的解决方案(在安全敏感的环境中)。使用SSL。它是一种经过验证的技术,易于实施。
Rolling your own security solutions can be really dangerous and even if it's implemented properly (0.000001% chance), it will be expensive.
滚动您自己的安全解决方案可能非常危险,即使它正确实施(0.000001%几率),也会很昂贵。
#3
If the data itself isn't too sensitive, but the passwords are, I'd suggest using HTTP digest authentication (which is quite a different beast from HTTP basic authentication). It's is quite secure over straight HTTP, and not at all difficult to implement on the server. Nothing is sent over the wire that could reveal what the password is, just information that allows the client to demonstrate to the server that they have the correct password.
如果数据本身不是太敏感,但密码是,我建议使用HTTP摘要认证(这与HTTP基本认证完全不同)。它比直接HTTP更安全,并且在服务器上实现起来并不困难。没有任何内容通过网络发送,可以揭示密码是什么,只是允许客户端向服务器证明他们有正确密码的信息。
If you want a decent explanation of how to implement HTTP digest authentication in your application, Paul James has an excellent article on it.
如果您想要在应用程序中如何实现HTTP摘要身份验证,Paul James有一篇很好的文章。
The only real problem with HTTP authentication is in the browsers themselves: the UI is terrible, but that can be overcome with some Javascript.
HTTP身份验证的唯一真正问题在于浏览器本身:UI很糟糕,但可以通过一些Javascript来克服。
You can store the passwords securely by storing the A1 hash.
您可以通过存储A1哈希来安全地存储密码。
UPDATE: As mentioned in other answers, while the server can avoid MITM attacks by not accepting Basic auth, the client is still vulnerable because it will.
更新:正如其他答案所述,虽然服务器可以通过不接受基本身份验证来避免MITM攻击,但客户端仍然容易受到攻击,因为它会。
UPDATE: You can't secure data over POST unless you either (a) do encryption in JavaScript on the client or, (b) do everything over SSL.
更新:您无法通过POST保护数据,除非您(a)在客户端上使用JavaScript加密,或(b)通过SSL执行所有操作。
You can, with a little bit of magic, use HTTP auth with forms. The article I linked to above is called 'HTTP Auth with HTML forms', after all. But that won't be done over POST.
您可以通过一些魔术将HTTP身份验证与表单一起使用。毕竟,我上面链接的文章称为“带有HTML表单的HTTP Auth”。但这不会通过POST完成。
If you really need it do use POST, use SSL and salt the passwords in your database.
如果你真的需要它,请使用POST,使用SSL并在数据库中加密密码。
If you want avoid CSRF, I recommend using formkeys, though the idea goes by many different names, I picked up that name from hacking Slashcode for my own use a few years back, which is where I came across it first.
如果你想避免使用CSRF,我建议使用formkeys,虽然这个想法有很多不同的名字,但是几年前我从黑客Slashcode中获取了这个名字供我自己使用,这是我第一次看到它的地方。
#4
You'll spend more time and money rolling your own solution and not be assured that it's secure. Industry standard SSL is easy to implement and far more secure out of the box than you can afford to make your own solution.
您将花费更多的时间和金钱来推动自己的解决方案,而不是确保它是安全的。行业标准SSL易于实施,开箱即用的安全性远远超出您自己制定解决方案的能力。
time == money
时间==钱
Buy a certificate and spend your time working on your application instead of a secure login form.
购买证书并花时间处理您的应用程序而不是安全登录表单。
#5
Client-side encryption is helpless against most MITM attacks. Attacker can simply remove your script.
客户端加密对大多数MITM攻击无能为力。攻击者可以简单地删除你的脚本。
It will only protect against passive sniffing. If that is good enough for you, you can use:
它只能防止被动嗅探。如果这对您来说足够好,您可以使用:
- Hashing implemented in Javascript. It's easy to implement challenge-response for initial login, but don't forget that for attacker session cookie is almost as good as password (you'd have to limit login to single IP and/or use script to generate one-time cookie for every request, which I imagine would be difficult and brittle solution).
- HTTP Digest authentication. More secure, as it can use one-time hashes, mutual authentication, etc., but standard UI is absolutely repulsive.
在Javascript中实现哈希。初始登录时很容易实现质询 - 响应,但不要忘记,对于攻击者会话cookie几乎与密码一样好(您必须限制登录到单个IP和/或使用脚本生成一次性cookie每一个请求,我想这将是困难和脆弱的解决方案)。
HTTP摘要式身份验证。更安全,因为它可以使用一次性哈希,相互身份验证等,但标准UI绝对令人厌恶。
...just use SSL.
......只需使用SSL。
#6
HTTP only solutions will always be susceptible to man-in-the-middle attacks.
仅HTTP解决方案将始终容易受到中间人攻击。
EDIT: A network trace would be an easy way to prove that HTTP isn't secure.
编辑:网络跟踪将是一种证明HTTP不安全的简单方法。
#7
Okay, here's the only answer you need: Your BANK only supports login/auth via SSL. If there was a better way to do it, they would.
好的,这是您需要的唯一答案:您的BANK仅支持通过SSL登录/验证。如果有更好的方法,他们会。
#8
Well, there's some internal discussion about instead doing some kind of roll-our-own client-side encryption of passwords (password + salt, etc.).
好吧,有一些内部讨论,而不是做一些自己的客户端密码加密(密码+盐等)。
The first thing we need to address is data in transit vs. data at rest. From the OP it sounds like the big concern is username/password in the clear over the Internet. So, you really care about data in transit. HTTPS via SSL is a tested method of doing this (and it's a pretty easy fix!). Now, if you really want to roll your own for data at rest (in a db, on a file server, etc.), that's a different beast, but the existing methods for data encryption are going to be better than a roll your own.
我们需要解决的第一件事是传输中的数据与静止时的数据。从OP看起来,最重要的是通过互联网明确用户名/密码。所以,你真的关心传输中的数据。通过SSL的HTTPS是一种经过测试的方法(这是一个非常简单的修复!)。现在,如果你真的想要为静态数据(在数据库中,在文件服务器上等)推出自己的数据,这是一个不同的野兽,但现有的数据加密方法将比自己的滚动更好。
Relying on the client side for your security is bad. Period. In a corporate environment, yes, you can somewhat rely on a standard setup. But, ultimately, users are dumb and you may run into someone disabling javascript or whatever client based solution you roll out, so they end up sending the username/password in plain text anyway (even if your servers dont' know what to do with it because it's not in the expected format.
依靠客户端来保证安全性是不好的。期。在企业环境中,是的,您可以在某种程度上依赖于标准设置。但是,最终,用户是愚蠢的,你可能会遇到禁用javascript或任何基于客户端的解决方案的人,所以他们最终都会以纯文本形式发送用户名/密码(即使你的服务器不知道如何处理它)因为它不是预期的格式。
Roll-your-own is not going to be subject to the scrutiny that an existing solution has. You could end up adding additional security issues into the mix because of the code.
自己动手不会受到现有解决方案的严格审查。由于代码原因,您最终可能会在混合中添加其他安全问题。
#9
We just put out a web/mobile app to do some of this stuff. It creates random URLs for logins, using HTTPS and a hashed/AES encryption method for the database storage. Theres a simple JSON API to use it without our UI, heres our writeup, give it a look.. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it
我们只是推出了一个网络/移动应用程序来完成这些工作。它使用HTTPS和数据库存储的散列/ AES加密方法为登录创建随机URL。这是一个简单的JSON API,可以在没有我们UI的情况下使用它,继承我们的文章,看一看...... http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it
#10
you mentioned doing your own encryption plus salt... I suggest using javascript md5 (it's also used by yahoo on their non ssl pages, or so he claims)...
你提到做自己的加密加盐...我建议使用javascript md5(雅虎也在非ssl网页上使用它,或者他声称)...
And you double hash the password... some may argue that double hashing it would make it prone to collision attacks. I would have to disagree because people have been able to do till now md5 signature collisions only on files, where large amount of data is md5'ed...
你加倍密码密码......有些人可能认为双重哈希它会使它容易发生碰撞攻击。我不得不反对,因为人们至今只能对文件进行md5签名冲突,其中大量数据是md5'ed ...
If it's a big corporate website (and there would be reasons to break in) there is no excuse not using SSL.
如果它是一个大型企业网站(并且有理由闯入),没有理由不使用SSL。
#1
+1 to Mehrdad's answer. Going ahead with home-grown cryptography is risky.
给Mehrdad的答案+1。继续使用本土密码学是有风险的。
Speaking from experience here, after having seen vulnerabilities in home-grown client-side encryption solutions. Most of the vulnerabilities are due to the same reason - the data transfer was protected by encryption with a secret key, but the key itself was exchanged in an insecure manner.
从本文的经验谈起,在看到了本土客户端加密解决方案中的漏洞之后。大多数漏洞都是由于同样的原因 - 数据传输受到使用密钥加密的保护,但密钥本身是以不安全的方式进行交换的。
TLS/SSL solves the problem of not just secure key exchange, but also of secure data transfer.
TLS / SSL解决了安全密钥交换以及安全数据传输的问题。
TLS/SSL protects your sensitive information by using assymmetric key cryptography to exchange the symmetric key used to encrypt information back and forth, once the TLS/SSL session has been established. The symmetric key is generated at runtime, and is a shared secret between the client and the server; it is this key that is used to encrypt all other traffic once the session is ready for transfer of data.
TLS / SSL通过使用非对称密钥加密来保护您的敏感信息,以便在建立TLS / SSL会话后交换用于来回加密信息的对称密钥。对称密钥在运行时生成,是客户端和服务器之间的共享密钥;一旦会话准备好传输数据,就会使用此密钥加密所有其他流量。
The server's public and private keys are used only to exchange this shared secret. The only known way to compromise the shared key is to compromise the server's private key (so that the secret key can then be decrypted). In reality, it requires negligence or malice on the part of the server administrator.
服务器的公钥和私钥仅用于交换此共享密钥。危害共享密钥的唯一已知方法是破坏服务器的私钥(以便然后可以解密密钥)。实际上,它需要服务器管理员的疏忽或恶意。
If you roll your own encryption solution, you must exchange the symmetric key, in a secure manner. The easiest way to do so is to use TLS/SSL; the harder way is to implement your own assymmetric key exchange cryptography solution.
如果您使用自己的加密解决方案,则必须以安全的方式交换对称密钥。最简单的方法是使用TLS / SSL;更难的方法是实现自己的非对称密钥交换密码解决方案。
#2
I highly recommend against going with your own solution (in security sensitive environments). Go with SSL. It's a proven technology and it's easy to implement.
我强烈建议您不要使用自己的解决方案(在安全敏感的环境中)。使用SSL。它是一种经过验证的技术,易于实施。
Rolling your own security solutions can be really dangerous and even if it's implemented properly (0.000001% chance), it will be expensive.
滚动您自己的安全解决方案可能非常危险,即使它正确实施(0.000001%几率),也会很昂贵。
#3
If the data itself isn't too sensitive, but the passwords are, I'd suggest using HTTP digest authentication (which is quite a different beast from HTTP basic authentication). It's is quite secure over straight HTTP, and not at all difficult to implement on the server. Nothing is sent over the wire that could reveal what the password is, just information that allows the client to demonstrate to the server that they have the correct password.
如果数据本身不是太敏感,但密码是,我建议使用HTTP摘要认证(这与HTTP基本认证完全不同)。它比直接HTTP更安全,并且在服务器上实现起来并不困难。没有任何内容通过网络发送,可以揭示密码是什么,只是允许客户端向服务器证明他们有正确密码的信息。
If you want a decent explanation of how to implement HTTP digest authentication in your application, Paul James has an excellent article on it.
如果您想要在应用程序中如何实现HTTP摘要身份验证,Paul James有一篇很好的文章。
The only real problem with HTTP authentication is in the browsers themselves: the UI is terrible, but that can be overcome with some Javascript.
HTTP身份验证的唯一真正问题在于浏览器本身:UI很糟糕,但可以通过一些Javascript来克服。
You can store the passwords securely by storing the A1 hash.
您可以通过存储A1哈希来安全地存储密码。
UPDATE: As mentioned in other answers, while the server can avoid MITM attacks by not accepting Basic auth, the client is still vulnerable because it will.
更新:正如其他答案所述,虽然服务器可以通过不接受基本身份验证来避免MITM攻击,但客户端仍然容易受到攻击,因为它会。
UPDATE: You can't secure data over POST unless you either (a) do encryption in JavaScript on the client or, (b) do everything over SSL.
更新:您无法通过POST保护数据,除非您(a)在客户端上使用JavaScript加密,或(b)通过SSL执行所有操作。
You can, with a little bit of magic, use HTTP auth with forms. The article I linked to above is called 'HTTP Auth with HTML forms', after all. But that won't be done over POST.
您可以通过一些魔术将HTTP身份验证与表单一起使用。毕竟,我上面链接的文章称为“带有HTML表单的HTTP Auth”。但这不会通过POST完成。
If you really need it do use POST, use SSL and salt the passwords in your database.
如果你真的需要它,请使用POST,使用SSL并在数据库中加密密码。
If you want avoid CSRF, I recommend using formkeys, though the idea goes by many different names, I picked up that name from hacking Slashcode for my own use a few years back, which is where I came across it first.
如果你想避免使用CSRF,我建议使用formkeys,虽然这个想法有很多不同的名字,但是几年前我从黑客Slashcode中获取了这个名字供我自己使用,这是我第一次看到它的地方。
#4
You'll spend more time and money rolling your own solution and not be assured that it's secure. Industry standard SSL is easy to implement and far more secure out of the box than you can afford to make your own solution.
您将花费更多的时间和金钱来推动自己的解决方案,而不是确保它是安全的。行业标准SSL易于实施,开箱即用的安全性远远超出您自己制定解决方案的能力。
time == money
时间==钱
Buy a certificate and spend your time working on your application instead of a secure login form.
购买证书并花时间处理您的应用程序而不是安全登录表单。
#5
Client-side encryption is helpless against most MITM attacks. Attacker can simply remove your script.
客户端加密对大多数MITM攻击无能为力。攻击者可以简单地删除你的脚本。
It will only protect against passive sniffing. If that is good enough for you, you can use:
它只能防止被动嗅探。如果这对您来说足够好,您可以使用:
- Hashing implemented in Javascript. It's easy to implement challenge-response for initial login, but don't forget that for attacker session cookie is almost as good as password (you'd have to limit login to single IP and/or use script to generate one-time cookie for every request, which I imagine would be difficult and brittle solution).
- HTTP Digest authentication. More secure, as it can use one-time hashes, mutual authentication, etc., but standard UI is absolutely repulsive.
在Javascript中实现哈希。初始登录时很容易实现质询 - 响应,但不要忘记,对于攻击者会话cookie几乎与密码一样好(您必须限制登录到单个IP和/或使用脚本生成一次性cookie每一个请求,我想这将是困难和脆弱的解决方案)。
HTTP摘要式身份验证。更安全,因为它可以使用一次性哈希,相互身份验证等,但标准UI绝对令人厌恶。
...just use SSL.
......只需使用SSL。
#6
HTTP only solutions will always be susceptible to man-in-the-middle attacks.
仅HTTP解决方案将始终容易受到中间人攻击。
EDIT: A network trace would be an easy way to prove that HTTP isn't secure.
编辑:网络跟踪将是一种证明HTTP不安全的简单方法。
#7
Okay, here's the only answer you need: Your BANK only supports login/auth via SSL. If there was a better way to do it, they would.
好的,这是您需要的唯一答案:您的BANK仅支持通过SSL登录/验证。如果有更好的方法,他们会。
#8
Well, there's some internal discussion about instead doing some kind of roll-our-own client-side encryption of passwords (password + salt, etc.).
好吧,有一些内部讨论,而不是做一些自己的客户端密码加密(密码+盐等)。
The first thing we need to address is data in transit vs. data at rest. From the OP it sounds like the big concern is username/password in the clear over the Internet. So, you really care about data in transit. HTTPS via SSL is a tested method of doing this (and it's a pretty easy fix!). Now, if you really want to roll your own for data at rest (in a db, on a file server, etc.), that's a different beast, but the existing methods for data encryption are going to be better than a roll your own.
我们需要解决的第一件事是传输中的数据与静止时的数据。从OP看起来,最重要的是通过互联网明确用户名/密码。所以,你真的关心传输中的数据。通过SSL的HTTPS是一种经过测试的方法(这是一个非常简单的修复!)。现在,如果你真的想要为静态数据(在数据库中,在文件服务器上等)推出自己的数据,这是一个不同的野兽,但现有的数据加密方法将比自己的滚动更好。
Relying on the client side for your security is bad. Period. In a corporate environment, yes, you can somewhat rely on a standard setup. But, ultimately, users are dumb and you may run into someone disabling javascript or whatever client based solution you roll out, so they end up sending the username/password in plain text anyway (even if your servers dont' know what to do with it because it's not in the expected format.
依靠客户端来保证安全性是不好的。期。在企业环境中,是的,您可以在某种程度上依赖于标准设置。但是,最终,用户是愚蠢的,你可能会遇到禁用javascript或任何基于客户端的解决方案的人,所以他们最终都会以纯文本形式发送用户名/密码(即使你的服务器不知道如何处理它)因为它不是预期的格式。
Roll-your-own is not going to be subject to the scrutiny that an existing solution has. You could end up adding additional security issues into the mix because of the code.
自己动手不会受到现有解决方案的严格审查。由于代码原因,您最终可能会在混合中添加其他安全问题。
#9
We just put out a web/mobile app to do some of this stuff. It creates random URLs for logins, using HTTPS and a hashed/AES encryption method for the database storage. Theres a simple JSON API to use it without our UI, heres our writeup, give it a look.. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it
我们只是推出了一个网络/移动应用程序来完成这些工作。它使用HTTPS和数据库存储的散列/ AES加密方法为登录创建随机URL。这是一个简单的JSON API,可以在没有我们UI的情况下使用它,继承我们的文章,看一看...... http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it
#10
you mentioned doing your own encryption plus salt... I suggest using javascript md5 (it's also used by yahoo on their non ssl pages, or so he claims)...
你提到做自己的加密加盐...我建议使用javascript md5(雅虎也在非ssl网页上使用它,或者他声称)...
And you double hash the password... some may argue that double hashing it would make it prone to collision attacks. I would have to disagree because people have been able to do till now md5 signature collisions only on files, where large amount of data is md5'ed...
你加倍密码密码......有些人可能认为双重哈希它会使它容易发生碰撞攻击。我不得不反对,因为人们至今只能对文件进行md5签名冲突,其中大量数据是md5'ed ...
If it's a big corporate website (and there would be reasons to break in) there is no excuse not using SSL.
如果它是一个大型企业网站(并且有理由闯入),没有理由不使用SSL。