Open shellster opened 4 years ago
Or we could drop the GUID and go for that function entirely. 200/8 seems like a decent length.
$bytes = new-object 'System.Byte[]' (200/8)
(new-object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($bytes)
(new-object System.Runtime.Remoting.Metadata.W3cXsd2001.SoapHexBinary @(,$bytes)).ToString()
:)
Sounds good. Though, in that case, for sure it is probably a good idea to check for collisions, however rare they may be.
I feel terrible, since I suggested moving to GUID's for ID's. GUIDs are guaranteed unique, and as of UUID Type 4 which is what the New-GUID method in Powershell uses, they are not directly tied to the network MAC address, however, they are seeded largely from values that are known, or could become known to an attacker. Should an attacker know when a password was generated, they can conceivably narrow down possible GUID's to a fairly small range. The consensus is that UUID's are not unguessable and should not be used for passwords (or things that lead to passwords): https://stackoverflow.com/questions/643445/how-easily-can-you-guess-a-guid-that-might-be-generated
I know we are moving into the theoretical here, but it might be good to additionally add 8 hex bytes from a CRNG to the end of the string with something like this: https://github.com/virtualox/Get-RandomHex/blob/master/Get-RandomHex.ps1
The above change should ensure that the ID is unique, un-guessable, and long and unique enough that it cannot be enumerated even by an attacker with significant information about the environment that it runs under.