But you get the Google knowing so much about you experience when going to sites that you do not have a login for anyway.
So that is the Internet and the all pervasive Googleverse and as long as my banking and tax and other key sites are separately protected by unique logins and passwords and 2FA I couldn’t care about Google.
No I don’t. I use another search engine, block third party cookies, and block Google/Facebook/Twitter trackers on websites.
I also have a plugin that blocks Google Analytics - although since it comes from Google I cannot be entirely sure that the label correctly describes what it does. (Google would of course get into a lot of trouble if the plugin was not doing what it describes.)
Yes, I was guilty of re-using passwords until I developed a system for having unique passwords that I could easily remember, but someone else was highly unlikely to guess (unless they knew my password formula). I use a password formula based on the name of the website. Each password I use now has a common base, plus an added formula based on the first (e.g. four) letters in the website name. For instance if the website was ‘Choice’, and my password base is FrEd$9V, plus a formula of adding 3 letters past the first 4 letters of the website name (e.g. Choi) - i.e. C+4 = F, h+4=k, o+4=r, i+4=l. So my unique password for the Choice website would becomes FrEd$9V(the base password) plus Fkrl - or FrEd$9VFkrl. Now all I need to remember is the formula. PS - this obviously is NOT my formula!!
Hmm. The good old Caesar cipher. Probably crackable in milliseconds if a password cracker suspected its use and your root becomes known. 
Single sign-on (SSO) using your existing Google, Facebook, or other account to log into websites and apps has pros and cons.
Some websites/apps will also use your Apple, Twitter or LinkedIn account for SSO.
SSO gives you less control over what information is shared when the account is activated. Your social media credentials will likely share things like your email address, name, and profile photo to the app, and it may be able to access more personal details like your birthdate and phone number.
Do the prexisting account and the one you are signing up for, both make clear what parts of your data do or don’t get shared?
PS: I include password manager accounts and thus never use them for anything financial.
This is 100% true but and there’s a big but … all crypto experts advise against designing your own crypto algorithms … so this means that most sites that need to do hashing will use one of, say, half a dozen widely available, widely used hashing algorithms. Some sites will use the platform’s default hashing algorithm and leave it at that (if there is a default).
Furthermore, if a hacker has gained system-wide read-only access (in order to steal the password database in the first place) the hacker may well be able to copy the code that is used to verify passwords on that site, and from that code very quickly or sometimes with more patience determine the hashing algorithm in use. Determining the algorithm may be as simple as scanning the binary executable for the string e.g. “SHA1” or fairly straightforwardly verifying whether the binary executable uses the platform’s built-in routine for e.g. SHA1.
As a further data point, in the case of the Linux password file, the file explicitly says what hashing algorithm has been used for any given stored hash (so that it is possible to upgrade to a new algorithm in a convenient way if and when the current default algorithm becomes too weak for use). In other words, this is a clear trade-off in giving the hacker the identity of the algorithm for free in order to be more flexible for future upgrades.
As a final observation, if the hacker happens to be a customer of the site then the hacker can very easily test which possible hashing algorithm is in use, since the hacker knows his own password, and the hash (and salt) for that password is among those stolen. This could be generalised to the situation where the hacker is not a customer.
So you should assume that the hashing algorithm that is in use is known.
The bottom line: Strength of hashing does not arise from noone knowing the hashing algorithm in use. That is security through obscurity. Strength of hashing arises from the quality of the algorithm and the fact that the algorithm has been reviewed and prodded and poked by hundreds of independent experts all around the world for many years.
While this is not terrible - it does lead to a fairly solid password in isolation - it would be vulnerable if two or more web sites that you sign up to are fully compromised. A hacker would then notice that the first 7 characters of the password are identical. You can then assume that any of your web site passwords are compromised, as soon as the site itself is compromised, because it will take no time at all for a hacker to go through all possible 4 character endings. That is, it doesn’t matter at all what your algorithm is for mapping web site name to 4 character ending. The ending has 32 bits of entropy (maximum) and will be broken in no time.
I personally wouldn’t use this technique anywhere that money or other assets are at risk.
I created my own manager years ago. I bought an address book. Each company/website is listed under its initial, i.e. CHOICE Community is under C. I list my user name (if it isn’t my email address) or note if it’s one of my alternative email addresses. Then I write down my password, IN CODE. Only family are going to have a good idea of M’s birth year (2 digit) [or who M is for that matter] - but I do. Again, only close friend’s and family will know the ages of K; M & D the year that ‘we’ got married. I use all sorts of key events, people, places, heroes, favourite authors etc. I use digit substitutes for specific letters. I specify if it’s LLUC or FLUC or ALUC or ALLC. I may have several similar passwords, but I don’t believe any are the same. I do keep a duplicate (back up) book. I don’t have to worry about a manager being hacked and my only outlay has been the cost of the two address books.
Yes, there are pros and cons.
But the sites I use and register for a login using Google do not have any userid or password for me. What they have is a token from Google and a bit of search history maybe. Certainly no phone numbers or card details or profile pictures etc, since none of that is in my Google account.
If the site gets hacked, then no userid or password is exposed, and all they have is my Google nickname, and Gmail address. And I couldn’t care less about who knows those.
Naturally, important places like my banking, investments, tax, etc are kept separate from the Googleverse, and from any common factors like userid and password.
Intereresting approach. Whatever floats your boat as the saying goes.
If you were to be in an environment where password changes were forced on you on a regular basis, and password reuse prevented, how would your scheme go?
Or if you had, say, hundreds of logins to keep track of in your manual system?
I write everything in pencil – password changes aren’t a problem. I counted the number of passwords up to H. I have 65 so I probably have over a hundred already anyway. Technically I have space for 832 passwords (26 x 32), although some m/ships take up more than one space because of recording security question answers (again, they’re set down in code). Some passwords are defunct but I’ve not needed their spaces yet.
I’m not sure what you mean by your last question – I just open the book and flip to the correct initial letter: eg. A for Apple; B for BBC; C for CHOICE; D for Dropbox etc. and look down the page(s) until I come to the right one.
This is probably the most significant factor. The vast majority of attacks are online and a paper document of some type is almost completely immune to that.
A couple of comments though …
It becomes important where that backup is. If your house burns to the ground, taking with it the primary and the backup, then at an incredibly stressful time anyway you just lost access to everything.
Obviously you have to keep the backup up to date, so each time you scrawl in a new account or scratch out an old password for an existing account, you have to do both copies.
Even so, there are only 100 possible passwords coming from that (hence for example I as the hacker know not to be bother trying letters in those positions in the password, even though I don’t know who M is or how old she is). Against an offline attack, such a password will last much less time than a snowflake in hell. And it would even be vulnerable to an online attack, even for a site that limits an attacker to three bad passwords before locking the account. (This is somewhat theoretical since it presumes that I somehow know something about the rest of the password.)
Dates of birth are a bit vulnerable since that information is very widely collected and stored. Thanks to Optus, hackers may have the names and date of birth of up to 10 million Australians (possibly including M) - but Optus is only the tip of the iceberg. Almost any other date (e.g. marriage, as you suggest) is more robust.
Ultimately what usually matters is the total length of the password and the variety in use of characters.
An alternative to paper that is also largely unhackable is a digital address book on an offline computer i.e. one that is never connected to the network and exists solely to hold passwords. The address book file can then be backed up to external media. The file is ideally encrypted, which means that you do have to remember or otherwise record one password.
Point taken about the 100 digit max. but then I do position them differently: Also your point about the house burning down, but there’s never going to be a 100% foolproof anything. I’ve been lucky so far in not losing the master book. (I’m on the second, the first started to fall apart)
What I love is your suggestion of a digital copy on a computer that never goes online. That I’m definitely going to set up. Although you know that’ll be lost in the fire too, don’t you? 
Don’t have the digital copy on your computer, have it on a friend’s or family member’s - as long as they are not in the same building complex (preferably not the same suburb, in case of various natural disasters) it is safe.
Brute force attacks are not particularly useful actively trying to login and break into your account because as you said most places have the three strikes and your out and the account will be locked.
Where brute force attacks are very useful is when somebody has compromised the system and got a copy of the user ids and encrypted passwords. Sure they can’t read the password, but that can use brute force at their leisure to try and determine what the password is and then access accounts.
So holding the file of encrypted passwords they could try many possibilities at their leisure until they get a match. A match to what? How do they know when a trial is correct?
You have the encrypted password which is stored as (&^)(&GkladfYY5 for example.
You brute force passwords through the encryption algorithm until you find one that generates (&^)(&GkladfYY5 - bingo you have found a password that works. It may take millions of attempts to get it of course.
But, as you said earlier, you don’t get to try millions of combinations. You get just a few attempts before the account is locked.
But anyway, the password sample you provide would mean a 120 bit key. The most powerful supercomputers today may be able brute force crack that in a few billion years.
So the whole thing is pointless.
A hacker will not “notice that the first 7 characters of the password are identical” on any serious website because the passwords should never be stored in plain text but as hashes, and the hashed values may not even contain the same number of characters let alone the same first 7 characters. The danger with personal password algorithms such as these is simply that if the algorithm is discovered along with one example of a password then all passwords are compromised in one go. The example given in the post actually looks reasonably good as it presents as a randomly generated string and certainly would not be tempting as low hanging fruit even if somehow discovered.
