Is a sha256 hash of a unix timestamp a strong password

Question

I am setting up a postgres db that will never be used by humans. In fact, I really don't need to know it myself ever. I assumed that just using a 256bit(64 alphanumeric chars) hash of a unix timestamp IE:

date +%s%3N | sha256sum

A very important detail is I am not "hashing a password"... I am hashing a timestamp and using the sha256 hash as the password in the db connection string.

would be pretty damn strong. An example of one I could use has 31 lowercase chars and 33 integers, for an entropy of ~330 bits, which is.... well... I'd say pretty damn solid, if not completely insanely overkill. The reason I ask is because it STILL got flagged by chainlink's password complexity check for only having lowercase chars and numbers.

So... My question is, are they right? Is there something wrong with a 64 character alphanumeric password just because it doesn't have fancy capital letters? Is there something inherently wrong with using sha256 algo with a timestamp like this?

I am contemplating raising an issue on their github stating that I should not have to set their SKIP_DATABASE_PASSWORD_COMPLEXITY_CHECK=true flag for such a password, and that they should consider the actual entropy of the password instead of just applying a set of simple rules.

Answer 1

... for an entropy of ~330 bits, ...

The question is not how strong a password looks like but how strong it actually is. SHA-256 does not add any entropy at all, so it all depends on what the input to SHA-256 was. And the entropy of the chosen input is pretty low: Assuming that the attacker knows how the password was created, they can test all possible inputs around the time the password might have been created.

A much stronger input would be to use real random data as input:

dd if=/dev/random bs=1 count=32 | sha256sum

While the output might look similar strong, it is practically impossible to predict the input by the attacker.

Answer 2

Password complexity is not a matter of having a bunch of random-ish characters.

The purpose of password complexity is to make your password harder to guess, not to make your password "look random." As a result, password complexity meters are not a good way of measuring password complexity, because it is simply not possible for a computer to figure out how an attacker will go about attacking your password.

Similar to Kerckhoffs's principle, it is good practice to assume that the attacker knows how you generated your password. Even if you don't like that assumption, you have now revealed this method in a public forum, so a resourceful attacker could find this Stack Exchange question and deduce that you have used this method to generate passwords.

Under that assumption, this method is potentially problematic. For starters, the SHA-256 hashing algorithm is public knowledge, so if an attacker can guess the input you used, then they can easily compute the hash of that input. Therefore, the hash adds nothing from a security perspective, and may be disregarded (besides which, the database should be doing its own password hashing on top of your sha256sum, and their hashing is probably a lot more thorough than that). Your question is equivalent to "Should I use the output of date +%s%3N as a password?"

An attacker may have a good idea of approximately when you generated this password. Your method does go to millisecond precision, so an attacker must try 1000 guesses for each second of uncertainty. But the exact time that you set up the database is probably not a secret! Or at least, you're probably not going to treat it like a secret. Unless you generate the password months in advance (which I doubt), there are all sorts of people who might plausibly know when you set up the database, such as:

• Coworkers or colleagues.
• The hosting provider, if any.
• Your own provisioning system or other records.

In conclusion, this is a bad plan and you should not do it. Generate your password from scratch using a cryptographically-secure random number generator instead, such as using the code in Steffen Ullrich's answer.

Answer 3

To bring some of the answers together in a more concise way. The short answer is NOT AT ALL.

The reason is that the entropy of the UNIX timestamp is entirely dependent on the time interval an attacker can assume contains the timestamp, once they've determined this was the method used for generation. If they know the date, they can generate every sha256sum that could be created within that window in a matter of seconds. Even if they only know within a 30 day interval, they could guess all the hashes in a few mins.

The correct way would be to use a cryptographically secure RNG to generate the password. One linux native option would be to use urandom to generate a 256bit string of utf8 chars IE:

cat /dev/urandom | tr -dc '[:alnum:]' | fold -w ${1:-64} | head -n 1

Another (more secure) option would be to use a tool specifically designed for generating secure random keys (IE OpenSSL):

