Correct. Characters.
Yes. So I’ll go with base64 encoding and hence 96 bits of salt (I haven’t checked the source code but that’s what the man page implies).
Yes. Unless there is a ‘rounds’ specifier, overriding the default of 5000 rounds of the hash function.
We call it 29 June where I come from.
Non-random, no special characters. Entropy is rather low compared to the alternative.
(Have you tried rubbing your cat against an inflated balloon?)
I use an offline password manager, that also applies a particular algorithm that causes a substantial delay (half a second or so) between typing the unlock password and actually decrypting my passwords. Not sure of the exact technology, but the result is that anyone who wants to try brute forcing my master password is going to be waiting a loooong time for any results.
If you really hate password managers, write your passwords down and store them in a safe place - preferably not with exact details of the accounts they unlock (e.g. ‘bank’, ‘social media’…). Unless you are a likely target for espoinagifiers, the average burglar who breaks in and steals your computer won’t really be looking to crack all your online accounts even if they do take that crucial piece of paper. As always, make sure you have an off-site backup (copy at relative’s house).
Alternatively, you can ditch passwords and move to FIDO2 - once a few websites actually implement it. Then there’s SQRL as another alternative to passwords - with the same chicken and egg problem of adoption.
Another reason why I like pass phrases over passwords.
I could have written down for anyone to find:
Internet banking. Userid 1234567 password 02/03/20
So what does the coding in the password mean?
Page 02, third paragraph, first 20 characters of one of the hundreds of books I have, or a source freely available online, or one of many documents I have in the cloud.
Only I know the source. And can share that source if needed to a trusted other person if needed.
Password change? No problems. Pick another phrase and change the reference.
Sort of. They go all static like.
`
I am aware of one OS family circa 1970-80s that echoed nothing when a password was entered and ‘backspace’ was an acceptable character. Anything on the keyboard excepting ‘enter’ was valid, and for those who knew there was an escape character the password system recognised so one could use ‘enter’ and from memory allowed one to embed spaces. Login details on Hollerith cards were not quite as secure 
For example ignoring the length of this example, ‘123<bksp><bksp><bksp> (enter)’ that today would be a nul entry (zero length) on common systems was OK. as would ‘123<bksp><esc-enter><bksp>’ (enter).
Nor many other alternatives for completing one’s tasks as a user with limited privileges. Basic TTY devices communicated locally with standard encoding (ASCII) and without encryption. Remote dial up connections also transmitted and received keystrokes/characters without encryption. The Commonwealth Bank remote banking service used a primitive form of 2FA that predated RSK keys. Little slips of paper diligently delivered by AP with once only confirmation codes to be used in sequence to verify each transaction.
The greatest risk to any password? Someone looking over your shoulder. Those most paranoid about such things were self evident as they stabbed at the keys. 
They were also mostly point to point excepting the DARPANet and a small number of similar research networks where almost everyone knew everybody else.
I would just like to add to the “password science” and point out an unfortunate trade-off with this.
A system that implements this will typically have a “unique key” against which failures are recorded so that when the limit is reached, the account can be locked.
There are two obvious choices for “unique key”.
Each has advantages and disadvantages.
The disadvantage of the first option is that it may make it easy to mount a DoS attack. This is particularly the case if user account identifiers are guessable or publicly available. This is particularly bad if user account identifiers are email addresses. I can use a publicly available list of spam targets, select the ones that are likely to be in Australia, pick one of the large companies in Australia that uses the email address as the user account identifier, and lock out every account that is valid. (The passwords to use are irrelevant. Just use ‘a’, ‘b’ and ‘c’.) Where the account identifier is, say, a nine digit number, just run through them sequentially.
Of course it is possible for the company to offer some kind of defence against this attack but the attacker can often mitigate it with a DDoS.
So in circumstances where it matters, it is highly desirable not to use the email address as the user account identifier, highly desirable to keep user account identifiers private and not readily guessable, if there’s redundancy in the user account identifier highly desirable to keep the check (digit) algorithm secret, and desirable to use a user account identifier that is long enough to make valid accounts sparse in the space of all user account identifiers (which means that redundancy is desirable).
On the other hand, the disadvantage of the second option is that it directly enables a ‘distributed’ attack to have far more than just 3 guesses. If I can marshal a block of 256 IPv4 addresses then I can get 768 guesses, which against a 4 digit PIN would be uncomfortable. A relatively organised attacker can probably marshal 10,000 IPv4 addresses.
Also, the second option is completely unviable against IPv6 (since I myself have 264 IPv6 addresses, or something around that number of bits, as would most home users that actually have IPv6).
Any server attempting to use the second option with IPv6 is potentially vulnerable to a DoS attack against the mechanism itself, as it tries in vain to store 264 records i.e. in that case, the attacker only makes 2 password attempts from each IPv6 address before changing IPv6 address.
This can be partially mitigated by assuming that IPv6 addresses come in large blocks e.g. absolute minimum 48 bits - and only therefore using the top N bits of the IPv6 address - but the space of IPv6 addresses is still very big.
Not a bad approach but make sure to cover the scenario that the actually used book is lost, stolen or damaged. (The risk is not that someone will therefore manage to use your password - your approach is obscure enough that it will defeat all but state-based attackers. The risk is that you will have lost access to the password.)
You may be able to buy the book again but it might end up being a different edition (text edited slightly) or differ in layout so that page numbers are completely different. Or you may no longer be able to buy the book (out of print).
So making it a book that you can download and therefore backup has some advantages and some disadvantages. If doing this, I would download lots of books so that it is not obvious which book is used.
A “source freely available online” mitigates some of that risk but things that are freely available online have a habit of suddenly disappearing - and could likewise change in subtle inadvertent ways - unless of course you yourself are hosting the freely available online source.
If you are thinking of something like the bible, which is nicely divided for this kind of approach, I would consider that a bit obvious.
I cannot even think why any access system would use your option 2.
However, I agree that email IDs as userids is a bad idea that has unfortunately become very common.
Some systems I have accessed have implemented a temporary lockout to mitigate against DOS attacks. Say 5 unsuccessful access attempts and the account is locked for one hour. A locked account is an uncompromised account. No further attempts are allowed until the lockout period ends.
The tech support will have been alerted, checked the various server and firewall logs, identified the source of the DOS attack, and blocked it.
Since you have details in plain text on your fridge or in a drawer, wherever, then you retain the account ID, and what it applies to. You do not know the pass phrase if your source is lost. Well you would remember frequently used pass phrases since they would be entered frequently and in plain english.
Find a new source of pass phrases, and go through the process of forgotten password resetting for accounts you don’t remember the password for, and change password for those you do, and update your written down references.
King James? Revised Standard? Common English? Good News?
Obviously the more refined reader will go King James every time, but there are still printing differences and occasional errors. I’d quite like a copy of the Wicked Bible.
Unfortunately dictionary attacks can also search for phrases. Definitely do not use a phrase like correct horse battery staple.
Dictionary attacks try single words and variations on a word like capitalization of letters, substitution of letters for numbers like e=3, i=1, o=0. They would be useless against strings of words since the time rises exponentially as each word is added to the pass phrase.
But how does a hacker know how many words are in a pass phrase? They don’t.
They assume someone has used one word and modified it a bit to meet site rules of at least one capital, at least one numeric, and at least say 8 characters.
A dictionary attack would also be totally defeated by made up words.
Ah the memories. IBM 3270 display systems and EBCDIC.
So your password would be hex F1F2F3161616 padded with 40 on the end to make up 7 chars.
Not at all useless. You need to think of each part of the phrase as a single place holder - with a defined type, EG my_dictionary. The longer the pass phrase the greater the number of combinations, password character length restrictions permitting.
As previously commented,
Are we saying that even with a pass phrase there are poor choices and better choices? IE a set of rules which need to be observed to ensure the pass phrase is as effective as a long string of random characters.
Absolutely. Pass phrases have been broken in the past, and are susceptible to dictionary attacks where the data source is aware of pass phrases as a possibility. Even changing a word from “to” to “2” will not help against a reasonably powerful dictionary attack.
Bear in mind that while the English language has hundreds of thousands of words, the average person will only know up to around 35,000 and commonly use probably ten percent of the words they know. Even using the higher number, if a program is able to make millions of comparisons per second then checking for a pass phrase becomes reasonably easy.
And if you’re keen to expand your vocabulary, I recommend reading some Stephen R Donaldson. He definitely enjoys using some of our less common terms (as is recognised in the first paragraph of his Wikipedia page).
If we consider a pass phrase as a set of multiple simple passwords. Each password could be found in a dictionary. We will ignore case, and assume very simple English, no proper nouns, no character substitutions, then the possible keyspace for each word could be only a few thousand combinations.
But a pass phrase of 20 characters could typically have 4 or more words. Even with 4 words we are into the quadrillions of combinations to check. And trying at a rate of, say a billion per second, you’d be looking at a few days to crack.
Make it 5 words and make that centuries.
But put even one word in the pass phrase that is not found in the dictionary then it essentially comes down to a brute force attack on a string of characters of length 20. And in old 7 bit ASCII that is a 140 bit keyspace. Which is orders of magnitude greater than the reported cracking of old 56 bit DES.
There are no reports of cracking AES128 I have heard of, let alone pretty standard AES256.
Going with a dictionary of 35,000 possible words, four words could have 1,500,625,000,000,000,000 possible combinations. In 2020 a computer was able to guess 100,000,000,000 passwords per second. This is clearly not your standard desktop machine, but gives us some sort of benchmark - and is probably your standard desktop in another five years.
So that particular computer would take 15,006,250 seconds to check all possible combinations of four words from a dictionary of 35,000 words. A little under 174 days. Of course, it would have a 50% probability of finding the right combination in half of that time - 87 days.
This assumes a reasonably large dictionary, and a single powerful computer. The dictionary size does not need to shrink much to make the work much more realistic. And if you happen to control a botnet, then instead of running the problem on a single (extremely fast) computer you may be able to farm it out to 100,000 or so routers and other very slow devices that will still solve the problem faster in parallel than your single supercomputer.
Long, complex, random passwords using a large character set are the best passwords right now. Use 20 random characters that include upper and lower case, digits and special characters and your password is secure until a decent quantum computer is built - and depending on the encryption algorithm that is used, may be secure even then.
And as I said, make even one of those 4 words not findable in the dictionary, and your computers will have spent a long time trying, to come up blank.
A 20 character string of plain English with maybe some numerics and punctuation characters that is easy to remember would beat the hell out of a randomly generated string of characters limited to a length of say 10 characters.
And if you make it 20 characters then best of luck trying to remember that string.
One suggestion several of us have made.
Of course is that what everyday users do when they create a pass phrase?
The temptation or is it observed behaviour, is that those less aware will always follow the KISS principle. Even if forced to by the PW checker to use at least one capital and one number, odds are it’s the first letter of the first word in the phrase that will be a capital with the number added to the end.
Does a brute force attempt need to use a complicated algorithm and very large dictionary to be successful? A smaller dictionary will not break the clever and well informed. It will however be much faster (minutes) against predictable human behaviour than the suggested better choices.
P.S.
My more important PW’s use a combination with at least one long and one unfamiliar word, randomised capitals and at least 2 strategically placed numbers. Special characters only if permitted. Not all logins permit special characters, and fewer require them. Each is unique.
