Need guidance on message-digest based password generation algorithms.
July 19, 2011 7:20 AM Subscribe
Need some guidance on message-digest based password generation algorithms.
posted by anonymous to computers & internet (5 answers total)
My sysadmin would like to put together a script or console application that does the following:
1) Reads in a "salt" shared secret / master password.
2) Reads in a computer / server NETBIOS name.
3) Uses a one-way hash to spit out a password by combining the data from steps 1 and 2.
4) Converts the hexadecimal output from the hash into a password of "n" length using a standard Windows NT complex character set.
I have laid out an approach for doing this by breaking the digest into chunks and spitting out acceptable characters, and then using a random number generator seeded by the digest to select a substring and pad the password so that it contains 3 of the 4 required character groups for Windows NT complexity.
I will probably use SHA-2. The sysadmin is *really* focused on hiding the algorithm itself and is entertaining all sorts of hoops we can jump through to fully obfuscate the password. Having just reverse engineered an application that generates salted digests for encrypted storage of passwords in a database (for the purposes of building a self-password-reset service, which got him all interested in digests) I don't think we should be wasting a lot of time building a convoluted algorithm and trying to hide it.
I have every intention of writing this on my free time and releasing it as open-source. In my opinion if the "salt" is sufficiently complex and is protected like any other shared secret, the algorithm will stand up on its own. Just about all respectable encryption/obfuscation techniques are open source, no?
The sysadmin thinks that it's reasonably possible to brute-force the master password / salt if an attacker is aware of the algorithm. I disagree. I think our concerns should lie entirely in protecting the salt itself and making it sufficiently long that it would be statistically impossible to brute force. Sure, somebody could come up with a "collision" that produces the same output but I think that if SHA-2 is used we'll be in pretty good shape and if this is all automated it will be easy to incorporate more effective digest algorithms down the road.
If someone gets an actual password generated by the algorithm, they've got the "end game" (a flippin' password that will allow them into at least one machine with admin privileges) and if they're concerned about reverse-engineering that password to brute-force our hash rather than just using their one compromised machine as a jumping-off-point into the network, we're dealing with a pretty determined attacker and we've got far more to worry about than protecting the algorithm.
If such a breach occurs to our knowledge, we can easily revise the algorithm or create a new salt and push out the new passwords to all machines.
But anyway, I'm seeking your input. Is my method not secure enough? Should I throw in other digests and/or salts (like the date/time the password was generated) or is this just like playing childish spy games? It's fun to write convoluted algorithms but I'm kind of over it at this point.