openssl rand -base64 48

Answer 4

There are so many misconceptions about passwords and security, and many of them are in this question.

tl;dr: Your choice is weak and predictable.

The main thing a password should be is not complex or full of special characters or anything like that, but hard to figure out. That's why your name is a bad password, even if you have a long name full of foreign accent characters. If you have such a name, go ahead and put it into five or six of the "online password strength metres" you find in Google and half of them will probably tell you that's a good password. It clearly isn't.

First of all, what is your threat model? - or in simpler terms: What is it that you are defending against whom? Is this database your personal gym log that nobody really cares about, including you; or is it your $200 Mio. crypto currency wallet, the only photographs of your late grandmother or a commercial database where people could lose their jobs? All different scenarios with different use cases and different levels of "secure".

We don't know your use case, so we can only give you generic advise:

• The hashes might look random, but they aren't. In fact, they are perfectly predictable by anyone who knows your method. You could just as well use the timestamp directly and I think you'd agree that's a crappy password.
• Generating a random password (simply get /dev/urandom) would be a much better idea. Among other things you can map it to the whole ASCII space, not just 0-9a-f. It's also not predictable.
• Why would you want to use a timestamp at all? Does it serve a purpose? Or is it just a cheap source of randomness? In which case, why don't you use a real source of randomness?
• If you thought of putting all that into a script, you've probably shot yourself in the foot as that makes it a) easy to find for an attacker who managed to get some level of access and b) highly predictable because with a bit of log or bash_history reading, said attacker can probably make an educated guess at when that was executed and narrow down the possible timestamps to be within reasonable brute-force territory.

So please do what every install script does: Simply generate a random password of sufficient length.

Finally:

I am contemplating raising an issue on their github stating that I should not have to set their SKIP_DATABASE_PASSWORD_COMPLEXITY_CHECK=true flag for such a password, and that they should consider the actual entropy of the password instead of just applying a set of simple rules.

Before doing that, please check the actual source and you'll find that your hash should already pass the checks almost every time (except the one-in-a-million where the hash is completely numeric or alphabetical). Unless your distro includes CrackLib, there isn't really much checking going on and the functionality is included as an example so you can write your own checks.

Answer 5

There's a lot of moaning about how you're deriving your password. It is a little suspect but answers assume an informed attacker. Depending on the value of the thing being protected, it's likely fine. Even if you sourced the password from the most complex of randomness, if it randomly spat out only lower case letters, your actual question would still stand.

"Does the password contain [x,y,z]?" is easier to program and explain to users than entropy. So we're left with a well meaning but ultimately blind set of rules. Is randomly choosing only lower case letters from a larger set less good? Against, the attacker that is playing by the original rules, it's exactly the same. It does open one to an attacker playing by a lesser set of rules. But there is a password length which is likely too much to guess by anything other than an offline attack, if that.

Should the project loosen their standards? Probably not when the user could instead add an instance of each missing type to the end of the password instead. Or in this case choose an encoding which likely has all of the required character types (Base64?).

Answer 6

No, and not because of the Unix Timestamp. A hash digest is a hex string.

A hash digest has a limited character set (16). This is low hanging fruit for a brute force attack.

An informed attacker need only cycle through timestamps from time a to time b, given he can ballpark the year(s) of the timestamp this may be trivial.

In addition, it will be hard to remember, and therefore likely to be exposed by saved copies, vaults notwithstanding.

However it is suitably complex for a database connection string and transport neutral. Providing you secure access to the database with a tunnel to a private endpoint that is also firewalled, it is OK.

You would not use the unhexed value as it may not be transport neutral and may lead to unpredictable translations, escape sequences also notwithstanding.

The key here is not to share how this is generated at all, your own people would prefer not to know, as it grants the gift of plausible deniability.

A string is a string is a string. Too many academic answers here. If you do not tell anyone, it is not predictable. I defy anyone given a arbitrary hex string to reverse engineer the document it was generated from.