This is password protected, so then an attacker must crack the password. The author exchanges the password over a phone call, which requires the password to be relatively weak, meaning the password is probably crackable.
Exchanging the password via a second channel that the other user can copy and paste a more difficult password from to decyrpt the document might be more secure. The password may be more exposed, but an attacker would have to compromise both channels. Basically use two messaging platforms (one of which could be email) ideally where at least one channel is sent encrypted. For example if the other party is using their mobile phone to view the payload they should have a messaging app to copy and paste from that is at least encrypted in transit if not e2e.
This is not meant as a solution. It's a demo of a self-contained, self-extracting, portable encrypted file.
That said, the password strength and the strength of the side-channel to transmit it depend on your use case.
If we were friends for example, I may not need to send you a password at all.
I could just add some secret questions we both know in the hint.
Or, at the opposite side of the spectrum, I could send you a secret as email attachment and *include the password in the email itself*.
This adds zero security in certain scenarios, but for example it keeps Google bots out of your private correspondence. Which is all I want sometimes.
Challenge: make it possible to use something like Diffie Hellman[0] to exchange a key securely even over an unsecure channel but where they resulting key is actually the password to type in and "reads" like https://xkcd.com/936/ i.e. something my grandma could type in. Without reducing the key space too much to be insecure ;)
Passwords being transmitted over a voice call does not equate to a weak password. You can very easily communicate 4-6 English words outside the 10,000 most common to produce a password with 49-83 bits of entropy. And most people will have just as easy a time remembering 5 words as 5 alphanumerics, if not easier.
It does not mean the password needs to be weak at all. Make it a full sentence with punctuation, like:
"Don't you hate passwords that need a number and symbol?"
Easy enough to transmit over the phone and definitely more difficult than the ubiquitous "Password1!" that most people I know end up using to meet password "security" requirements.
Also, phone exchange can be preferable for many people who are less tech comfortable
28 words would be about 200 characters, though, and I don't think simply existing somewhere in plaintext is enough -- what if I said it is the first 28,000 words of the Latin Bible -- would you still consider that a weak password because it exists in plain text somewhere?
I took a list of "2000 most common English words" used metaphopne to eliminate words that sound similar to other words on the list, and reduced it to a power of 2. I ended up with 512 words that are probably in all fluent English speakers vocabularies so can easily be read over the phone. It's 9 bits per word, so 7 words is 63 bits of entropy which means it's (on average) 2^62 times more computational work to brute-force than it is do decrypt. That's a pretty good margin to have.
If they were using a stupid hash like, say, MD5 the time to brute force that would still be months on a GPU, but they are using PBKDF2/SHA-1 which is significantly more work.
There is nothing requiring the password to be “weak”. It can be a strong password generated with a random number/strong password generator. Sharing a string of characters or a “weak phrase” is no different if reading it to the person.
The author recommends the use of XKCD correct-horse-battery-staple style passwords (aka diceware), which have a high ratio of entropy to ease of transmission effort.
In other words they're relatively easy to exchange over a phone call but still secure.
