how actual the password is hashed in linux
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). |
Quote:
Before you go telling everyone what's wrong, you might want to understand what you're talking about. |
Quote:
|
Quote:
|
Quote:
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. |
Quote:
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. |
All times are GMT -5. The time now is 07:54 PM. |