Talk:End-user Computer Security/Main content/Passwords and digital keys

Add section under "Digital cryptography: security certificates, keys & tokens" entitled something like "PGP signing and encryption for secure communications"?
There isn't any information on how to use PGP signing and encryption for secure communications (such as secure email communication, and secure forum posts). Probably such information should be included somewhere. The aspect of 'security by time passed' in the repeated communication of public keys is covered somewhat in "Broad security principles" (chapter 8)-&sect;"Time based"-&sect;"Based on time passed"-&sect;"Example 2" however, that is only in passing, and not a full exposition on how to use PGP signing and encryption for secure communications.

MarkJFernandes (discuss • contribs) 08:24, 7 May 2020 (UTC)

Add information under "Password security" about how security is affected by the 'keep me logged-in' option (available when logging into online accounts)?
Choosing 'keep me logged-in' can perhaps help to reduce the attack window (and so also the attack surface) associated with the interception of passwords entered during log-in. However, if you accidentally leave your computer unlocked, then it can also leave some of your online accounts exposed that wouldn't be if you had not invoked this option on those accounts.

MarkJFernandes (discuss • contribs) 08:45, 7 May 2020 (UTC)

Add non-incidental content on crypto-shredding and the Heads “Destroy key when attacked” functionality?
The Heads “Destroy key when attacked” functionality is probably something usefully documented in the "Passwords and digital keys based /  Chapter 2" section because it is a good way to secure digital keys. If documenting under the section, having a link to the broader “Destroy key when attacked” security principle (in the Broad Security principles chapter) would probably be a good idea.

Likewise, the practice of crypto-shredding for the purposes of increasing security, probably ought to be also documented in the "Passwords and digital keys based /  Chapter 2" section. For example, a user may encrypt some important asset, crypto-shred the encryption keys, and then only be able to recover the data by relying on their key backups. By doing this, they may have effectively increased the security protecting the asset considerably (at the price of it being more difficult [but not impossible] to recover the asset). Such backup methods perhaps might be good for protecting BitCoin wealth where it doesn't matter if it takes a while to recover the wealth.

MarkJFernandes (discuss • contribs) 16:50, 15 May 2020 (UTC)

The distinction of 'psychic' within the broader topic of 'thought reading and control' is perhaps pointless?
See discussion page for the "Mind-reading attacks" chapter.

"Psychic spying of password" section is missing mention of protection using MFA
Such is missing most likely because it was first thought that it was significantly covered under password encryption. However, that is not the case. Probably a new sub-section should be created to document such protection. After such documentation, probably the "This principle is somewhat related to the later “Protection using password encryption” subsection." footnote, as well as probably the "Also, the use of security tokens (such as USB security tokens[1]) as well as the use of password encryption, can overcome such psychic attacks." sentence, should be accordingly updated and improved. Also, such documentation should link to the "Multi-step authentication and multi-factor authentication" subsection.

If fake keys are added to paper-based keyboard scrambler, use of such fake keys can obfuscate the password capture that mind-reading spies might try?
Essentially, paper keyboard scrambler is extended to include keys outside the keyboard area. When user presses on such keys, nothing is input into the keyboard. Then the user can potentially use such fake key presses, during the typing of their password, to obfuscate the password they think about in their mind.

If password length is 10, alphabet size is 26, and number of fake key presses is 5, then perhaps the password is obfuscated by up to the following factor when attacker knows password length (where factor relates to number of sub-strings attacker will need to try using brute-force method):

$$\binom {15}{5} \times (26^5\times5!) =$$ $$\color{gray}\dfrac{15!}{5! \times (15-5)!} \times (26^5\times5!)$$ $$\color{black}=$$ $$\color{gray}\dfrac{1,307,674,368,000}{120 \times 3,628,800} \times (11,881,376\times120)$$ $$\color{black}=$$ $$\color{gray}\dfrac{1,307,674,368,000 \times 1,425,765,120}{435,456,000}$$ $$ = \color{blue}4,281,572,655,360$$

Perhaps add these ideas to the "Protection using password encryption > Without technology" subsection?

ADD use of deep-fake-resistant media for communicating public keys → §"Non-compromised communication of public keys"❓
Deep-fake-resistant videos (and other media) can perhaps be used to communicate public keys, such that it is difficult to fake such media.

Ideas for deep-fake-resistant technology:


 * Use 3D videos that are perhaps harder to fake.
 * Use camera angle that rotates round.
 * Use famous head of company to communicate key (face that everyone knows).
 * Shoot video in famous location, such as in the centre of New York.
 * Use high quality resolution and audio. The higher the quality, perhaps the easier it is to detect whether it has been faked or not.
 * Use holograms in video, that are difficult to fake.

