Is it possible to be secure without a password manager?

Question

I've read a thousand times that a password manager is the best way to secure numerous online accounts, and I think I understand the reasons pretty well. In practice, there is one problem : the ideal solution doesn't currently exist.

Why password managers aren't ideal

The most well-known "cloud" PMs like 1Password and Dashlane are paid and require me to trust a proprietary, closed-source system with the most important pieces of data I have. LastPass, aside from the closed-source problem, has a very bad, half-baked UI, was full of bugs last time I tried, and its interface is only partially translated into my language. It's also a pain to use it with other apps than my browser, as I have to open the browser, open the LastPass extension, search for the entry, copy the username, switch windows, paste, then repeat for the password. Finally, I've read too much about the vulnerabilities that were discovered in it to be comfortable with it, and I usually don't trust "free" (as in free beer) cloud storage.

Then there is KeePass that's the best solution I know of. The main problem with it is that there isn't an iOS equivalent that would be capable of syncing two databases (the iOS apps that are compatible with it just overwrite the remote version with their local one, potentially overwriting changes in the remote one).

In every case, syncing my passwords database with my phone would require either using a proprietary system or using a standard cloud service, which I don't want to use for several reasons (mainly not wanting to have a new background process on my laptop for syncing just one file, and not wanting to make my data available to cloud provides and whoever can read their data, even for an encrypted KP database).

What to replace them with

For all of these reasons, I'm currently trying to go back to using my brain as a password manager. I'm able to remember some reasonably secure passphrases for the few accounts I really care about and I'm working on a password scheme that would be reasonably hard to guess and provide different passwords for different sites. These usually mix a secret value remembered by the user with some information about the site, like its name.

I can make this method work, but then I'm worried about, for example, password leaks on some website with bad security, enabling someone to analyze one or two of my "lower-security" passwords, and guessing the scheme. The main problem to solve seems to be to design such a scheme that would be simple enough to be practical, while resisting to the leak of a few passwords from time to time.

Which brings me to my question : is it possible to create such a good password scheme, and would that method provide security that's not substantially inferior to a well-designed password manager ?

Answer 1

Personally I have ~5 >= 12 character entirely random passwords memorised. These are used for key sites and the password is used between at most two sites and if reused then the two sites have different email addresses and usernames for me..

For other less critical sites I map 3 random 8 character strings + the site name. For example "4QvkmvBt-StackExchange" and I might also have "4QvkmvBt-reddit". I have my own schema for mapping sites to random string. I also get extremely upset with sites whose password policy does not allow me to use this. Personally I view this as secure enough. If ever I became aware one site had been compromised I would replace all passwords using that random string.

This is good enough for me personally. Its not as strong as the passwords a password manager could provide but its also convenient (they are always available - in my head) and good enough. If stored properly by sites they should be impossible to brute force. If somehow someone does obtain a plaintext password the damage is limited. I also have no reason to believe someone would put above average effort into breaking into my accounts.

I dislike password managers because its a single point of failure. Any major password manager will also be mass targeted should a vulnerability be found. However for people that cannot remember long random strings I would still recommend them.

Answer 2

You can use a stateless (or vaultless) password manager such as https://lesspass.com/. Basically it does what you were doing by hand (it generates passwords as function(master_password,website_name)), only that this time function is a secure hashing function rather than concatenation.

By using a per-website "counter" token, you can change passwords for the same website.

This would solve your concerns, I think.

Answer 3

I will diverge by suggesting that you might not need to discard usage of a password manager.

You seem to actually have a technical problem: no iOS app being able to synchronise the database intelligently. However, they seem to be able to copy the files somewhere trustable that isn't a cloud provider (?)

I see a few options available:

Do not sync the keepass files

Do you need all the passwords on desktop and the mobile? Maybe you could do with separate keepass files.

Get the app to implement the feature

Either implement it yourself, if you have the required knowledge, resources and time, or convince someone else to do it. That could range from simply opening a bug report / mentioning the problem on a mailing list to hiring a developer just for doing that.

Generally, attaching a bounty to the request should help, though.

Synchronise manually

You probably don't add passwords too often (as opposed to reading them), so performing it manually should be doable (either by entering the missing entries by hand or by moving the files in the right direction).

Only add entries on mobile

^{(If your keepass app is able to copy-to-remote)}

Generate new passwords only on the mobile version. The desktop one acts as read-only. Thus, as it always have the master version, there is no loss.

Sync on the desktop

^{(If your keepass app is able to copy-to-remote)}

