Flaws in deterministic password managers(tonyarcieri.com)
tonyarcieri.com
Flaws in deterministic password managers
https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers
105 comments
Not to be too pointed, but would you consider adding this disclaimer to your blog post and github repo? Hopefully that will inform potential users before using a system that could leave them less secure.
Funny, I also implemented mine a while ago (mostly un-maintained but I still use it): https://pypi.python.org/pypi/virtualkeyring/
I also thought I was clever and the first to do it ;)
I have been thinking about adding support to keep some state info in a yaml file to deal with revocation and specific varying password policies (e.g. in a dropbox synced folder) but I was too lazy to implement it. If someone wants to do it please feel free to send a PR.
The compromised master password issue is a real issue though.
I also thought I was clever and the first to do it ;)
I have been thinking about adding support to keep some state info in a yaml file to deal with revocation and specific varying password policies (e.g. in a dropbox synced folder) but I was too lazy to implement it. If someone wants to do it please feel free to send a PR.
The compromised master password issue is a real issue though.
Use a photo as the master password. It can't be confused with text.
This change seems kind of worrying: https://github.com/libeclipse/visionary/pull/40/files#r79336...
The distribution of characters in “complex passwords” isn’t even?
The distribution of characters in “complex passwords” isn’t even?
That doesn't matter. I could just put a full stop at the end of the string and call it a complex password. The point of it was for sites that require symbols. The complex password doesn't add a meaningful amount of entropy to a sufficiently long normal password; a 32 character normal password already has log2(16^32) = 128 bits of entropy.
We rely on the seed for security, the seed being the hash that scrypt spits out
We rely on the seed for security, the seed being the hash that scrypt spits out
So it’s way too complicated for that purpose, then.
That's not an argument. Keep in mind that entropy is a property of password generation, not the result of the generation.
I mean, what do you want me to say? It is way too complicated. Why are you using a pre-shuffled character set and getting a permutation of it by index when the index is always extremely low compared to the number of permutations just to get some symbols in your password? Just base64-encode with a custom alphabet or something.
I never said anything about entropy, either.
I never said anything about entropy, either.
Two extra advantages of vault based password managers:
1. The manager can automatically change old passwords for you. LastPass support a big set of websites, when Dropbox was hacked this was very handy. I like to change social media passwords every few months and this makes it very easy.
2. You can store passwords that you can remember if necessary. Sometimes I need to access a password for a service or a site in an environment where I don't have an easy access to my password manager, for example when I'm using a friend's phone or when I SSHd into another machine. In those cases is handy to have some passwords that you remember, but are stored in the vault just in case you forget them. I only do this for a few passwords, but it's a nice feature to have.
1. The manager can automatically change old passwords for you. LastPass support a big set of websites, when Dropbox was hacked this was very handy. I like to change social media passwords every few months and this makes it very easy.
2. You can store passwords that you can remember if necessary. Sometimes I need to access a password for a service or a site in an environment where I don't have an easy access to my password manager, for example when I'm using a friend's phone or when I SSHd into another machine. In those cases is handy to have some passwords that you remember, but are stored in the vault just in case you forget them. I only do this for a few passwords, but it's a nice feature to have.
I've been surprised by how negative the opinions of deterministic password managers have been since I've been using one for over two years and it has been a much better experience overall than using KeePass on Dropbox, and I also think that it's more secure than cloud-based systems (see point 4).
My take on the points in the post:
1. Out of the 100 or so sites that I use, only a few have password policies that require tweaks, and it usually just requires disabling symbols and or adjusting the length. These tweaks are cached in my browser, so this hasn't been much of an inconvenience.
2. My passwords are rarely revoked, and when they are it is just a counter bump. This is state, but again it is cached in the browser.
3. It's true that they can't store existing secrets, but this can be viewed as out of scope for a password manager.
4. For the application I use, it's not true that exposing just the master password exposes all of your site passwords. There is a 512bit private key that is synchronized once between devices using a QR code. An attacker would need both the master password and the private key file to generate any passwords. Because the private key only exists on devices I physically own, this should be harder to obtain than an encrypted database that lives in the cloud, so I view this system as more secure than KeePass on Dropbox, Lastpass, or 1Password.
My experience over the past two years has been that the advantages are more significant than the disadvantages.
My take on the points in the post:
1. Out of the 100 or so sites that I use, only a few have password policies that require tweaks, and it usually just requires disabling symbols and or adjusting the length. These tweaks are cached in my browser, so this hasn't been much of an inconvenience.
2. My passwords are rarely revoked, and when they are it is just a counter bump. This is state, but again it is cached in the browser.
3. It's true that they can't store existing secrets, but this can be viewed as out of scope for a password manager.
4. For the application I use, it's not true that exposing just the master password exposes all of your site passwords. There is a 512bit private key that is synchronized once between devices using a QR code. An attacker would need both the master password and the private key file to generate any passwords. Because the private key only exists on devices I physically own, this should be harder to obtain than an encrypted database that lives in the cloud, so I view this system as more secure than KeePass on Dropbox, Lastpass, or 1Password.
My experience over the past two years has been that the advantages are more significant than the disadvantages.
If your browser is caching all of your passwords, I think you've got security problems well outside the scope of your choice of password managers.
Only the override parameters for a site are cached, such as a boolean to indicate that symbols are disabled or an integer reset counter. The passwords are never cached.
I'd guess he doesn't mean cached, but instead means that his web browser works with this system keyring (or has its own) to save/use the passwords.
Which is bad. I've reverse engineered script kiddie malware far too many times to find them shipping "iStealer" and similar, which basically just dump browser password stores and send them to a gmail or FTP account. Often these pieces of malware include the SMTP credentials to the same gmail account or FTP access to download the results.
And having seen their results, let me just say, these script kiddies can do damn well with this tactic.
Do not use a browser/system keyring store under any circumstances unless you can be 100% positive that you won't accidentally run that sketchy exe you came across.
If you use Keepass, it presents another layer, they have to actually get your keepass password too, or dump your database when it's logged in. Often something like that won't be hit by script kiddies but certainly would in a targeted attack. The best practice here is to run Keepass on a separate machine to prevent an all-at-once dump. Even a separate machine on the same network where you use Synergy or similar to sync the clipboards would probably be sufficient.
Anything worth more than dirt should of course have 2FA, which is why I also suggest a tiered password system (ie: junk password for common and worthless sites, separate passwords for banking, etc) and 2FA as an alternative to a real password manager.
And having seen their results, let me just say, these script kiddies can do damn well with this tactic.
Do not use a browser/system keyring store under any circumstances unless you can be 100% positive that you won't accidentally run that sketchy exe you came across.
If you use Keepass, it presents another layer, they have to actually get your keepass password too, or dump your database when it's logged in. Often something like that won't be hit by script kiddies but certainly would in a targeted attack. The best practice here is to run Keepass on a separate machine to prevent an all-at-once dump. Even a separate machine on the same network where you use Synergy or similar to sync the clipboards would probably be sufficient.
Anything worth more than dirt should of course have 2FA, which is why I also suggest a tiered password system (ie: junk password for common and worthless sites, separate passwords for banking, etc) and 2FA as an alternative to a real password manager.
> Do not use a browser/system keyring store under any circumstances unless you can be 100% positive that you won't accidentally run that sketchy exe you came across.
This is easy once you decide to do it. Just don't download and run random crap, don't be stupid and "curl URL | bash", etc. It really isn't that hard to be 100% if you pay attention. The main problem is that most people just don't care enough.
This is easy once you decide to do it. Just don't download and run random crap, don't be stupid and "curl URL | bash", etc. It really isn't that hard to be 100% if you pay attention. The main problem is that most people just don't care enough.
Wait, KeePass only decrypts the database into memory for a particular process, right? So it would take an exploit of some kind to read the memory holding the decrypted database?
No, it wouldn't take an exploit, it just takes a process running as an administrator, maybe even as the same user if the attacker is clever.
There's several ways to go about it:
1) Basic basic software keylogger, there are some mitigations against this via common APIs though with mixed success. It also would mean a lot of data to filter through. Not fun for someone just looking to grab as many passwords as they can.
2) Dump memory, just save the entire memory of the keepass process via ReadProcessMemory calls, as long as you have sufficient privileges this should be possible. The passwords are in there, KeePass has no memory shadowing support to my knowledge at least. And once you've logged in to keepass you don't get prompted for the password again, therefore, it should be entirely possible to read all passwords based on just this.
3) Replace the keepass executable with your own modified version that logs the password or other auth credentails to disk, or just dumps the database to disk on logon if they're using some esoteric authentication method like Yubikey. This involves shipping your own patched exe around though, which works, but isn't particularly clever, could be fairly large and will be revealed with a signature check.
4) Do the same, but rather than replacing it on disk, do it in memory - do it from a shared library or inject your own code via WriteProcessMemory/CreateRemoteThread, etc. This is usually less detectable. Doesn't matter if the executable is signed this way either, you bypass the signature system and can avoid the need for disk write permissions too. This is the way to get the brownie points.
Any and all of these are fairly trivial to someone who knows their way around the Windows API and has a copy of the Keepass source and IDA. However, none of these are things commonly used by script kiddies going for a hit-and-run operation. All of these however are on the table in a targeted attack with even a slightly competent attacker.
There's several ways to go about it:
1) Basic basic software keylogger, there are some mitigations against this via common APIs though with mixed success. It also would mean a lot of data to filter through. Not fun for someone just looking to grab as many passwords as they can.
2) Dump memory, just save the entire memory of the keepass process via ReadProcessMemory calls, as long as you have sufficient privileges this should be possible. The passwords are in there, KeePass has no memory shadowing support to my knowledge at least. And once you've logged in to keepass you don't get prompted for the password again, therefore, it should be entirely possible to read all passwords based on just this.
3) Replace the keepass executable with your own modified version that logs the password or other auth credentails to disk, or just dumps the database to disk on logon if they're using some esoteric authentication method like Yubikey. This involves shipping your own patched exe around though, which works, but isn't particularly clever, could be fairly large and will be revealed with a signature check.
4) Do the same, but rather than replacing it on disk, do it in memory - do it from a shared library or inject your own code via WriteProcessMemory/CreateRemoteThread, etc. This is usually less detectable. Doesn't matter if the executable is signed this way either, you bypass the signature system and can avoid the need for disk write permissions too. This is the way to get the brownie points.
Any and all of these are fairly trivial to someone who knows their way around the Windows API and has a copy of the Keepass source and IDA. However, none of these are things commonly used by script kiddies going for a hit-and-run operation. All of these however are on the table in a targeted attack with even a slightly competent attacker.
> I've reverse engineered script kiddie malware far too many times to find them shipping "iStealer" and similar, which basically just dump browser password stores and send them to a gmail or FTP account.
Meet the guy behind some of them: https://news.ycombinator.com/item?id=13003236
Meet the guy behind some of them: https://news.ycombinator.com/item?id=13003236
If only my bank allowed passwords...
Shame, Société Générale, shame.
Shame, Société Générale, shame.
I thought browsers store password s encrypted. I use Firefox sync that encrypts and uploads passwords. Do u mean this is also vulnerable? Thx
We're talking about different things:
- Firefox Sync is not vulnerable in the sense that Mozilla, nor any attacker can read your passwords while they're on the wire or on Mozilla servers. Passwords are encrypted client-side only and are effectively unbreakable between your devices assuming your master password is secure.
- The Firefox browser password store is only encrypted if you use a separate master password to unlock your saved passwords each and every time your browser starts up. This master password would defeat the majority of script kiddie malware, but not a targeted attack, similar to separate password managers. However, it's also a real pain, no one wants to have to type all that extra stuff, so they just use the default - remembering passwords without a master password. Even if you use Firefox Sync, your passwords still get sync'd into this store. Firefox Sync keeps them safe everywhere between your devices, but not on your devices.
- If your Firefox password store has no master password set, that means that the Firefox browser must be able to read your passwords from it. They can (and do) encrypt it all they want, but ultimately all it takes it a little bit of reverse engineering to decrypt it, because the key needs to somehow be accessible to Firefox, that means that to read your passwords, malware simply needs to duplicate what Firefox does.
- Firefox Sync is not vulnerable in the sense that Mozilla, nor any attacker can read your passwords while they're on the wire or on Mozilla servers. Passwords are encrypted client-side only and are effectively unbreakable between your devices assuming your master password is secure.
- The Firefox browser password store is only encrypted if you use a separate master password to unlock your saved passwords each and every time your browser starts up. This master password would defeat the majority of script kiddie malware, but not a targeted attack, similar to separate password managers. However, it's also a real pain, no one wants to have to type all that extra stuff, so they just use the default - remembering passwords without a master password. Even if you use Firefox Sync, your passwords still get sync'd into this store. Firefox Sync keeps them safe everywhere between your devices, but not on your devices.
- If your Firefox password store has no master password set, that means that the Firefox browser must be able to read your passwords from it. They can (and do) encrypt it all they want, but ultimately all it takes it a little bit of reverse engineering to decrypt it, because the key needs to somehow be accessible to Firefox, that means that to read your passwords, malware simply needs to duplicate what Firefox does.
Neophyte to all this. What is a browser password store? Do you mean never letting Chrome (or whatever) save a password?
Yes. If you want to see how vulnerable you are to this sort of attack, Nirsoft ships a good tool called WebBrowserPassView:
http://www.nirsoft.net/utils/web_browser_password.html
Be aware, this may be detected as malware or a "hacking tool" by your AV for obvious reasons.
http://www.nirsoft.net/utils/web_browser_password.html
Be aware, this may be detected as malware or a "hacking tool" by your AV for obvious reasons.
How is this to supposed to show "how vulnerable you are to this sort of attack"? This runs standalone.
1. As a general rule, if you download and run an untrusted standalone program, it could probably steal your passwords even if you use a password vault (although that would certainly make it a little bit harder).
2. You can just go into the Chrome password manager and click "show" to see any stored password. No tool needed.
Chrome uses sandboxing and process isolation extensively. Using the default browser password store certainly presents a ripe target if someone manages to totally own the browser, but technically there's not a huge leap from owning the browser to owning an external password store, and certainly not grabbing any and all passwords entered into the browser via a password vault.
I'm not disagreeing that a standalone password vault encrypted with a master password is effectively more secure than the built-in manager. I do think it has been exaggerated both how much more so it is. Saving strong passwords with the built-in password store is generally much less bad than, for instance, using a common memorized password, or using very weak passwords. Both of which are likely outcomes of "never use the password store."
1. As a general rule, if you download and run an untrusted standalone program, it could probably steal your passwords even if you use a password vault (although that would certainly make it a little bit harder).
2. You can just go into the Chrome password manager and click "show" to see any stored password. No tool needed.
Chrome uses sandboxing and process isolation extensively. Using the default browser password store certainly presents a ripe target if someone manages to totally own the browser, but technically there's not a huge leap from owning the browser to owning an external password store, and certainly not grabbing any and all passwords entered into the browser via a password vault.
I'm not disagreeing that a standalone password vault encrypted with a master password is effectively more secure than the built-in manager. I do think it has been exaggerated both how much more so it is. Saving strong passwords with the built-in password store is generally much less bad than, for instance, using a common memorized password, or using very weak passwords. Both of which are likely outcomes of "never use the password store."
Yeah, this is not an attack itself, just one of the most common post exploitation routes to easy profit. So common that if you have amateur people who try to pirate things, cheat at games or click on the big flashing red banner ad, they're almost certain to come across it and they're almost certain to have common accounts stolen.
Using even a separate password manager, even an integrated one like LastPass raises the bar beyond this extremely basic level and takes it from easy target to medium target, eliminating every common stealer malware I've seen. This definitely doesn't rule out targeted ones of course, like you say, on an objective level there doesn't seem to be much of a difference. At a practical level though based on what's in the wild for non targeted attacks, it's huge.
Using even a separate password manager, even an integrated one like LastPass raises the bar beyond this extremely basic level and takes it from easy target to medium target, eliminating every common stealer malware I've seen. This definitely doesn't rule out targeted ones of course, like you say, on an objective level there doesn't seem to be much of a difference. At a practical level though based on what's in the wild for non targeted attacks, it's huge.
[deleted]
I never let my browsers store a password to anything, ever. I rely on 1Password to supply all passwords, and having my browser also store a password doubles the attack surface.
What system are you using?
Today I learned that many people on Hacker News have really insecure web security practices. :(
I don't understand the resistance to using a vault-based password manager. Is it inertia? I mean, if you're using the same one or two passwords on every site, then sure, it may not seem worthwhile to us 1Password. But then, enough password hashes have been leaked this year alone to suggest that you need to do something better.
I don't understand the resistance to using a vault-based password manager. Is it inertia? I mean, if you're using the same one or two passwords on every site, then sure, it may not seem worthwhile to us 1Password. But then, enough password hashes have been leaked this year alone to suggest that you need to do something better.
I literally cannot be bothered. There are 3 kinds of sites:
- Important - Useful - Trash
Trash sites all use pretty much the same password. It's terrible but who cares?
Useful sites all use a standard root with prefix/suffix
Important sites (basically my email since that's the unlocker to everything else) just has it's own unique.
I imagine an attacker could probably post rude things on my linkedin and steal my neopets account? It's a downside risk i'm willing to take in exchange for not having to flick into another program which I have to install on all my devices etc etc etc.
When the government comes for me I'm screwed anyway
- Important - Useful - Trash
Trash sites all use pretty much the same password. It's terrible but who cares?
Useful sites all use a standard root with prefix/suffix
Important sites (basically my email since that's the unlocker to everything else) just has it's own unique.
I imagine an attacker could probably post rude things on my linkedin and steal my neopets account? It's a downside risk i'm willing to take in exchange for not having to flick into another program which I have to install on all my devices etc etc etc.
When the government comes for me I'm screwed anyway
For me it was a case of thinking I know better. As in, "no way I'm giving you my passwords" and "who knows how tight their opsec is" ... never even tried anything like LastPass or 1Password until six months ago.
Now I cannot imagine going back. My LastPass subscription is among the most vital services I pay for and the sheer freedom of having to remember one diceware-style master password instead of maintaining my own local database is just too nice.
I'm using banking software with a HBCI card and have set reasonable limits on all things like PayPal. So if you cracked my LastPass vault - good luck with that, 2FA considered - you'd be well able to ruin my digital life. But you would not get much out of it.
The attack surface I offer in total has shrunk a lot, too. Unique, maximum allowed length passwords for every unimportant little account and no need to memorise a single one.
It's to Web logins what pubkey auth is to ssh for me personally. Just such a freaking blessing.
Now I cannot imagine going back. My LastPass subscription is among the most vital services I pay for and the sheer freedom of having to remember one diceware-style master password instead of maintaining my own local database is just too nice.
I'm using banking software with a HBCI card and have set reasonable limits on all things like PayPal. So if you cracked my LastPass vault - good luck with that, 2FA considered - you'd be well able to ruin my digital life. But you would not get much out of it.
The attack surface I offer in total has shrunk a lot, too. Unique, maximum allowed length passwords for every unimportant little account and no need to memorise a single one.
It's to Web logins what pubkey auth is to ssh for me personally. Just such a freaking blessing.
> For me it was a case of thinking I know better.
I'm deeply curious: why? When virtually every reputable security practitioner on this site and others has echoed the advice to just use a password manager for years, how do you come to the conclusion that you know better than them?
If it sounds like I'm asking judgmentally, please don't interpret it that way. Your experience mirrors that of many others, and if I can understand how this line of thinking happens then maybe we can find ways to combat it.
This is just one battle amongst many where, despite endless warnings and examples to the contrary, people seem to think they are qualified to go against encouraged practice for password storage, password management, encrypting data at rest, encrypting data over the wire, etc. And in almost all cases, people come to the conclusion that they know better, when they absolutely do not.
I'm deeply curious: why? When virtually every reputable security practitioner on this site and others has echoed the advice to just use a password manager for years, how do you come to the conclusion that you know better than them?
If it sounds like I'm asking judgmentally, please don't interpret it that way. Your experience mirrors that of many others, and if I can understand how this line of thinking happens then maybe we can find ways to combat it.
This is just one battle amongst many where, despite endless warnings and examples to the contrary, people seem to think they are qualified to go against encouraged practice for password storage, password management, encrypting data at rest, encrypting data over the wire, etc. And in almost all cases, people come to the conclusion that they know better, when they absolutely do not.
I think the reason is that it just feels insecure. If you keep all your passwords in your head, then you have full control. Using a password manager means handing them off to something else, whether it is a paid service, a piece of software, or whatever. It feels like a "cat's out of the bag situation", that once you let the password escape that first container (your mind), it will inevitably spread everywhere.
I'm not saying it's rational (I'm a happy customer of 1password), but there is something a little bit scary about letting go of control of your passwords.
I'm not saying it's rational (I'm a happy customer of 1password), but there is something a little bit scary about letting go of control of your passwords.
>I'm deeply curious: why? When virtually every reputable security practitioner on this site and others has echoed the advice to just use a password manager for years
I think the disconnect is "perfect use" vs. "typical use".
With perfect use, generating a unique passphrase for each service and storing it only in your head is more secure than using any kind of remotely-syncing password manager. It's also more convenient - wherever you are, whatever you have with you, so long as you have an internet connection you can identify and verify yourself. You don't need your phone or an app or anything else.
With typical use, people use weak passphrases, reuse passphrases and forget passphrases, so using a remotely-syncing password manager is more secure, even if it's less convenient.
Some people (possibly wrongly) think they can achieve close enough to perfect use that they're better off not using a manager. Security experts know that virtually no one can achieve perfect use, so they recommend using a manager (which is almost certainly the correct advice to give to a wide audience).
But your apparent absolute confidence in the superior security of password managers, especially closed-source cloud-based password managers, seems to me to be overplaying your hand a little. The failure mode of a closed-source cloud-based password manager, even if very unlikely, is absolutely catastrophic.
I think the disconnect is "perfect use" vs. "typical use".
With perfect use, generating a unique passphrase for each service and storing it only in your head is more secure than using any kind of remotely-syncing password manager. It's also more convenient - wherever you are, whatever you have with you, so long as you have an internet connection you can identify and verify yourself. You don't need your phone or an app or anything else.
With typical use, people use weak passphrases, reuse passphrases and forget passphrases, so using a remotely-syncing password manager is more secure, even if it's less convenient.
Some people (possibly wrongly) think they can achieve close enough to perfect use that they're better off not using a manager. Security experts know that virtually no one can achieve perfect use, so they recommend using a manager (which is almost certainly the correct advice to give to a wide audience).
But your apparent absolute confidence in the superior security of password managers, especially closed-source cloud-based password managers, seems to me to be overplaying your hand a little. The failure mode of a closed-source cloud-based password manager, even if very unlikely, is absolutely catastrophic.
> But your apparent absolute confidence in the superior security of password managers, especially closed-source cloud-based password managers, seems to me to be overplaying your hand a little. The failure mode of a closed-source cloud-based password manager, even if very unlikely, is absolutely catastrophic.
In fact it's you that's overplayed your hand.
Open-source vs. closed-source is a red herring. Did you download compiled binaries published by the authors of an open source project? Would you be able to tell if they had published backdoored binaries that didn't match the source? Would you be able to tell if they cleverly added backdoors to the source code itself? You might argue that such deception would eventually be discovered. Maybe, but by then the "catastrophic" scenario has already unfolded.
Similarly, if you're downloading and running a third-party deterministic password manager, open-source or not, you're giving the author of that project the ability to run arbitrary code on your machine. Unless you're running it in a container with no network access or access to storage, the failure case is identical — regardless of what the software claims to do on the label, it may do something wildly different (e.g., send all of your passwords to the author).
In fact it's you that's overplayed your hand.
Open-source vs. closed-source is a red herring. Did you download compiled binaries published by the authors of an open source project? Would you be able to tell if they had published backdoored binaries that didn't match the source? Would you be able to tell if they cleverly added backdoors to the source code itself? You might argue that such deception would eventually be discovered. Maybe, but by then the "catastrophic" scenario has already unfolded.
Similarly, if you're downloading and running a third-party deterministic password manager, open-source or not, you're giving the author of that project the ability to run arbitrary code on your machine. Unless you're running it in a container with no network access or access to storage, the failure case is identical — regardless of what the software claims to do on the label, it may do something wildly different (e.g., send all of your passwords to the author).
It's cool! I've been wondering too, since it's been an eye opener without equals finding out just how wrong I was. I think there were multiple lines of reasoning going on:
- "I don't even use that many logins." I do. I just abused 'reset password via email'.
- "I distrust the cloud provider's opsec." Seriously? I'm a self taught amateur. Get a grip guy.
- "What if they give my passwords to the NSA?" ... at this point I want to slap myself.
- "How can it be secure if it's easy to use?" I blame PGP for this one...
So I guess many things. In the end it was the usual mix of uninformed bias, weariness against third parties in security, being very wrong and the assumption that security needs terrible UX.
As I said, I never looked back. I've even sat down with friends and family, explained the concept and turned their '$catsname$birthyear' passwords they used for absolutely everything into security they wouldn't ever hope to achieve otherwise. And they're all so freaking happy, too.
For their master passwords I used the 'correct horse battery staple' approach and nobody has a problem remembering one of those, especially if it's in their native language.
So, yup, you're right in every way. I didn't know better.
- "I don't even use that many logins." I do. I just abused 'reset password via email'.
- "I distrust the cloud provider's opsec." Seriously? I'm a self taught amateur. Get a grip guy.
- "What if they give my passwords to the NSA?" ... at this point I want to slap myself.
- "How can it be secure if it's easy to use?" I blame PGP for this one...
So I guess many things. In the end it was the usual mix of uninformed bias, weariness against third parties in security, being very wrong and the assumption that security needs terrible UX.
As I said, I never looked back. I've even sat down with friends and family, explained the concept and turned their '$catsname$birthyear' passwords they used for absolutely everything into security they wouldn't ever hope to achieve otherwise. And they're all so freaking happy, too.
For their master passwords I used the 'correct horse battery staple' approach and nobody has a problem remembering one of those, especially if it's in their native language.
So, yup, you're right in every way. I didn't know better.
[deleted]
> So if you cracked my LastPass vault - good luck with that, 2FA considered
Well, the traditional[1] way to break[2] LastPass is to ignore individual accounts and go after poor coding technique[3]. 2FA won't help you there.
[1] https://www.wired.com/2015/06/hack-brief-password-manager-la...
[2] https://techcrunch.com/2011/05/05/password-manager-last-pass...
[3] https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...
Well, the traditional[1] way to break[2] LastPass is to ignore individual accounts and go after poor coding technique[3]. 2FA won't help you there.
[1] https://www.wired.com/2015/06/hack-brief-password-manager-la...
[2] https://techcrunch.com/2011/05/05/password-manager-last-pass...
[3] https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...
I'm probably the least knowledgeable person on HN so please understand these as questions more than objections, okay?
I would think the first link doesn't affect me since I use a fairly strong unique master password and haven't set an insecurity question.
As for the second link, much the same. I mean I'm fairly certain I can create an encrypted plaintext file that withstands extensive cracking attempts with standard Linux tools. These kinds of attacks would suck for people using 'lastpassword' as their master, if the stored vaults were unhashed and unsalted. Even then, how would that circumvent 2FA? Without my phone or Yubikey or whatever, you still don't get in.
As for the last one, and generally for most criticism: these tools give you the means to be more secure, they even encourage you by asking things that must annoy the average user. There's no unlimited trust for devices or browsers, the security checker is actually quite helpful in identifying possible problems - like my banking password being capped at five digits by design... sigh - and telling you when you're getting dumb ideas, like permanently storing your master password on your phone. So in the end, it's up to the user isn't it?
It's not using it by itself that makes the concept an increase in security, it's using it thoughtfully that is.
I would think the first link doesn't affect me since I use a fairly strong unique master password and haven't set an insecurity question.
As for the second link, much the same. I mean I'm fairly certain I can create an encrypted plaintext file that withstands extensive cracking attempts with standard Linux tools. These kinds of attacks would suck for people using 'lastpassword' as their master, if the stored vaults were unhashed and unsalted. Even then, how would that circumvent 2FA? Without my phone or Yubikey or whatever, you still don't get in.
As for the last one, and generally for most criticism: these tools give you the means to be more secure, they even encourage you by asking things that must annoy the average user. There's no unlimited trust for devices or browsers, the security checker is actually quite helpful in identifying possible problems - like my banking password being capped at five digits by design... sigh - and telling you when you're getting dumb ideas, like permanently storing your master password on your phone. So in the end, it's up to the user isn't it?
It's not using it by itself that makes the concept an increase in security, it's using it thoughtfully that is.
I do use a vault-based password manager (KeePass), but investigated using a deterministic one out of fear of losing my database, a risk which is avoided by using a memorable algorithm to generate passwords instead.
Wouldn't good backups be an easy way to deal with this risk? Presumably you have plenty of other data that you wouldn't want to lose (photos is usually the big one), so you need a solid backup plan regardless.
I have an irrational(?) fear of vault password managers. I see it as a single point of failure.
Furthermore, the more "useful" they become, with browser extensions etc., the greater the attack surface becomes.
Because of this fear, I generate random passwords and memorise them, which is not ideal.
Furthermore, the more "useful" they become, with browser extensions etc., the greater the attack surface becomes.
Because of this fear, I generate random passwords and memorise them, which is not ideal.
How many passwords do you actually remember? 10, maybe 20? What do you do for everything else?
In my password vault I have over 500 logins, each with unique password. Unless you are reusing passwords it doesn't seem feasible to have a unique password for each site (or you have a much better memory than me :D).
In terms of your fears, I remember unique passwords that aren't stored in the vault for things like my main email account and banks. Everything else goes in the vault - if it gets lost, at worse I can reset the password via email, and if it gets stolen at worse they get access to my Spotify account.
In my password vault I have over 500 logins, each with unique password. Unless you are reusing passwords it doesn't seem feasible to have a unique password for each site (or you have a much better memory than me :D).
In terms of your fears, I remember unique passwords that aren't stored in the vault for things like my main email account and banks. Everything else goes in the vault - if it gets lost, at worse I can reset the password via email, and if it gets stolen at worse they get access to my Spotify account.
> the more "useful" they become, with browser extensions etc., the greater the attack surface becomes
Also, the more popular the password manager becomes, the more valuable cracking it becomes. One exploit can yield the email, banking, workplace, confidential document, and other passwords for many millions of people. If you are an attacker, it would be worth it to have the exploit on file, proactively, for the next time you attack someone using that password manager.
Also, the more popular the password manager becomes, the more valuable cracking it becomes. One exploit can yield the email, banking, workplace, confidential document, and other passwords for many millions of people. If you are an attacker, it would be worth it to have the exploit on file, proactively, for the next time you attack someone using that password manager.
This is only true for cloud based password managers. I recommend using 1Password or KeePassX with Dropbox.
> This is only true for cloud based password managers
I agree, in the sense that one successful attack on the supposed centralized database containing all user credentials would have a high ROI.
But it also applies to local password managers. If 20 million people use the same password manager and I have an exploit for it, if I'm in the business of stealing data I'm likely to find a use for my exploit.
I agree, in the sense that one successful attack on the supposed centralized database containing all user credentials would have a high ROI.
But it also applies to local password managers. If 20 million people use the same password manager and I have an exploit for it, if I'm in the business of stealing data I'm likely to find a use for my exploit.
'If 20 million people use the same password manager and I have an exploit for it'
Someone is going to exploit my local password manager remotely?
Someone is going to exploit my local password manager remotely?
> Someone is going to exploit my local password manager remotely?
I don't know - who are you?
Even if you are not an especially valuable target, malware is pretty widespread. It steals credit card numbers and other data; if the attacker had a hack for a popular password manager, why wouldn't they go for it?
I don't know - who are you?
Even if you are not an especially valuable target, malware is pretty widespread. It steals credit card numbers and other data; if the attacker had a hack for a popular password manager, why wouldn't they go for it?
Yes. If you don't think so, then just tell your browser to remember your passwords and don't bother with another tool.
Maybe I'm paranoid, but it still doesn't feel "safe" to me. Let's assume that KeePassX is truly unbreakable at the moment. I still fear losing my kdbx file, as if someday it will become vulnerable (maybe for technical reasons, or maybe just because of master-password exposure) I'd lose much more than any single of the accounts there: even if passwords there will be outdated already, it will be exposed that all these accounts belong to one person with known identity. All bank accounts, credit cards, email addresses, messengers, accounts on some shady forums. And if passwords are not outdated — oh my God…
It may be unlikely, but it's still putting all eggs in one basket. Just one failure, and you are truly fucked.
It may be unlikely, but it's still putting all eggs in one basket. Just one failure, and you are truly fucked.
I use KeePassX. I think the easiest way to break it (on Linux, at least) would be to get a program running on the user's machine, using a browser exploit or whatever, which would make a copy of the database and also sniff the X keypress events on the KeePassX window to get the master password. I don't know if it has any defence against that.
I guess you have to balance the probability of that kind of breach in Keepassx against the probability of fucking up and forgetting a password or reusing passwords (I still see this) across multiple services.
If you have an eidetic memory and can remember 20 digit random passwords for every service after securely generating them then keepassx increases your risk.
If however you behave like a 'normal' user and use the same one or three passwords on everything I'd estimated keepassx improves your security.
If you have an eidetic memory and can remember 20 digit random passwords for every service after securely generating them then keepassx increases your risk.
If however you behave like a 'normal' user and use the same one or three passwords on everything I'd estimated keepassx improves your security.
FWIW, I do use a password manager. But what you say is pure speculation. I don't see any formula for how should I estimate risks here, and the common narrative amongst security folks is "hooray password managers!". I'm often giving that advice myself, but honestly, I'm doubting it more and more.
The truth is that I don't give a fuck about losing 90% of accounts I use (and I guess I'm not the only one). Many of them I could even give you myself as a birthday present. Using password manager as a rule of thumb would imply that these accounts are as important as the most important ones. Which is nonsense. Even if we discard all the disposable accounts, I still doubt that losing your twitter would hit you nearly as hard as losing your main email account or bank account.
However, exposing that all these trash accounts are mine might make me feel uncomfortable.
If that makes sense, then we must actually stop using the rule "password managers FTW" and start using the rule "consider how important is every given account to you, and treat it accordingly, chosing between several kdbx files". Which is much more complicated rule, obviously. I would even say it creates much higher mental load than remembering several sufficiently complicated passwords.
The truth is that I don't give a fuck about losing 90% of accounts I use (and I guess I'm not the only one). Many of them I could even give you myself as a birthday present. Using password manager as a rule of thumb would imply that these accounts are as important as the most important ones. Which is nonsense. Even if we discard all the disposable accounts, I still doubt that losing your twitter would hit you nearly as hard as losing your main email account or bank account.
However, exposing that all these trash accounts are mine might make me feel uncomfortable.
If that makes sense, then we must actually stop using the rule "password managers FTW" and start using the rule "consider how important is every given account to you, and treat it accordingly, chosing between several kdbx files". Which is much more complicated rule, obviously. I would even say it creates much higher mental load than remembering several sufficiently complicated passwords.
I have a similar fear of a lot of stuff like that
So I just use keepass (synced on spideroak, although I am considering alternatives as they still can't be arsed to do 2FA and I am still sceptical of some of their claims). No browser extension, just the app on my PC (and phone).
If it is a site I use regularly, I actually know the password because I generate it in a memorable way. if it isn't, I unlock the database, find the entry, copy it, and paste it.
To be compromised, I need:
1. My device to already be compromised, at which point I am boned anyway
2. Someone to get a hold of the database through stealing my device: I would know about this and would take action for the more sensitive passwords while filing a police report. The hope is that it would take long enough to compromise the database that I would have time
3. Someone to compromise spideroak and get the database. This is my big worry right now as I won't know about this (see my concerns over spideroak), but I put this in the "it is worth the risk" category as it avoids desync between my devices. But, as mentioned, I am looking in to alternatives or at least an extra layer of security/encryption to add in between.
So I just use keepass (synced on spideroak, although I am considering alternatives as they still can't be arsed to do 2FA and I am still sceptical of some of their claims). No browser extension, just the app on my PC (and phone).
If it is a site I use regularly, I actually know the password because I generate it in a memorable way. if it isn't, I unlock the database, find the entry, copy it, and paste it.
To be compromised, I need:
1. My device to already be compromised, at which point I am boned anyway
2. Someone to get a hold of the database through stealing my device: I would know about this and would take action for the more sensitive passwords while filing a police report. The hope is that it would take long enough to compromise the database that I would have time
3. Someone to compromise spideroak and get the database. This is my big worry right now as I won't know about this (see my concerns over spideroak), but I put this in the "it is worth the risk" category as it avoids desync between my devices. But, as mentioned, I am looking in to alternatives or at least an extra layer of security/encryption to add in between.
I thought I'd make an account on contribute on this issue as the author of a (probably pretty bad) password manager https://slaymaker1907.github.io/password/, source code at https://github.com/slaymaker1907/password-hasher.
There definitely is an issue with some websites having strange requirements, but the way I get around it is keeping an drive sheet with all information used to generate the password (except for the master password of course). This does add some state, but I find that for common passwords I memorize the method of generation very quickly.
There is a central point of failure if the master password is compromised. However, this can be mitigated by first choosing and memorizing a very strong master password as well as versioning passwords by storing the name of the master password used with the rest of the info (though obviously not the master password itself). Additionally, I find the threat model under which such compromises to not be very convincing assuming you choose a strong master password compared to the common case of simply needing to change a password key on the site from linkedin1 to linkedin2 in case of a password database breach.
One weakness of password vaults is that they don't have the advantage of working without access to the vault. While my method can store state as mentioned above, it is very easy to memorize this state, particularly for common/important passwords and has actually saved my bacon before.
Finally, something that I think is a significant strength to a manager but a weakness for managers is that I can and do use my manager for passwords that I need to type out, most often using a feature that translates the password into a password similar to a diceware password (I use a significantly shorter dictionary since dictionary length does not affect the entropy density of a password very much and it makes them easier to type/remember if only using common words). Using this feature, I've been able to create separate passwords for my desktop, laptop, and phone that are both easy to remember as well as having good entropy (when I compute entropy I do assume that an attacker knows the method of generation).
There definitely is an issue with some websites having strange requirements, but the way I get around it is keeping an drive sheet with all information used to generate the password (except for the master password of course). This does add some state, but I find that for common passwords I memorize the method of generation very quickly.
There is a central point of failure if the master password is compromised. However, this can be mitigated by first choosing and memorizing a very strong master password as well as versioning passwords by storing the name of the master password used with the rest of the info (though obviously not the master password itself). Additionally, I find the threat model under which such compromises to not be very convincing assuming you choose a strong master password compared to the common case of simply needing to change a password key on the site from linkedin1 to linkedin2 in case of a password database breach.
One weakness of password vaults is that they don't have the advantage of working without access to the vault. While my method can store state as mentioned above, it is very easy to memorize this state, particularly for common/important passwords and has actually saved my bacon before.
Finally, something that I think is a significant strength to a manager but a weakness for managers is that I can and do use my manager for passwords that I need to type out, most often using a feature that translates the password into a password similar to a diceware password (I use a significantly shorter dictionary since dictionary length does not affect the entropy density of a password very much and it makes them easier to type/remember if only using common words). Using this feature, I've been able to create separate passwords for my desktop, laptop, and phone that are both easy to remember as well as having good entropy (when I compute entropy I do assume that an attacker knows the method of generation).
I don't agree with the author on many of his points. 1 and 2 are "merely" convenience features. Sure, those things make a truly stateless password manager harder to use and a very niche tool, but they're by no means fatal flaws. 3 is a good argument, but storing existing secrets is by definition out of scope for password generators. It is a usability problem, which makes using a truly stateless password generator as the only password manager harder, but still not a fatal flaw. The fourth one is in my opinion the only one which could be called a fatal flaw. It's probably the thing that has to be considered the most before using a master secret password generator.
The hyperbolical title annoys me, but what annoys me probably even more is that the author then recommends (not directly, mentions as his personal choice, but that counts as a "seal of approval" for me) a closed-source cloud password manager, which could possibly be less secure than a password generator.
> Sure, those things make a truly stateless password manager harder to use and a very niche tool, but they're by no means fatal flaws.
If the Deterministic Password Generator does not generate a valid password for a given site, it's certainly a fatal flaw for that site, and a usability nightmare - now I have to remember which sites aren't supported and keep a vault anyway.
And I guess point 2 isn't a fatal flaw until you need to change a password for whatever reason, but after that it becomes quite a problem.
If the Deterministic Password Generator does not generate a valid password for a given site, it's certainly a fatal flaw for that site, and a usability nightmare - now I have to remember which sites aren't supported and keep a vault anyway.
And I guess point 2 isn't a fatal flaw until you need to change a password for whatever reason, but after that it becomes quite a problem.
We both seem to have a different view of what a "fatal flaw" is. For me (especially when talking about a computer security tool), it means a very serious security vulnerability and nothing less. You seem to have a more relaxed view, accepting things that create a bad user experience as fatal flaws, too.
Security isn't an end in and of itself, it's a means to an end. A tool which delivers on security but isn't usable still fails to fulfill its purpose, in the same way an unplugged computer is both secure and useless.
I know there's a group within the security community willing to tolerate poor user experiences, or wear them as a badge of honor, "the price of security" or so to speak. But often I find these are the same people scratching their heads wondering why OpenPGP encrypted email hasn't seen more widespread adoption, or why the Web of Trust failed (or perhaps they think it succeeded), while at the same time bemoaning successful encrypted chat systems like WhatsApp and Signal.
I would argue that user experience is just as important a consideration as the security properties of a tool.
I know there's a group within the security community willing to tolerate poor user experiences, or wear them as a badge of honor, "the price of security" or so to speak. But often I find these are the same people scratching their heads wondering why OpenPGP encrypted email hasn't seen more widespread adoption, or why the Web of Trust failed (or perhaps they think it succeeded), while at the same time bemoaning successful encrypted chat systems like WhatsApp and Signal.
I would argue that user experience is just as important a consideration as the security properties of a tool.
I couldn't agree more. Getting smart but non-nerd friends set up with OpenPGP is truly an eye opener. The rate of adoption is terrible because of that and nothing else.
Even with a GUI like Enigmail, I needed hour long explainathons to make it work for these friends. Smart, borderline brilliant folk.
The same people now use WhatsApp with encryption and don't even know it. That's what a good crypto UX looks like.
I'd love for a google-free, proprietary-free, facebook-free alternative to exist but if the alternative is painful hours of setting up encrypted mail only to have it cease working after two weeks because the user forgot their passphrase, I'm gonna say I don't care too much.
Even with a GUI like Enigmail, I needed hour long explainathons to make it work for these friends. Smart, borderline brilliant folk.
The same people now use WhatsApp with encryption and don't even know it. That's what a good crypto UX looks like.
I'd love for a google-free, proprietary-free, facebook-free alternative to exist but if the alternative is painful hours of setting up encrypted mail only to have it cease working after two weeks because the user forgot their passphrase, I'm gonna say I don't care too much.
"Bad user experience" implies it's still usable but inconvenient, but in fact it's completely unusable if it can't handle passwords for arbitrary sites. You might as well say that having a password manager that can only store one password is a "bad user experience."
Regardless of whether it's "fatal" or not, usability is crucial. If it's impractical or impossible to use in common scenarios, that's a huge flaw.
I use a deterministic password generator so all I have to remember is my master password and default password scheme to get access to all my critical accounts (critical ones generally don’t have silly password requirements). If I were using something that stored passwords and lost my database somehow, I’d lose access to all of those.
"lost my database somehow"
I have mine in Dropbox and at least 3 devices. I'm really not concerned I'll lose it.
I have mine in Dropbox and at least 3 devices. I'm really not concerned I'll lose it.
If I were out of country and my laptop got stolen, for example, I’d lose it. Sure, you can use a separate password for your Dropbox/email/etc. that you remember, but that’s pretty much the same thing as generating based off a master password.
(With the exception of your master password being brute-forceable based on any password you generate, but you just use a master + KDF combo that’s unbreakable to prevent that.)
(With the exception of your master password being brute-forceable based on any password you generate, but you just use a master + KDF combo that’s unbreakable to prevent that.)
Same here. Plus my email uses a different strong password I remember, so if worse comes to worse, I can just reset everything.
I agree with the author's opinion with the master password being compromised, you're done. I have found an elegant solution for managing my passwords with http://masterpasswordapp.com/ the iOS app is a breeze and I also use the export feature to backup my login names, hashed passwords, custom passwords, and stored secrets. This app in particular solves the author's third point. For the second point, I save the iteration X of a password as a stored secret when I need to revoke a password. It doesn't sacrifice the user experience in my opinion.
Another flaw: deterministic password managers are inherently vulnerable to brute forcing-- it's basically like sending your password database to every site you log into. Ideally they use a very expensive KDF, but I've seen implementations that use weak derivations like 10,000 round PBKDF2.
Use a master password that’s impossible to brute-force, then. (128 bits.)
Do people really complain that size is an issue in syncing password data? The author of this article's file was 512 KB, personally mine is 10 KB. That's basically none.
On a related topic, a number of Bitcoin wallets have moved to hierarchical deterministic (HD) addresses and they market that as a positive.
This is a good one (from what I've heard) https://github.com/habnabit/passacre
When will we stop using passwords?
The only deterministic password manager you need is your own mind. Come up with a set of password rules that are generic enough to accommodate all these issues. For example my deterministic password manager might be:
1. random english wordx2 + first 4 letters of registered domain, all caps + remaining lowercase + number of letters in domain (integer) + symbols associated with digits of the integer digits
2. If site doesn't allow special characters, remove them
3. If site requires a shorter password than the generated one, trim the minimum number of characters from the front of the password until the criteria is met.
So, using my above rules my password for Ycombinator would be:
coppercopperYCOMbinator11!!
If the site restricts passwords to max 12 characters, it would become:
Mbinator11!!
1. random english wordx2 + first 4 letters of registered domain, all caps + remaining lowercase + number of letters in domain (integer) + symbols associated with digits of the integer digits
2. If site doesn't allow special characters, remove them
3. If site requires a shorter password than the generated one, trim the minimum number of characters from the front of the password until the criteria is met.
So, using my above rules my password for Ycombinator would be:
coppercopperYCOMbinator11!!
If the site restricts passwords to max 12 characters, it would become:
Mbinator11!!
> If the site restricts passwords to max 12 characters
The problem with this is that most sites are designed by idiots and don't state their pointless password rules on the login page - only on the 'change password' page. So you can be trying your coppercopperYCOMbinator11!! password and thinking "why the hell doesn't this work?", then after 10 minutes you give up and go to change it and see "Your password must be between 8 and 12 characters and contain a symbol." So infuriating.
The problem with this is that most sites are designed by idiots and don't state their pointless password rules on the login page - only on the 'change password' page. So you can be trying your coppercopperYCOMbinator11!! password and thinking "why the hell doesn't this work?", then after 10 minutes you give up and go to change it and see "Your password must be between 8 and 12 characters and contain a symbol." So infuriating.
This is exactly why I started using a password manager, the situation you described is infuriating. Additionally, all it takes is one site with poor security practices having a breach and someone could figure out your scheme and use it to figure out other sites passwords or even seed a dictionary attack with the "shape" of your passwords
GitHub got me every bloody time on my companies account with this because they required a case change iirc.
In the end I just changed it to something stupidly random and shoved it in keepassx, life's too short.
In the end I just changed it to something stupidly random and shoved it in keepassx, life's too short.
That's very true. I forgot to mention that I also have a spreadsheet that has site-specific password rules so that I can do a lookup and see how I need to adapt my generated password.
Maybe what we really need instead of deterministic password generators is an authoritative database that tracks the password rules of all the different sites on the internet so we can easily look it up and/or publicly shame companies with asinine password policies.
Maybe what we really need instead of deterministic password generators is an authoritative database that tracks the password rules of all the different sites on the internet so we can easily look it up and/or publicly shame companies with asinine password policies.
> I forgot to mention that I also have a spreadsheet that has site-specific password rules so that I can do a lookup and see how I need to adapt my generated password.
So you do have a password manager.
> Maybe what we really need instead of deterministic password generators is an authoritative database that tracks the password rules of all the different sites on the internet
I'm glad to hear you volunteering to look up all of these policies, and keep them up to date!
So you do have a password manager.
> Maybe what we really need instead of deterministic password generators is an authoritative database that tracks the password rules of all the different sites on the internet
I'm glad to hear you volunteering to look up all of these policies, and keep them up to date!
First, your proposed scheme relies on doubling words to get complexity without imposing too much of a tax on the user. But because passwords must be reasonable to type, that rule (and any rule like it --- I get that the "key" in this scheme is in part the weird rules you come up with) limits you to smaller words, which can very quickly be searched.
Worse, an attacker who sees one of your passwords has a pretty decent shot at brute forcing the rules you use, and an attacker who sees two of them has the rules and has totally cracked your scheme.
To get real entropy from english word passwords, you have to use several different words. In each password. Which: nobody is saying that's a bad idea. They're saying: you should just have 1Password do that for you, because keeping all those passwords in your head is a chore, and normal people cheat and reuse passwords.
Worse, an attacker who sees one of your passwords has a pretty decent shot at brute forcing the rules you use, and an attacker who sees two of them has the rules and has totally cracked your scheme.
To get real entropy from english word passwords, you have to use several different words. In each password. Which: nobody is saying that's a bad idea. They're saying: you should just have 1Password do that for you, because keeping all those passwords in your head is a chore, and normal people cheat and reuse passwords.
> Worse, an attacker who sees one of your passwords has a pretty decent shot at brute forcing the rules you use, and an attacker who sees two of them has the rules and has totally cracked your scheme.
If an attacker is specifically targeting me and thinking about my passwords, there's not much I can do at that point. Password security in general kind of relies on attackers scanning huge quantities of credentials and going for the low hanging fruit.
Plus, I still don't get why 1Password is better than a password generator on the 4th point. I get that yes you need 2 things (both the master key and the ciphertext), but how does that protect you? The cipher text is available to anyone who logs in. If I get your 1Password credentials, what's to stop me from logging into 1Password.com as you?
If an attacker is specifically targeting me and thinking about my passwords, there's not much I can do at that point. Password security in general kind of relies on attackers scanning huge quantities of credentials and going for the low hanging fruit.
Plus, I still don't get why 1Password is better than a password generator on the 4th point. I get that yes you need 2 things (both the master key and the ciphertext), but how does that protect you? The cipher text is available to anyone who logs in. If I get your 1Password credentials, what's to stop me from logging into 1Password.com as you?
1Password isn't a web-based password manager, it's an offline one that has a syncing component. Syncing is traditionally done either over WiFi (so no exposure to attackers), Dropbox, or iCloud. More recently 1Password now has an optional subscription model that gets you syncing + all updates to the app on all platforms. But the new built-in syncing uses a separate Account Key, which you provide along with your master password the first time you set up syncing on a particular device, and then you never use the account key again (until you have to set up a new device). This means you can store the account key in whatever secure manner you want without needing ease-of-access, and it means you won't ever accidentally type your account key into the wrong place and expose it to an attacker.
So basically, if you use 1Password's built-in syncing, the attacker has to compromise your machine to get at your vault, just as they would have to do if you didn't do any syncing at all. If you use a third-party service for syncing (e.g. Dropbox, iCloud) they have to compromise that service. And of course in both cases they still need your 1Password master password.
So basically, if you use 1Password's built-in syncing, the attacker has to compromise your machine to get at your vault, just as they would have to do if you didn't do any syncing at all. If you use a third-party service for syncing (e.g. Dropbox, iCloud) they have to compromise that service. And of course in both cases they still need your 1Password master password.
Even for a cloud-based manager like Lastpass, you would have 2FA turned on, so an attacker with just your master password still wouldn't be able to log in. (Although obviously you would still change the master password if it were compromised.)
> If an attacker is specifically targeting me and thinking about my passwords, there's not much I can do at that point.
Have really long passwords that are extremely random on a bit-by-bit basis and doesn't have a snowball's chance in hell of containing a dictionary word (which are the blindingly killer flaw in your formula). Like: 6vRmÓ£æp¥£{&XèñgäÐë¸pH©Þ|÷g¸jn§/¥ÔÎpV4fÎ or ò\f4¬Ð³ &{W+ãÄçÏ)æý½06Ýzȯ+µ>få²9Æð:WÚuÂ
> Plus, I still don't get why 1Password is better than a password generator on the 4th point.
Because you have credentials that are 100% externally independent of each other. Only you have access to the plaintext passwords (the only way they are related) and you define the terms on which the ciphertext is distributed.
Have really long passwords that are extremely random on a bit-by-bit basis and doesn't have a snowball's chance in hell of containing a dictionary word (which are the blindingly killer flaw in your formula). Like: 6vRmÓ£æp¥£{&XèñgäÐë¸pH©Þ|÷g¸jn§/¥ÔÎpV4fÎ or ò\f4¬Ð³ &{W+ãÄçÏ)æý½06Ýzȯ+µ>få²9Æð:WÚuÂ
> Plus, I still don't get why 1Password is better than a password generator on the 4th point.
Because you have credentials that are 100% externally independent of each other. Only you have access to the plaintext passwords (the only way they are related) and you define the terms on which the ciphertext is distributed.
That is massive overkill.
128 bits of security is way more than sufficient. 23 characters (uppercase, lowercase, numbers) already gives much security.
Honestly, 128 bits is already overkill. An attacker that determined is probably quite proficient at rubber hose cryptography.
The point of PW manager is to prevent compromise from spreading. Not to keep a motivated NSA out of your PC.
128 bits of security is way more than sufficient. 23 characters (uppercase, lowercase, numbers) already gives much security.
Honestly, 128 bits is already overkill. An attacker that determined is probably quite proficient at rubber hose cryptography.
The point of PW manager is to prevent compromise from spreading. Not to keep a motivated NSA out of your PC.
I know, but that's a good property to have, it's easy to do, and the extra costs are insignificant.
It's a useless property to have, and the extra costs make it much harder to transcribe by hand. Never mind the fact that using non-ascii is asking for compatibility problems.
Honestly, diceware[1] is probably an even better choice, though it sometimes fails symbol count requirements.
[1] http://world.std.com/~reinhold/diceware.html
Honestly, diceware[1] is probably an even better choice, though it sometimes fails symbol count requirements.
[1] http://world.std.com/~reinhold/diceware.html
1Password doesn't ordinarily store your database (although I can't speak to the more recent team/cloud features). It's up to you to decide how to make them available to different devices, via Dropbox e.g.
So, yes, if the attacker has access to your Dropbox and your master password, you're screwed, but that's a very high bar to hurdle.
So, yes, if the attacker has access to your Dropbox and your master password, you're screwed, but that's a very high bar to hurdle.
> If an attacker is specifically targeting me and thinking about my passwords, there's not much I can do at that point.
You could use a password manager…
You could use a password manager…
A password like that would probably be guessed by a good password cracker pretty quickly.
I've taken the liberty of following your procedure for an un-named domain. If anyone's got a password cracker running, I'd be interested how long it takes to break this SHA256 hash: dae640f98b6894d2f6eab5755b22918be46b0d219ea10d3ceea06ebe538a75d1. Post once you've guessed it.
Just use 'pwgen -s 22'; it generates 128-bit passwords, which will never be guessed.
I've taken the liberty of following your procedure for an un-named domain. If anyone's got a password cracker running, I'd be interested how long it takes to break this SHA256 hash: dae640f98b6894d2f6eab5755b22918be46b0d219ea10d3ceea06ebe538a75d1. Post once you've guessed it.
Just use 'pwgen -s 22'; it generates 128-bit passwords, which will never be guessed.
I too am interested to see how long it takes assuming the attacker knows the generator ruleset (which he will have had to work out previously from two plaintext passwords of mine).
Still, I don't think it's that easy to figure out the ruleset of a good password generator if you make it obscure enough.
For example:
Amazon: NovemberAlphaies12#
Facebook: KiloFoxtrototto16&
What's the ruleset?
Answer: Phoenic alphabet of last + first letter of domain + italian number representing total letters in domain backwards + integer sum of the digits on either side of each digit in the Italian number + symbol representing sum of the digits of the previously calculated integer repeated until reduced to one digit.
Seems like way too much work for an attacker to try to figure out.
Still, I don't think it's that easy to figure out the ruleset of a good password generator if you make it obscure enough.
For example:
Amazon: NovemberAlphaies12#
Facebook: KiloFoxtrototto16&
What's the ruleset?
Answer: Phoenic alphabet of last + first letter of domain + italian number representing total letters in domain backwards + integer sum of the digits on either side of each digit in the Italian number + symbol representing sum of the digits of the previously calculated integer repeated until reduced to one digit.
Seems like way too much work for an attacker to try to figure out.
Frankly, the phonetics were trivial. So it's really...
Amazon: ies12# Facebook: otto16&
"Otto" made me think 8, and that led me to "sei" (I read stuff upside down when reading to my kids, so I flip letter orders easily). It didn't take long to figure out those were the length of the site. So now we're down to....
Amazon: 12# Facebook: 16&
These follow a pattern (digit digit symbol), so even if I didn't notice that the symbols were only those above digits There are about 2000 possible choices. Or 11 bits of entropy.
I didn't understand your number scheme, but I probably don't need to.
Amazon: ies12# Facebook: otto16&
"Otto" made me think 8, and that led me to "sei" (I read stuff upside down when reading to my kids, so I flip letter orders easily). It didn't take long to figure out those were the length of the site. So now we're down to....
Amazon: 12# Facebook: 16&
These follow a pattern (digit digit symbol), so even if I didn't notice that the symbols were only those above digits There are about 2000 possible choices. Or 11 bits of entropy.
I didn't understand your number scheme, but I probably don't need to.
Yup that wasn't hard at all. Also, security researchers / consultants / ___hats solve these kinds of puzzles all the time for their work and hobby. Friends I have in that business are insanely good at this sort of thing. Because apparently people always think they're so clever. One told me on multiple cases doing whitehat security consulting they studied the desk+office of the sysadmin for a bit (no post-its), pull some Sherlock Holmes magic (I don't know really) and guessed the password in 5-10 tries (no I didn't quite believe it either, but otoh this guy really doesn't like bragging nor had any reason to lie about).
Oh and if I understand the number scheme correctly:
> integer sum of the digits on either side of each digit in the Italian number
that means, when the number is "otto", meaning 8, the "digits on either side" are 7 and 9, which when you sum them, equal 7 + 9 = (8 - 1) + (8 + 1) = 8 + 8 = 16, so it's really a complicated way of saying "double that number" ... :-)
Oh and if I understand the number scheme correctly:
> integer sum of the digits on either side of each digit in the Italian number
that means, when the number is "otto", meaning 8, the "digits on either side" are 7 and 9, which when you sum them, equal 7 + 9 = (8 - 1) + (8 + 1) = 8 + 8 = 16, so it's really a complicated way of saying "double that number" ... :-)
> Seems like way too much work for an attacker to try to figure out.
I dunno, seems like way more work to come up with, maintain, and actually use the generator. Seems easier to just click a bunch in my vault to generate and copy, although I guess you're protected from vault-theft?
Given your example, I had already figured out all the way up to ies/otto are probably foreign numbers (more specifically, otto looks like 8 and 16 looks like double of 8) before even seeing that you just gave the answer away.
I dunno, seems like way more work to come up with, maintain, and actually use the generator. Seems easier to just click a bunch in my vault to generate and copy, although I guess you're protected from vault-theft?
Given your example, I had already figured out all the way up to ies/otto are probably foreign numbers (more specifically, otto looks like 8 and 16 looks like double of 8) before even seeing that you just gave the answer away.
Give me some time with him and a $5 wrench an I can "steal" his "password vault" - https://xkcd.com/538/
What do you mean by "integer sum of the digits on either side of each digit in the Italian number"? Your italian number is a word, not a sequence of digits. It looks to me like that number is really just the number of letters in the domain multiplied by 2. And the rest of that password scheme is actually rather trivial to deduce (assuming you can recognize italian numbers).
It's a word that represents a series of digits. "Otto" represents 8, tredici represents 13, etc
Yes, I know that Otto is Italian for 8. But even if I convert the italian word to the number, it doesn't make sense, because "8" doesn't have digits on either side of the digit so there's nothing to sum up.
Seems like kind of a lot of work to go through every time you want to log onto a site too, compared to just copying and pasting from your vault. (Or using a browser plugin, depending on your personal convenience/security trade-off preference.)
For unsalted hashes, they tend to be uncrackable if they don't show up in a simple google search.
I think a password manager (minus some of the scary bits like browser plugins) is a much better option than a mental password generation scheme. Maybe some folks can handle this but I think this is a non-ideal general recommendation.
[deleted]
The points that the article makes are right, and people should use conventional passwords over deterministic ones.
But I guess it appeals to a certain small subset of people. For some servers and things that I own I find myself using it sometimes: it turns a relatively strong password into a monster of a password.
Another useful use is that it's good at sharing passwords for things with friends, and for that, it's surprisingly handy.
For the average person however, the disadvantages and the things that could go wrong outweigh the advantages. Keepass is what you should be using.
[0] https://libeclipse.me/visionary/