Shell How to enter ENTER key in a script

[balanga]

The very notion of a hash of an empty string (i.e. of nothing) is simply absurd, is it not?

I don't really understand what happens, but if I have a 'null' password, that means the password is not set, and I don't get a password prompt when logging in. But when running passwd [ENTER][ENTER], then the password is set, and you do get a password prompt, and this must be registered somewhere, so it can no longer be an empty string. Apologies for my continued confusion, my brain isn't big enough to handle this.

Isn't there some program which will decrypt passwords and show what is recorded somewhere?

 

[zirias@]

Well, I'll try again in a different way, maybe that helps. There are three possibilities of what can be stored in the "password" field of the local passwd(5) database:

• An actual hash of an actual password.
• Some "invalid" string, typically *, sometimes ! is used as well ... any value that is NOT a valid hash is considered a "disabled password", so password authentication is disabled in any case for that account.
• Nothing at all, IOW an empty string. That's what PAM calls a "null password". It means the password is empty/unset, whether authentication is allowed without password can be configured by the administrator.

Now, it's (technically) possible to compute a hash of an empty string and store that hash. I agree with smithi, this is just weird. Still it's what happens when entering "nothing" (by just hitting enter) in passwd(1). I consider this a bug, especially because the nullok option is checked to decide whether this is allowed at all. But when authenticating, nullok only checks for an empty password field, aka "no hash stored".

You can't entirely prevent having a hash of the empty string stored, an admin could always manually store that hash. But IMHO it doesn't make any sense to distinguish that case from the "no hash stored" case, they should semantically be the same: password is empty. I'm still waiting for some feedback on my reviews that attempt to "sanitize" the behavior of pam_unix(8)...

Isn't there some program which will decrypt passwords and show what is recorded somewhere?

The whole point of storing "encrypted" passwords is using a one-way hash function for that, so they can never be decrypted. This prevents instant password disclosure when the password database is ever leaked. Of course it is possible to try offline brute-force attacks on the hashes (by testing millions of passwords...), and older hash algorithms are broken (e.g. md5, which can be cracked pretty quickly).

 

[smithi]

Now, it's (technically) possible to compute a hash of an empty string and store that hash. I agree with smithi, this is just weird.

I can't even see what sort of mathematical hash function could make something from nothing? Silly me?

 

[ralphbsz]

A string hash function takes a variable length string, and turns it into a fixed length hash. Let's do a hypothetical example, a 32-bit (4 byte) hash. The way it works conceptually: Initialize the hash result to a certain value, for example the integer 42 (answer to all questions) expressed in 32 bits. Now, for every byte of the input, perform an interestingly complex mathematical operation. For example, xor the new byte into the lowest byte of the 32-bit hash, then rotate the result by 7 bits (again, I pick a magical constant). This can be done for any number of bytes in the input, including for zero bytes, in which case the result will be 42. The important property is that the length of the hash is fixed (32 bits), independent of the length of the input string, which can be from zero to any number of bytes. Importantly, including zero bytes.

Obviously, this is a very bad hash function, but these kind of bad examples are actually used in CS homework problems when implementing hash tables.

One other comment: We are calling the function here a "hash function", but that is technically incorrect. A hash function is used in building hash tables, and randomizes the placement of objects (here: strings) in a data structure that has only a few places for such objects. Which is not what we're doing; we're instead storing a non-invertible and fixed length summary of the string. That's called a fingerprint, and in some uses it's called a checksum. The concepts of hash function, fingerprint, checksum and several others are overlapping, and they also relate to cryptography and error correction.

 

[zirias@]

One other comment: We are calling the function here a "hash function", but that is technically incorrect. A hash function is used in building hash tables, and randomizes the placement of objects (here: strings) in a data structure that has only a few places for such objects. Which is not what we're doing; we're instead storing a non-invertible and fixed length summary of the string. That's called a fingerprint, and in some uses it's called a checksum. The concepts of hash function, fingerprint, checksum and several others are overlapping, and they also relate to cryptography and error correction.

I certainly understand the wish for some exact wording around these functions (distinguishing them by purpose), that would certainly make sense and enable precise communication, but I'd say this train has left the station ... I guess you know what SHA is the abbreviation for ? – we'll probably have to go with "cryptographic hash" if we want precision in our language ?