Have the file synchronised by the mobile app to save on desktop on a different folder than the one where you use the local keepass. Then you trigger a smart synchronization between the two files on the desktop (you may copy back to the iPhone or work with a bigger desktop file). Note you could manually run the "daemon" when needed (thus sparing the background process).

Answer 4

I'll give you the typical IT answer: it depends. What does it depend on? The level of complexity you'd like to endure to ensure your security.

Several years ago at a security conference, I heard a speaker talk about his password procedure. Each system he logs into has its own password. These are changed every 30 days and he stores the passwords on paper in his safe. That's probably the most secure way to manage passwords. But the PITA factor is really high.

Hector has a good scheme, but it has one failing—it lists the site in the password. Once a password gets compromised, a bad guy can figure out that algorithm and unravel the whole shootin' match.

Remember: the longer your password, the longer it will take to brute-force. Each additional character makes the duration exponentially longer if a bad guy is trying to guess the password.

A good middle-of-the-road solution is to have one password that you use for a lot of sites. Then anything financial or worthwhile gets its own password. So e-mail, bank, and investment accounts all have different unrelated and long passwords. Everything else (vendor web sites, school, the pizza place, etc) would have a "standard" password.

Answer 5

Intro

I've actually been thinking on this a while myself, and I agree that using a password manager isn't ideal for password security.

1. Because it introduces a single point of failure, which in my book is too great a risk. I don't want to entrust a third party with my security, or place the weight of security for all my accounts onto the strength of one password.
2. Because you either need to store your passwords in the cloud which is potentially accessible to everyone, or keep local copies and run the risk of losing the data and access to all of your sites with it.

The best solution I can come up with is one that has been mentioned in a few different answers already: using an algorithm to generate passwords. Although it's been previously mentioned, I feel that none of the other answers have quite provided a good implementation of this method yet, nor have they touched on several noteworthy points.

Generating Passwords Using Hashing/Encryption

A secure password generating algorithm should do three things:

1. Generate a secure password
2. Make it easy for the user to retrieve their passwords
3. Be inefficiently reversible without the initial input

So, my solution to this would be to run your password through the following generalized algorithm:

ENCODE(HASH("password" + "salt"))

My ideal suggestion would be to use:

Base85(SHA3-512("password" + "salt"))

Essentially, your password will first be run through a hashing algorithm to generate a random, irreversible output (in this example SHA3-512), and then encoded to give the password a large range of character values which increases it's resistance to hashcracking exponentially (here I've chosen Base85).
I suggest setting the password as the base domain of the site you are trying to log into, and setting the salt as your "password".

A concrete example:

Base85(SHA3-512("security.stackexchange.com" + "MyPassword"))

Preforming SHA3-512 on the string "security.stackexchange.comMyPassword" yeilds

8b6fe2cfd65d5faf4f3babe823afa844a9eb9c36dc6c1459b0f430a0f77318052318ce6b607eab0114f990aa52bb2a7acd06735f8590c2886bbc68ca42d05328

And after running this through Base85 you get

<~3+=dXAMRb-A2Z;U2.g9/1hJOQ@:Ee-1,E?N@5p)#@6%n.3Faj'A7IN-0f1aJ@PDCN1GE5kAiDY)0fUjE1,CXE@q@Q-2D@($@:CoF0f3K&3A=lM2)8WM11<+M@q78O2`!='3&N]M@kp#'2I^-*2E52T1brSq2)@!I~>

I think you could argue the above password is a strong one, and all you have to do is remember "MyPassword".

Altering My Example

Obviously, this concept could be applied with any hashing algorithm and encoding scheme, and whatever pattern you want as the input. Be wary though, the security of your generated password relies on what you choose for the algorithm (as well as your base password!). Some things to note:

• When it comes to hashing, hashing twice doesn't really add to the security of the password. If you use two different hash algorithms, in theory the resulting hash is only as secure as the weakest one in the chain. Take SHA1(MD5("pass")) for example. MD5() produces a 128 bit hash, where as SHA1() produces a hash of 160 bits. By doing this, you are essentially mapping 2¹²⁸ inputs onto 2¹⁶⁰ outputs. By theory of the pigeonhole principle, at a maximum this algorithm can only generate 2¹²⁸ possible outputs, which undermines the security of SHA1().
  The same result occurs with MD5(SHA1("pass")), but what about SHA1(SHA1("pass"))? By using SHA1() twice, you are mapping 2¹⁶⁰ inputs onto 2¹⁶⁰ outputs, which theoretically should be fine, but in practice it is not because of hash collisions. Any two strings A and B that collide on SHA1() will collide on SHA1(SHA1()). Furthermore, two unique hashes SHA1("C") and SHA1("D") may collide on SHA1()! This means that not only will SHA1() output <2¹⁶⁰, but it will also have roughly twice the chance at forming hash collisions.
  TL;DR hashing a string twice only weakens the security of that hash, because instead of mapping ∞ onto n bits you are mapping <∞ onto n bits.
