Hi guys

I have a problem regarding the unix password encryption.There are already some posts regarding the same thing. The entry in the shadow file will be of the kind

root:$1$taz7zdm9$.7G.Y/oMF0npHiFozUngk1:13857:0:99999:7:::

as 1 represents MD5

taz7zdm9 represents salt

.7G.Y/oMF0npHiFozUngk1 is actually encrpyted hash which uses MD5.

According to my knowledge MD5 message digest is in hexadecimal but the encrypted hash is in base 64.

I want to know the combination in which password + salt are hashed or to be precise I just want to know the encryption process behind the scene which results to the encrypted hash.


I have see in a link which is not clear...i.e.,
in the article we have..

MD5-based scheme

Poul-Henning Kamp designed a baroque and (at the time) computationally expensive algorithm based on the MD5 message digest algorithm. MD5 itself would provide good cryptographic strength for the password hash, but it is designed to be quite quick to calculate relative to the strength it provides. The crypt() scheme is designed to be expensive to calculate, to slow down dictionary attacks. The printable form of MD5 password hashes starts with $1$.

This scheme allows users to have any length password, and they can use any characters supported by their platform (not just 7-bit ASCII). (In practice many implementations limit the password length, but they generally support passwords far longer than any person would be willing to type.) The salt is also an arbitrary string, limited only by character set considerations.

First the passphrase and salt are hashed together, yielding an MD5 message digest. Then a new digest is constructed, hashing together the passphrase, the salt, and the first digest, all in a rather complex form. Then this digest is passed through a thousand iterations of a function which rehashes it together with the passphrase and salt in a manner that varies between rounds. The output of the last of these rounds is the resulting passphrase hash.

The fixed iteration count has caused this scheme to lose the computational expense that it once enjoyed. Variable numbers of rounds are now favoured.



so guys please help me out...its urgent...

Thanks in advance....

Wow - I've never seen a more convoluted and just plain WRONG description of the password hash. It doesn't actually tell you how the hash is produced.

You don't have to know the details of producing the hash; you can simply use the 'crypt()' routine (with the GNU extensions) to produce a hash (man crypt):

1. come up with a salt - it must start with $1$ to indicate the GNU extension, followed by 1 to 8 characters (you can only choose from A-Z, a-z, '.' and '/'), terminated by '$'

2. make up a password - how long the password can be depends on the particular version of the login software that you use. The password may contain ANY printable character (whitespace characters like space and tab, are not considered 'printable' for this purpose)

3. Invoke 'crypt' (you may need to link to -lcrypt) to produce the hash:
char *myhash = crypt("mypassw0rd", "$1$myhash$");

If you really want to know how the hash is produced, go read the source for 'crypt' (or find a website which explains the thing properly, not heaping you with numerous fuzzy meaningless statements like the one you quoted above).

Wrong? Really??? Do you understand how hashing algorithms work, especially as they're applied to authentication mechanisms? MD5-based password hashing algorithms typically are not a plain application of the MD5 algorithm. That would be too easy to brute-force.

Before you go telling everyone what's wrong, you might want to understand what you're talking about.

When you implement the password MD5 hash based on the cockamamie "description" in the quote, then I'll change my mind about that description being wrong.

It would be greatly appreciated if you could elaborate a bit about what you consider to be wrong with the Wikipedia quote which was posted. Is it something technical, or is it the manner in which it was written? Perhaps both? Please shed some light on what exactly you meant.

What is wrong about the quote is that, as verbose as it is, it teaches you absolutely nothing about md5crypt. I could quote random phrases from the bible and it would be just as meaningful and as instructive of the mechanism of md5crypt. What is the point of words in a technical setting if you learn nothing from them? I have solved many fairly complex equations in my field, but I never attempt to describe my work with "then I solve these arduous equations" because that imparts no knowledge. Instead I seek to show equations in a sequence which would make it obvious how the final solution was produced.

Albert Einstein reputedly said something like "Always explain things in the most simple way possible, but no simpler". The quote in question is in the "too simple" category. It is unfortunate that many people these days accept such vapid explanations. It is certainly not a new phenomenon though; an old Belgian friend of mine has a funny name for the phenomenon (which he uses to annoy me) - he calls it the "American Manual" phenomenon. His explanation is that English (UK) and French manuals are well-written and explain the principles behind the functions of a device in a clear and easy to understand manner; American manuals on the other hand are filled with numerous pages explaining the most trivial things and the most important concepts are waved aside with half a phrase.

Uhh, it's already implemented that way, so what's your point? The information was technically accurate, and does describe the steps involved. It's not meant to teach people who to implement their own password hashing algorithms (that would be stupid, rule #1 of cryptography is "don't write cryptographic algorithms if you're not a cryptographer"), it's meant to give people the basic idea of how it works.

If the person interested in knowing the workings of a specific implementation had the skill to comprehend it, they would have already known to look at the source code, or any number of published research papers on the topic, so I don't see what you're so upset about.

More to the point, you should not be calling an accurate description "wrong". It wasn't wrong factually, you just didn't like the explanation. Your personal preference doesn't influence the factual truth of the description.