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, becaus...
To quantify the strength of OP's approach: if we assume that an attacker knows the day of password creation and that OP was awake for 16 hours, then the millisecond-precision password only has a strength of at most 26 bits. Even if the attacker only knows the month, that is at most 32 bits. This means an attacker will be able to crack the hash on consumer hardware in a matter of minutes or maybe just seconds.
I would assume using urandom I would not even need to use sha256sum at all. I could just use something like cat /dev/urandom | tr -dc '[:alnum:]' | fold -w ${1:-64} | head -n 1 to get a secure random 256bits string?
...Or perhaps I should just use a tool which was specifically designed for this IE OpenSSL
@ThisGuyCantEven: Right, any uniform unbiased way of mapping random binary input to printable ASCII characters works. e.g. hexdump, base64, or just keeping the alphanumeric characters all work fine. The larger the character set, the more entropy you keep for a given length. (e.g. hexdump only has about 4 bits per character, vs. 6 for base64)
Therefore, the hash adds nothing from a security perspective - I wouldn't go that far. If an attacker got a look at the plaintext for one such password, they might guess others were also a hash of something, but wouldn't know what. But if they got a look at a password being a plaintext date, then you'd have leaked your password-generating method. That's something some attackers might not know. You can't or shouldn't rely on them not knowing, so even hashed dates are a terrible method, but plaintext dates would be even worse.
TL:DR: obscurity that doesn't perfectly defend against all possible attackers isn't useless, and shouldn't always be discarded. Layers of obstacles to make things even less convenient for an attacker (before and after what you hope is the main showstopper obstacle) aren't necessarily bad if they don't make things worse for users (non-attackers).
But in terms of analyzing the strength of the password, yes it's appropriate to assume an attacker knows how it was generated. So we can disregard it for this purpose, but I wouldn't say it "adds nothing from a security perspective". It adds nothing in terms of mathematical / cryptographic strength against brute-forcing for an attacker that knows how it was generated, but practical security is a wider area.
Password complexity checker is one of the most useless measure of password strength. In all scenario where my memorized pattern of unique password creation is not allowed, I'm forced to RECORD DOWN my password somewhere, substantially reducing its security. For all other passwords, there's literally no way to determine what the password is because it's all in my head.
@Nelson, eh? What you're forgetting is that the hash database can be stolen and cracked at the attacker's leisure. Someone doesn't need to have the piece of paper you wrote your password on to run a piece of software to try to come up with passwords that hash to entries in the database they stole; but how effective that software will be depends on the amount of complexity in that password. And if you use the same password several places, someone who breaks your password from one stolen database can try that same password with your email address everywhere else.
@Nelson, ...this is not a new technique, and it's been used by real-world attackers for a very long time; if you read The Cuckoo's Egg, you'll see that password files (containing one-way hashes instead of actual passwords) were getting stolen and reversed, and used to break into other systems where the same users reused their passwords, back in the 1980s. If you don't reuse your passwords, don't record them anywhere, and don't use a pattern that's easy to figure out after someone has seen one of your passwords, either you have a very unusually impressive memory or you have very few accounts.
@CharlesDuffy While, much of what you say is useful info, I am not hashing plaintext passwords and storing them in the database. The question was regarding how to generate a strong password, not the best way to secretly store it after the fact.
@Nelson I totally agree that many password complexity rules are sort of stupid and lead people to use less secure passwords because they can't easily memorize one that fits all the rules.... I have no idea why it is so common a practice... I would imagine ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff‌​fff9 would be FAR more secure than $#Wd71&udP, but most checks would prefer the latter which is infuriating... Worse is when they have rules like "cannot contain old pw as substring" (yes I have seen this) which means either they store as plaintext or use an invertible hash.
@ThisGuyCantEven, I was speaking only to Nelson talking about complexity checkers being useless. That said, a lot of work has been put into coming up with better dictionary attacks; nobody does the silly "try every possible 1-character combo, then every possible 2-character combo, etc" approach anymore; instead, they try to intelligently figure out likely passwords to maximize the percentage of hits. If any significant number of people followed the pattern you're doing with fff...f9, then that would be incorporated into hash-cracking tools.
...maybe it already has been; that's not a subset of the industry I keep up on, and GPU-based hash checkers means that they can go through guesses very quickly, so keeping the GPU fed with guessed values to hash becomes a significant bottleneck (again, for real-world serious attackers as opposed to student toy projects).
@ThisGuyCantEven, ...that is to say, "repeat character ${a} ${n} times, followed by character ${b}" only has as much entropy as ${a}, ${n}, and ${b}. Kerckhoffs's principle, &c.
"An attacker may have a good idea of approximately when you generated this password." - Especially if they have access to an unprivileged account on the server, or a backup or something: drwxr-xr-x 3 postgres postgres 4096 Jul 24 18:38:12 /var/lib/postgresql
@ThisGuyCantEven You're probably not the first person to think of using a long password that mostly consists of repeated characters, so it wouldn't be surprising if someone does an attack with a rule for those. The problem with "clever" tricks like that is that you're less unique than you think. People use passwords like "password1" and "Qwertyuiop" thinking that no one would ever guess it and your fffff...f9 scheme isn't much different from that.
@ThisGuyCantEven Also, a site doesn't need to store your password in plain text or with reversible encryption in order to check if your new password is contains the old one. When you change your password, you usually have to enter your old password so they can just use that. Even if they don't have your old password, sites that really care about security might try hashing every substring of your new password and comparing the hashes.
@ThisGuyCantEven My point is that tricks where you create a password that seems hard to guess but doesn't contain much entropy don't work. If you want a strong password, you need to have real randomness. Use randomly generated passwords and store them in a password manager or use some scheme like Diceware if you need to remember them.
Discussion on answer by Kevin: Is a s…
Discussion on answer by Kevin: Is a s…