• You could exchange a hashing function for an encryption function, but I would argue that this wouldn't increase the security of the algorithm at all. If we assume both the encryption function E() and the hashing function H() are equally secure, then they're essentially doing the same thing: On one hand E() is using the string "MyPassword" as a key to encrypt the domain "security.stackexchange.com" while on the other hand H() is using "MyPassword" to salt and hash the domain.
  I want to put a disclaimer here that I am well aware of the difference between encryption and hashing. They are two separate types of string permutation, but in the context of generating a password they are essentially the same. If you don't know the difference between hashing and encryption, you can learn more here, and this is another interesting, related article.
• Changing the encoding is a possibility, but I think Base85 is that sweet spot. If you go with something lower like Base64 (or any encoding scheme that generates output from a smaller pool of characters) you're only making your passwords weaker. You could increase the encoding past Base85, but eventually you start to hit outputs with non-printable characters and issues would arise from there.
  One issue with encoding is that there are sites that actually limit the length and what you're allowed to input for passwords. This is utterly ridiculous because the only thing you should be doing with a user password is hashing it down to a fixed length and storing it. Password fields shouldn't offer any sort of vector for attack, not even SQL Injection because the data should be hashed before it even touches a query. Alas, there are sites out there that restrict password field inputs, so in rare cases Base85 might not work universally.
• Lastly, it's completely acceptable to use multiple passwords for this solution, and even different Hashing/Encryption algorithms for different sites. If you choose 3 strong passwords and 3 strong Hashing algorithms, you now have 9 generators to draw from! Of course, if you extrapolate too much then you'll find yourself with the exact same problem this method aims to solve, but I believe there is a happy medium to this.
  Perhaps create 3 base passwords to insert into this algorithm, one for sites you don't care about, another for sites you partially care about, and a third for sites with sensitive information on them. Or you could do the same but with different Hashing/Encryption algorithms. The world is your oyster here, as long as you can remember them all, the more the merrier.

The Security of this Method

Theoretically, using this algorithm to generate a password is no more secure than using your password in the first place. This is because if the attacker gets ahold of your base password ("MyPassword"), and assuming the algorithm is public (which it would need to be for this method to become widespread), there is nothing stopping them from generating your passwords for each site you visit.

In practice however, I would argue this method IS more secure. You can look at it from several different attack vectors:

Database Breach
If an attacker were to breach a database and collect the stored password hashes, his only route of attack would be to crack them. Brute force would take too long and a Mask Attack wouldn't reasonably succeed either with the Base85 encoding.
If the passwords weren't hashed (pray for that DB Admin) then the attacker could easily decode the Base85 encoding. But then all he'd be left with is a hash. Although he wouldn't need to crack this hash (or even strip the encoding) to login as you on that site, he wouldn't gain access to any of your other accounts without first discovering your base password.

Man In The Middle Attack
Ultimately, the hashed and encoded password you generate is being sent over the wire to the website. Hopefully that site uses HTTPS, but not all of them do. If an eavesdropper is sitting on your connection and they manage to read this password they can login as you, but like mentioned above it will only be for that site. Without your base password the eavesdropper will have no way to access your other accounts. This is a better outcome than if you didn't generate passwords, because in that case the eavesdropper could login to any account in which you've used the same username/password combo.

Brute Force/Mask Attack
If a malicious actor is attempting to brute force your base password, then your generated passwords will be no more secure than using a regular, non-generated password (assuming the actor knows the algorithm you used to generate those passwords). In this case generating passwords doesn't add any extra security, but it doesn't diminish the security at all either. This attack vector requires you as an individual to be targeted as well, which in practice is much less likely to happen than the above methods. That said, it's still possible, so make sure to choose a secure base password.

Uncovering Your Base Password
As it stands, the ONLY way an attacker could generate the passwords for all of your sites is if they knew your base password. There are only two ways they can get this (without you directly telling them).

1. Crack the generated hash of your base password
2. Brute force your algorithm until they come up with your base password

First of all, by attempting #1 you are actually using #2. The most efficient method of cracking a hash IS brute force, so these are essentially the same thing with minor differences.

As long as you have chosen a secure base password, both of these methods should be close to impossible. This is because the attacker would need to come up with your EXACT base password to gain access to all of your accounts. Only with your EXACT base password can an attacker correctly generate your other passwords, hash collisions don't even factor in here.

