A question recently came up asking why the -eq operator doesn't work for two different (but equal) SecureStrings.
By default, almost all environments (the .NET Framework included) test if two things are exactly the same – that they are stored in the same place in memory. This is called reference equality.
[D:\documents\WindowsPowerShell]
PS:14 > $test = Read-Host -AsSecureString
****
[D:\documents\WindowsPowerShell]
PS:15 > [Object]::ReferenceEquals($test, $test)
True
[D:\documents\WindowsPowerShell]
PS:16 > $test -eq $test
True
That’s not usually what people want, so each individual type of object is (optionally) responsible for supporting a value-based equality test. They do this by implementing interfaces (software contracts) called IComparable and / or IEquatable:
[D:\documents\WindowsPowerShell]
PS:17 > $string1 = "Test"
[D:\documents\WindowsPowerShell]
PS:18 > $string2 = "Test"
[D:\documents\WindowsPowerShell]
PS:19 > [Object]::ReferenceEquals($string1, $string2)
False
[D:\documents\WindowsPowerShell]
PS:20 > [String].GetInterfaces()
IsPublic IsSerial Name
-------- -------- ----
True False IComparable
True False ICloneable
True False IConvertible
True False IComparable`1
True False IEnumerable`1
True False IEnumerable
True False IEquatable`1
[D:\documents\WindowsPowerShell]
PS:21 > $string1 -eq $string2
True
The implementors of the SecureString class have chosen to not implement these contracts, so PowerShell supports only reference equality on these types:
[D:\documents\WindowsPowerShell]
PS:30 > [System.Security.SecureString].GetInterfaces()
IsPublic IsSerial Name
-------- -------- ----
True False IDisposable
[D:\documents\WindowsPowerShell]
PS:31 > $test1 = Read-Host -AsSecureString
****
[D:\documents\WindowsPowerShell]
PS:32 > $test2 = Read-Host -AsSecureString
****
[D:\documents\WindowsPowerShell]
PS:33 > $test1 -eq $test2
False