安全使用SecureString的用于登录表单 [英] Safe use of SecureString for login form

问题描述

因此，有这个类，似乎很少使用： SecureString的。它已经出现自至少2.0，并且有它的几个SO问题，但我认为我会问我自己的具体问题：

So there's this class that seems very seldom used: SecureString. It's been around since 2.0 at least, and there are a few SO questions on it, but I thought I'd ask my own specific questions:

我有一个LoginForm的;简单的WinForms用户名和（屏蔽）密码字段对话框。当用户输入都和点击登录时，信息被传递到执行层注入认证类键拉伸，然后散列验证拉伸键的一半，而另一半是用于加密的用户的对称密钥帐户数据。当这一切是通过，在登录表单被关闭时，设置认证类，系统转移到装载的主要形式。漂亮的标准的东西，也许有点比标准的哈希的密码和-比较更复杂，但简单的哈希密码会在我的情况通过存储明文的用户数据被打败的，因为该数据包括了三阶凭据。政党制度（我们都知道人们怎么想重用密码）

I have a LoginForm; simple WinForms dialog with username and (masked) password fields. When the user enters both and clicks "Login", the information is passed to an injected authentication class that does a layer of key-stretching, then hashes half of the stretched key for verification while the other half is the symmetric key for the encrypted user account data. When all this is through, the loginForm is closed, the authenticator class disposed, and the system moves on to loading the main form. Pretty standard stuff, maybe a little more involved than the standard hash-the-password-and-compare, but the simple hashed password would be defeated in my case by storing the user data in plaintext, because that data includes credentials for a third-party system (and we all know how people like to reuse passwords).

这是第一个问题;我将如何使用SecureString的从文本密码找回密码，的没有的它暴露通过文本框的Text属性是普通System.String？我认为有访问非托管的GDI窗口，针对要由CLR类包裹的文本框，并使用Marshal类拉文本数据的方式。我只是不知道怎么了，我似乎无法找到好的信息。

Here's the first question; how would I use SecureString to retrieve the password from the Password textbox, without it being exposed as an ordinary System.String through the Text property of the textbox? I assume there's a way to access the unmanaged GDI window for the Textbox that's being wrapped by the CLR classes, and pull the text data in using the Marshal class. I just don't know how, and I can't seem to find good information.

下面是第二个问题;一旦我有密码作为SecureString的，我怎么把它传递给来自System.Security.Crypto命名空间的哈希供应商？我的猜测是，我会使用从返回的IntPtr Marshal.SecureStringToBSTR（），然后Marshal.Copy（）返回到一个字节数组。然后我可以调用Marshal.ZeroBSTR（）来清理非托管内存，我可以归零与Array.Clear（）管理的阵列一旦我有哈希值。如果有一个更清洁的方式，让我在记忆中的任何管理副本的寿命完全控制，不要告诉

Here's the second question; once I have the password as a SecureString, how do I pass it to a hash provider from the System.Security.Crypto namespace? My guess is that I'd use Marshal.SecureStringToBSTR(), then Marshal.Copy() from the returned IntPtr back into a byte array. I can then call Marshal.ZeroBSTR() to clean up the unmanaged memory and I can zero out the managed array with Array.Clear() once I have the hash. If there's a cleaner way that allows me full control over the lifetime of any managed copy of the memory, do tell.

第三个问题;难道这一切真的有必要，或者说是System.String固有的不安全感在托管内存环境有点夸大？用什么来存储密码，加密或其他方式的应的出的范围，并在它的方式对垃圾收集很久以前的操作系统会考虑交换应用到虚拟内存（使密码嗅探从交换文件后，计算机的硬关机）。冷启动攻击是一种理论上的可能性，但实际上，有多普遍是这样吗？更大的问题是现在解密的用户数据，从而徘徊在用户的整个应用程序生命周期的一部分（并因此将使用SecureStrings，因为除了一对夫妇的基本用法他们保持相当蛰伏的主要候选人）。

Third question; Is all this really necessary, or is the inherent insecurity of System.String in a managed-memory environment a little overblown? Anything used to store the password, encrypted or otherwise, should be out of scope and on its way to the garbage collector long before the OS would consider swapping the app into virtual memory (allowing the password to be sniffed from the swap-file after a hard shutdown of the computer). A cold-boot attack is a theoretical possibility, but really, how common is this? The bigger concern is the now-decrypted user data, which hangs around as part of the user for the entire application lifetime (and thus would be a prime candidate for using SecureStrings, as except for a couple of basic usages they stay pretty dormant).

推荐答案

如果您认为您需要 SecureString的你必须相信，一个攻击者可以读取你的进程的内存了。如果是后者，他可以读取密码字符，因为它们都可以直接键入，或者从文本框内部字符缓冲区中读取，或读出屏幕像素。

If you believe that you need SecureString you must believe that an attacker can read your process memory, too. If the latter is true he can read the password characters as they are typed, or read from the textbox internal character buffer directly, or read pixels off the screen.

这是一个不切实际的场景。不要使用 SecureString的。它可以帮助一点，偷了你的时间。

This is an unrealistic scenario. Don't use SecureString. It helps little and steals your time.

冷启动攻击也更加真实，但非常少见。他们需要通常完全拥有机物理机的访问。的阅读的攻击者是至少在这种情况下，你的顾虑。

Cold boot attacks are more real, yet extremely uncommon. They require physical machine access which usually totally owns the machine. Reading by the attacker is the least of your concerns in this case.

基本上，你有图谋的情况下您的开发商时间使用 SecureString的用得其所。

Basically, you have to contrive a case where your developer time is well spent using SecureString.

这篇关于安全使用SecureString的用于登录表单的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！