Join 3,494 readers in helping fund MetaFilter (Hide)


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.

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.
posted by anonymous to Computers & Internet (5 answers total)
 
Other than being able to always generate the password for a given machine/master-salt combo, what is the end goal ? Not having to remember any password, since you can always re-run the algorithm ?

I wouldn't bother trying to argue this is a secure way to generate passwords. There are better ways to generate secure, random passwords. This is not one of them.

Also, if you plan to use the end-bytes to generate a password, you know there won't necessarily be ASCII characters there, right ? How you do plan to "type" some of the characters in that you generate ? And you'll pad it to make it group-policy acceptable ?
posted by k5.user at 8:02 AM on July 19, 2011


what's your actual goal here? are you planning on using the generated strings as the admin passwords on newly deployed machines?

you don't want to be designing your own crypto, even if you're using trusted building blocks - amateurs messing up the key schedule is one of the reasons WEP sucks as hard as it does.

I would take a known & trusted algorithm and use that. assuming you're generating passwords for new machines, a standard HMAC would do the job. m, the message, is your machine name. K, the secret, is your secret. OpenSSL implements hmac(3) so you don't need to implement anything other than a wrapper yourself (pass EVP_sha1 as evp_md to get a modern SHA hash as the H() function).

take the output and turn it into passwords (use it as a baseN index into the list of valid characters or something?).

assuming nothing gets bollixed up in the wrapper your sysad writes, strength of the output will be based on the secret you use. a decent secret (> 1024 bits, or more if you're paranoid) will provide all the bruteforce protection you need.
posted by russm at 8:09 AM on July 19, 2011


Reads in a "salt" shared secret / master password.

I'm not sure why you are calling this a "salt". For something to be a salt in the context of encryption, it has to be random and unique to that particular session. The point of a salt is to prevent things like rainbow tables from being used to speed up an attack by making sure that the plaintext always has some completely random element.

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.

Seems unnecessarily complicated.

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?

You are rolling your own security mechanism here, which generally leaves you open to a lot of very basic attacks because you invariably didn't think of everything. The idea of making widely-used encryption algorithms open source is that there are a lot of eyeballs to analyze everything and figure out every possible flaw. Nobody is going to do that for your solution, other than maybe someone who wants to compromise your system.

If someone gets an actual password generated by the algorithm, they've got the "end game"

As others have said, what is the point of all this? You seem to want to have a way of knowing all of the passwords for these machines. If there are actual users who use these passwords to log in, best practices dictate that you just keep hashes of the passwords, and if a user forgets their's you just reset it. That way it's impossible for anyone to get any kind of full access to log in to any machine. With your proposed system, assuming that this program and the master key are stored on a single machine somewhere, you don't have any more security than a scheme where you simply generate random passwords and store them in plain text on that same machine.
posted by burnmp3s at 8:22 AM on July 19, 2011


You seem to have a serious misunderstanding of what a salt is.

A typical implementation for storing passwords is: The salt is stored in plain text, but it doesn't matter, it's just a random number. The purpose of a salt is to make it less likely that two people who use the same password will have the same hash, and to make it difficult for attackers to pre-calculate the hashes for commonly-used passwords.
posted by 1970s Antihero at 10:52 AM on July 19, 2011


I apologize for omitting the end goal -- that's one of my pet peeves, when folks present a highly complex solution to a problem they haven't yet described. My bad. I'm not entirely sure why I posted this as anonymous at this point but russm would get "best answer!"

The end goal is to have a simple method for generating (and quickly re-generating if adjustments are needed) local admin passwords that are unique to every machine.

k5.user: can you be more specific in explaining why this wouldn't be secure? I can lay out the entire algorithm but I might just stick with HMAC. Basically I would define my character set ([a-z],[A-Z],[0-9],symbols), break the hash into chunks that I can use to create a password from my character set by simply adding up the hexadecimal values for each chunk (this is one area where I see a security risk but I'm having a hard time identifying it beyond a gut feeling), and then pad the password out with deterministically "random" characters from the appropriate sub-sets of characters (upper, lowercase, numbers, symbols) if necessary.

russm: Thanks, I will check out HMAC!

burnmp3s: is invoking "rand" with a seed really that complicated? What would you suggest instead? I've seen password generators that always append "1a" but using a pseudo-random number generator with the hash as its seed doesn't really strike me as complicated in the least bit.

Everyone else: sorry for "seriously misunderstanding what a salt is." When a highly specific or technical term is surrounded in "quotes" that's your cue that the person is quite aware that they may not be employing the term to your exacting specifications with utmost confidence and you don't need to swagger and condescend to get your point across, and you might be more successful if you can restrain yourself from doing so.

In the context I'm using, it's "data you throw into a hash besides the clear text to increase complexity."

The machine name itself is "salt" in this context too too. I realize that it's not a perfectly random number (they don't exist, for one) but it is unique. Is there a better term for what I'm describing?
posted by aydeejones at 3:34 PM on July 21, 2011


« Older Looking for dresses that are b...   |  Is it normal or ethical for a ... Newer »
This thread is closed to new comments.