I'm working on a small personal project that involves a user entering a password that would then allow them to view a text file that would otherwise be encrypted.

I'm having trouble wrapping my head around storing the password somewhere so that the program can authenticate that it has been entered correctly If I can't guarantee 100% uptime. If I save a default password as a string literal wouldn't it be possible to un-assemble the binary file so as to find it? I'm writing this in Go if it's of any relevance.

2 Answers 2


Don't store the password anywhere at all. Instead, derive a key from it and use that key to decrypt the file. You can store a sentinel string at the beginning of the file and check for it after decryption. If the sentinel is not there, the provided password was wrong or the file has been corrupted. The value of the sentinel need not be kept secret.

Storing the password, no matter how obscured, within the realm of the person who is about to authenticate provides no security at all.


You should never store a password or hash mask (or salt) directly in your code. For the reason you already stated: someone will decompile your code to source. Then they will have the password.

A Couple of Simplish Ways

You can run your password through a one way hashing algorithm and save the results of that somewhere (maybe in a database). You could easily write this method yourself. It could be as simple as XORing every character in the password string with a sequence of semi-random characters. It could be more complex (e.g., Cyclic Redundancy Checks). Neither of these methods would stand the harsh scrutiny of a code breaker.

A More Complex Method, But Safer

This is where you start to get into cryptographically safe hashes.

A cryptographic hash function is a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone. These one-way hash functions have been called "the workhorses of modern cryptography".


Storing all user passwords as cleartext can result in a massive security breach if the password file is compromised. One way to reduce this danger is to only store the hash digest of each password. To authenticate a user, the password presented by the user is hashed and compared with the stored hash. (Note that this approach prevents the original passwords from being retrieved if forgotten or lost, and they have to be replaced with new ones.) The password is often concatenated with a random, non-secret salt value before the hash function is applied. The salt is stored with the password hash. Because users have different salts, it is not feasible to store tables of precomputed hash values for common passwords.

Some Help

Thankfully, Go has implemented a version that is closer (I am no expert on Go) to the cryptographically safe hashes in the Go Crypto package.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.