Further ideas regarding password security
I'm moving closer to the overhaul of my security credential system. Have been using the paper-based keyboard scrambler for a few months now, creating a new scrambler/cipher with a week between different ciphers, or with a longer lapse between ciphers (such as when other activities have taken higher priority). It appears to be effective as well as generally good to use&mdash;seems like sometimes low-tech solutions are the best. Am thinking of using the Google password manager/vault (that comes as standard with Google accounts), to store all of my passwords. I would then also use it to create random strong passwords for all my accounts. Moving the browser window such that suggested strong passwords don't appear on the VDU, seems to be good and to work well. Might make a video about it because it seems to be a really good idea: you overcome ppl spying over your shoulder, ppl spying with hidden cameras, and also spying via interception of VDU electronic signals.

With such a planned set-up, there would mostly only then be one password to remember: the master password for the Google password manager/vault. Some more thoughts about keyed-in passwords:
 * When using a paper-based scrambler/cipher, it doesn't seem so necessary to add "salt" to memorable words or phrases making-up what the user consciously selects in the keying-in of the password; more generally, what the user remembers as the password before scrambling, doesn't need to be difficult to crack. The scrambler/cipher would seem to add the necessary "salt" to what the human person remembers, to make the actual "computer-keyboard-presses password", hard to crack. The user could then perhaps just remember a certain easy-to-remember natural-language phrase to input into the scrambler/cipher.
 * After the user uses the scrambler/cipher, the user can add to the password without the scrambler/cipher installed, for the better defeating of mind-reading password-capture attacks. As already touched upon in §⟪Protection by thinking little⟫, passwords that aren't thought about much during the keying-in, perhaps because of very good rote memorisation, can perhaps defeat mind-reading attacks. The second part of the password, that the user enters without the scrambler installed, can be this other kind of rote-memory password that is keyed-in with very fast key presses. There would then be a two-pronged defence against mind-reading capture of the password: the defence formed by the first part of the password entered using the paper-based scrambler, and the defence formed by the second part of the password entered using rote-memory fast keyboard entry.
 * It may also be a good idea to use copy-and-paste functionality of text never displayed on the VDU (perhaps by using white-on-white text), to add a third part to the password. Even though cryptographic security USB tokens can be used for similar effect, it might be that somehow, the security added by such tokens is defeated perhaps due to there being certain surveillance deliberately monitoring such technology. Copy-and-paste functionality might overcome such monitoring, because adversaries might not be considering the copy-and-paste functionality so much. Copy-and-paste functionality can overcome key-loggers, because recording the key presses associated with using the functionality does not reveal the actual pasted text.

The Google password manager/vault master password in such a set-up would be a particular point of attack. Fortunately, the free security generally available with Google accounts, seems to be good. Things like security alerts concerning unusual logins to your account, help to keep security at a high level. The master password would have to be changed on a regular basis to ensure security. I may just end-up doing it once per week, in tandem with creating a new paper-based keyboard scrambler/cipher each week.

By only needing to remember one master password, and because that password would be used each working day, the password memorisation work would hopefully be much less. In contrast, several passwords that are each used on average just once per month, might take significantly more resources for memorisation, both for all of them together, as well as for any one of them. Practice makes perfect, and repetition each day helps with memorisation.

== Perhaps add info under § ⟪Digital cryptography: security certificates, keys & tokens⟫, about the requirement to keep public-key security certificates up-to-date? ==

Maintaining an up-to-date cache of public-key security certificates is likely important when only using a static historic copy of an OS&mdash;perhaps on a live DVD&mdash;in order that the security of internet communications be maintained. To this end, downloading the latest certificates to some secure storage in such circumstances, perhaps each day, or each week, probably would be a good idea. It may be no use updating the cache just when it is detected that internet communications have become compromised, because downloading the latest certificates with compromised certificates, is open to MITM attack where the man in the middle can keep modifying your downloads so that you only download bogus certificates. When your OS is installed to a rewritable system disk instead (rather than being a static version), the OS will likely apply security updates of its own accord, to make sure its cache of certificates is kept sufficiently up-to-date.

Are collision attacks a serious threat to the security of digital signatures (such as those used for signing firmware)?
The info in the table under the section "Cryptanalysis and validation" of the Wikipedia article on SHA-2, appears to indicate that they might be.

" ... Definitely not formally a security researcher (by any means), but just was wondering whether due to the signatures likely being relatively short, collision attacks (based on hash collisions, where two different messages can produce the same signature? [see https://en.wikipedia.org/wiki/Collision_attack]) could be used to sign rogue firmware components. You could have a small malware program, then bulk it up with "dead" redundant code (doesn't get used) in such fashion that you manage to get it matched to some valid signature. See https://en.wikipedia.org/wiki/Flame_(malware) . ..." - https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=286049&start=50#p1737381