Return to Answer

You should use a cryptographic hash function: a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone.

To authenticate a user your application will:

• hash the password presented;
• compare the value with the stored hash.

This way, if the password file is compromised, you haven't a massive security breach: the application asks for a password, not for a hash-key and the hacker cannot retrieve the password (the one-way function prevents the original password from being retrieved even if forgotten or lost).

Reverse engineering the hash function / application is not meaningful as there is nothing hidden in your code. The passwords are protected by the complexity of reversing the hash function.

Anyway the hacker could try a dictionary attack using a large list of pre-computed hashes for commonly used passwords. Usually even a small dictionary (or its hashed equivalent, a rainbow table) has a significant chance of cracking the most used passwords.

So the access to hashed password data should be restricted (e.g. see Shadow file for the Unix-like operating systems).

You should use a cryptographic hash function: a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone.

To authenticate a user your application will:

• hash the password presented;
• compare the value with the stored hash.

This way, if the password file is compromised, you haven't a massive security breach: the application asks for a password, not for a hash-key and the hacker cannot retrieve the password (the one-way function prevents the original password from being retrieved even if forgotten or lost).

Reverse engineering the hash function / application is not meaningful as there is nothing hidden in your code. The passwords are protected by the complexity of reversing the hash function.

Anyway the hacker could try a dictionary attack using a large list of pre-computed hashes for commonly used passwords. Usually even a small dictionary (or its hashed equivalent, a rainbow table) has a significant chance of cracking the most used words.

So the access to hashed data should be restricted (e.g. see Shadow file for Unix-like operating systems).

You should use a cryptographic hash function: a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone.

To authenticate a user your application will:

• hash the password presented;
• compare the value with the stored hash.

This way, if the password file is compromised, you haven't a massive security breach: the application asks for a password, not for a hash-key and the hacker cannot retrieve the password (the one-way function prevents the original password from being retrieved even if forgotten or lost).

Anyway the hacker could try a dictionary attack using a large list of pre-computed hashes for commonly used passwords. Usually even a small dictionary (or its hashed equivalent, a rainbow table) has a significant chance of cracking the most used passwords.

So the access to hashed password data should be restricted (e.g. see Shadow file for the Unix-like operating systems).

You should use a cryptographic hash function: a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone.

To authenticate a user your application will:

• hash the password presented;
• compare the value with the stored hash.

This way, if the password file is compromised, you haven't a massive security breach: the application asks for a password, not for a hash-key and the hacker cannot retrieve the password (the one-way function prevents the original password from being retrieved even if forgotten or lost).

Reverse engineering the hash function / application is not meaningful as there is nothing hidden in your code. The passwords are protected by the complexity of reversing the hash function.

Anyway the hacker could try a dictionary attack using a large list of pre-computed hashes for commonly used passwords. Usually even a small dictionary (or its hashed equivalent, a rainbow table) has a significant chance of cracking the most used passwords.

So the access to hashed password data should be restricted (e.g. see Shadow file for the Unix-like operating systems).

You should use a cryptographic hash function: a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone.

To authenticate a user your application will:

• hash the password presented;
• compare the value with the stored hash.

This way, if the password file is compromised, you haven't a massive security breach: the application asks for a password not a hash-key and the hacker cannot retrieve it (the one-way function prevents the original password from being retrieved even if forgotten or lost).

Anyway the hacker could try a dictionary attack using a large list of pre-computed hashes for commonly used passwords. Usually even a small dictionary (or its hashed equivalent, a rainbow table) has a significant chance of cracking the most commonly used passwords.

You should use a cryptographic hash function: a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone.

To authenticate a user your application will:

• hash the password presented;
• compare the value with the stored hash.

This way, if the password file is compromised, you haven't a massive security breach: the application asks for a password, not for a hash-key and the hacker cannot retrieve the password (the one-way function prevents the original password from being retrieved even if forgotten or lost).

Anyway the hacker could try a dictionary attack using a large list of pre-computed hashes for commonly used passwords. Usually even a small dictionary (or its hashed equivalent, a rainbow table) has a significant chance of cracking the most used passwords.

So the access to hashed password data should be restricted (e.g. see Shadow file for the Unix-like operating systems).