To explain further, say you have your generated password P₁ where P₁ = G(S₁) and S₁ = p + s₁ (G = generator algorithm, p = base password string, s₁ = salt). If an attacker procured P₁ and found some S₁' such that P₁ = G(S₁'), then S₁' would HAVE to equal S₁ or the attacker wouldn't have access to your other accounts. Just because S₁' evaluates to P₁ does not imply that S₁' will evaluate to P₂ where P₂ = G(p + s₂).

Hopefully I didn't lose anyone with that explanation.

Outro

To specifically answer the OP's questions:

Is it possible to create such a good password scheme?

I think the method I've outlined in my post is a sufficiently good password scheme. It gives you a unique, strong password for every site you have an account on without straining your brain to remember all said passwords individually. All you have to remember is the algorithm and base password(s) you used.

Would that method provide security that's not substantially inferior to a well-designed password manager?

At it's weakest, the method I've given is equally secure to using regular passwords, and a PM to store them.

• When using a PM, you are essentially encrypting each (password, website) pair for every site with a single key. Using this key gives you access to all of your accounts.
• When generating passwords, you are essentially encrypting (or hashing) each password so that the only way to get that password is by knowing the key. Using this key gives you access to all of your accounts.

However, at it's strongest, you could reasonably say that this method is more secure than a Password Manager. Namely because You aren't entrusting someone else to keep that base password safe for you. The only thing you have to trust is your brain, and as long as you don't go crazy that's not such a scary thing to do. :)

PS: If there are any oversights to my solution or extra tidbits that anyone thinks I should add, please comment and let me know. I would be happy to improve this answer by editing in any valid points you guys come up with.

Answer 6

TLDR

Use a stateless password management with different master password for each site.

---

Let's go into detail

The stateless password management methods suggested in other answers has one major flaw, if a person knows your master password he can generate passwords for all your sites. It can be solved by using different master password for each site.

You can store the list of master passwords in the following way or any other way you find comfortable,

1. Create two lists - one that lists sites and the other lists master passwords.
2. Use a numeric code to link them. For example list one will contain 1234 - Stack Exchange and list two will contain 1234 - secretmaster.
3. To access the lists across multiple devices use two different cloud storage with Two Factor Authentication.

Alternatively, you can use a single list. It is a trade off between ease of use and security. Choose what is best for you.

I also recommend to change the master password of a site and thereby the actual passwords once in a while.

---

Security of this method

Like any method this is not 100% secure but it an improvement over the previous suggestion.

1. It is unlikely that an unauthorized person can obtain two list from different cloud providers and link them with one another.
2. Even if they obtain two lists they still do not know what algorithm you are using to produce the site's password.
3. This way you can also change the password of a single site and still use the algorithm by changing the master password of that site. In previous methods changing master password affects all sites.

Answer 7

Instead of a password manager and cloud storage, I use something like this in a bookmarklet:

Paste this into the url of a new bookmark, and edit the salt (123456789) after pasting:

javascript:function s2a(s)%7Bvar a=new Uint8Array(s.length);s.split('').forEach((x,y)=>a%5By%5D=x.charCodeAt(0));return a;%7Dfunction a2s(a)%7Breturn%5B%5D.slice.call(new Uint8Array(a)).map(x=>x.toString(16)).join('');%7Dcrypto.subtle.digest('SHA-256',s2a('123456789'+location.host)).then(a2s).then(function(r)%7Bprompt(location.host,btoa(r).slice(2,22))%7D);void(0);

As slightly more readable code (JS, run in console from [F12] developer tools):

function s2a(s) {
    var a = new Uint8Array(s.length);
    s.split('').forEach((x, y) => a[y] = x.charCodeAt(0));
    return a;
}
function a2s(a) {
    return [].slice.call(new Uint8Array(a)).map(x => x.toString(16)).join('');
}
crypto.subtle.digest('SHA-256', s2a('this is MY s@lt, use yer 0wn' + location.host))
    .then(a2s)
    .then(function(r) {
        prompt(location.host, btoa(r).slice(2, 22))
    }
);

When run on this site, c5ODI5NDMzMzQxNzRlZG is offered in a copy-able prompt interface.

This performs client-side hashing on an https site using a user-defined salt and the site's domain. Given a decent salt, it should be impossible to reverse, even if the attackers know the code above was used. It's different each site and virtually impossible to correlate between sites.

You should probably not sync your bookmarks if you go down this route, or if you must, prompt() for some user-supplied salt to keep the source code from revealing your formula.

While these kind of self-defined password derivations are secure, there's one major downside: you can't change a single password without changing them all. It's just another option in a field of imperfect options, so I thought I'd put it out there.