8 ms·

I am shocked to see a tech literate audience recommending a single algorithm based password. This is pretty basic stuff. Minimize attack surface! With a passwo

I am shocked to see a tech literate audience recommending a single algorithm based password. This is pretty basic stuff. Minimize attack surface! With a password manager, your attack surface is your email, and the password to the manager. You can focus your efforts on securing those two things with 2fa, a hardware device, etc. Every other password can be extremely difficult, and only grant access to an individual service. Compare it to an algorithm, where your attack surface is "every service." If one password is compromised, they all are. Then you have to change them all manually, and remember what's been changed, when. In an age of great open source options like bitwarden, Keepass, and unix pass, there's no excuse for using an algorithm anymore.

arunc 9y ago
Absolutely! I've been using Keepass soccer 2011 and I would highly recommend it to anyone. It's available for Windows, Android (Keepass2Android), Ubuntu Linux (Keepass2) and I have the encrypted database synchronised via Google. Seamless setup and operation. A must have in this modern age.
- faster 9y ago
  On Linux I have recently switched to KeePassxc because it is screaming fast, doesn't require hundreds of megabytes of mono libs, and it is maintained. https://github.com/magkopian/keepassxc-debian https://github.com/magkopian/keepassxc-debian
alangpierce 9y ago
> If one password is compromised, they all are. The point of an algorithm as opposed to a single shared password is that this isn't true. With a basic algorithm, you can avoid automated attacks based on password dumps. With a more complex algorithm, even a determined attacker targeting you would have a really hard time figuring it out. Regardless, it probably would need to be a few passwords, not just one. Also, any good web service will implement rate limiting and other protective measures, so brute force attacks are unlikely to work. The counterargument to "minimize attack surface" is "avoid single points of failure", and that includes both attacks and accidentally losing access to all of your passwords. What if I drop my phone and/or laptop in a lake? What if I forget my master password somehow? What if someone installs a keylogger and gets my master password? What if I accidentally install a malware version of the password manager client that steals my password? Not that I necessarily think that an algorithm is better overall than a password manager, but I think it's not as obvious a decision as you're claiming.
- WorldMaker 9y ago
  Threat model analysis is a complex topic and not everyone has the same threat model to take into account, so there are plenty of aphorisms on every side and the best advice will almost always be "your mileage may vary" and "take with a grain of salt". I see an algorithm as a single point of failure of its own, in the case where a determined bad actor has direct access to your algorithm. At that point you've traded potentially complex passwords for intentionally weak and guessable passwords. Yes, rate limits and other protections may mitigate the threat, but once an attacker has access to your algorithm, they quite possibly have a much easier password cracking game to play. From that perspective, and from the other direction, most algorithms that I've seen make me a single point of failure. I still have to remember a set of weak passwords for every site I use. The algorithm may work to step up the overall complexity and entropy of the weak passwords I use, but I still have to rely on somewhat faulty memory for a series of passwords. Even if that information is easily accessible there's still a lot of variables and forgetfulness that can take place and sometimes it would be me trying to password crack my own passwords (Did I use "facebook" or "fb" or maybe it was "facebook.com"? Was this was password rotation number 12 or 13 or second quarter 2015?). Add in the encoding difficulties to make sure that you can generate a password within the arbitrary complexity requirements of sites themselves (I need a weak password that generates a strong password with no SQL keyword symbols, but at least one capital letter, one emoji, and at least one platitude to an elder god), and you really are just trading one set of complex passwords for an equally arbitrary set of weak passwords (to get the right output I had to use "facebook@2015", transpose odd characters into the Unicode astral plane by divination, and truncate the output to the first 12 code points). A benefit to a password manager is that my own faulty memory isn't itself a part of the threat model. I don't have to maintain a list of weak passwords and/or additional "clean up steps" to feed to an algorithm. On the flipside, I don't know anything about my Facebook password inside my password database. I just copy and paste it when it is needed. There are threat models where that is a benefit. If I'm asked, on the spot, in a location without access to devices which I trust to produce my Facebook password, I cannot, because I honestly do not know it. A judge or over zealous customs agent can't make me remember what I don't know. How likely of a threat that is, I don't know, but it's a threat model that an algorithm can't pass if a judge considers your weak password and knowledge of your algorithm as a password that you know and must divulge. That's of course entirely speculation, there's no US precedent on that yet, but on the flipside there are US precedents protecting "I don't have the right device on me", and most bets are off when your threat model includes a government actor specifically threatening you. But it's still a fringe benefit to certain threat models, ymmv. Not to make a long comment unnecessarily longer, but there are mitigations available based on your threat model to keep a password manager from being a single point of failure: * Use multiple databases with different master passwords for different threat models/risk level assessments/use cases. * Explore options for synchronization systems based on your threat models. For instance, I might have a low risk database synchronized with OneDrive/GDrive/Dropbox, but keep riskier databases in various combinations of Keybase file shares, or Resilio Sync encrypted shares, or a lone self-destructible USB thumb drive primarily kept in a safety deposit box. Similarly many file sharing systems allow you the means to explicitly manage which devices have which files/shares, and you can use that to your advantage as well. (I've stuck with KeePass over the years because it offers a lot of flexibility in how I maintain and sync my constellation of password databases.)
kinkrtyavimoodh 9y ago
It doesn't make sense to talk of an attack surface without talking about the kind of attack. Unless you are a high value target, there is a pretty good chance no one is sitting specifically bruteforcing your passwords. Your biggest source of attack is then a password dump, where you are one of the many millions compromised and now your other accounts (if you reused the same password) are now vulnerable to automated attacks. Even in this case, no one is going to sit around trying to figure out your password algorithm. Even when it comes to compromised accounts, not all of them are equal. For most people, their primary email, banking and social media accounts are paramount, because they are fundamentally linked to their identity (I would be horrified if my FB or GMail were to be compromised, but only mildly miffed if my etsy account where I have made one purchase were to be compromised). All in all, it seems that the most important thing to do is to never reuse a password for ANY of your primary accounts (email, finance, social media, other forms of identity). Ideally for those, don't use an algorithm either. And set up 2FA for these. And for other accounts, preferably never reuse passwords. Whether you use a password manager to manage them or an algorithm should not make too much of a material difference.
- xkcd-sucks 9y ago
  >Unless you are a high value target, there is a pretty good chance no one is sitting specifically bruteforcing your passwords. But... I don't want advice from plebs, I want advice from big winners!
  - kinkrtyavimoodh 9y ago
    you are getting advice from big winners... for plebs :D
- bradknowles 9y ago
  No, but there is malware out there that specifically targets your password manager files. So, that is totally a legit concern.
ecesena 9y ago
I think you're assuming that the algorithm must be reversible, but I don't see why. For example, hash(site|strong_master_password) isn't reversible under reasonable assumptions. If the algorithm is not reversible, "one password is compromised, they all are" isn't true. Only if the master password is compromised, then all your passwords are (but this is exactly the same with any password manager.) The one thing that personally I don't like about vaults is availability of my passwords. You need your password manager (i.e. the app) to get your passwords. I've had multiple situations, typically when traveling, where I didn't have access to my devices, and thus I didn't have the app.
- soccerdave 9y ago
  In your scenario, what happens if you need to change strong_master_password? I’m assuming you now need to change every password on every single site or else remember your new strong password and your old.
  - ecesena 9y ago
    If you have to change your master password, you have to change all passwords. With a vault, if you ever “leaked” your vault file, it’s the same. To me, it’s hard to think to a realistic case where your master password is leaked, but you’re 100% sure your vault file is not.
bradknowles 9y ago
Algorithmic password generation from a single master password works fine up to the point where it doesn’t. What happens when you run into a site that won’t accept your algorithmic generated passwords? Do you fall back to a traditional password manager? If so, then you’ve just increased your attack surface area by an order of magnitude. What happens when you need to change your master password because of a compromise, and now all of your passwords have to change at the same time?
- ythn 9y ago
  > What happens when you run into a site that won’t accept your algorithmic generated passwords? You maintain a public file that has metadata that is meaningless to an attacker. Metadata such as min/max length restrictions, etc.
ythn 9y ago
> Compare it to an algorithm, where your attack surface is "every service." If one password is compromised, they all are. My password for Amazon is "f3cfcb6ZUZ^". What's my algorithm?
- karategeek6 9y ago
  Doesn't really matter because it's too short. Crackable in 10 seconds if the password hashing is poorly implemented. (I assume Amazon implements good hashing, but that's besides the point. Your algorithm generates passwords that are just a bit too short.) https://lowe.github.io/tryzxcvbn/ https://lowe.github.io/tryzxcvbn/ https://blog.codinghorror.com/your-password-is-too-damn-short/ https://blog.codinghorror.com/your-password-is-too-damn-shor...

arunc 9y ago

Absolutely! I've been using Keepass soccer 2011 and I would highly recommend it to anyone. It's available for Windows, Android (Keepass2Android), Ubuntu Linux (Keepass2) and I have the encrypted database synchronised via Google. Seamless setup and operation. A must have in this modern age.

faster 9y ago
On Linux I have recently switched to KeePassxc because it is screaming fast, doesn't require hundreds of megabytes of mono libs, and it is maintained. https://github.com/magkopian/keepassxc-debian https://github.com/magkopian/keepassxc-debian

alangpierce 9y ago

> If one password is compromised, they all are. The point of an algorithm as opposed to a single shared password is that this isn't true. With a basic algorithm, you can avoid automated attacks based on password dumps. With a more complex algorithm, even a determined attacker targeting you would have a really hard time figuring it out. Regardless, it probably would need to be a few passwords, not just one. Also, any good web service will implement rate limiting and other protective measures, so brute force attacks are unlikely to work. The counterargument to "minimize attack surface" is "avoid single points of failure", and that includes both attacks and accidentally losing access to all of your passwords. What if I drop my phone and/or laptop in a lake? What if I forget my master password somehow? What if someone installs a keylogger and gets my master password? What if I accidentally install a malware version of the password manager client that steals my password? Not that I necessarily think that an algorithm is better overall than a password manager, but I think it's not as obvious a decision as you're claiming.

WorldMaker 9y ago
Threat model analysis is a complex topic and not everyone has the same threat model to take into account, so there are plenty of aphorisms on every side and the best advice will almost always be "your mileage may vary" and "take with a grain of salt". I see an algorithm as a single point of failure of its own, in the case where a determined bad actor has direct access to your algorithm. At that point you've traded potentially complex passwords for intentionally weak and guessable passwords. Yes, rate limits and other protections may mitigate the threat, but once an attacker has access to your algorithm, they quite possibly have a much easier password cracking game to play. From that perspective, and from the other direction, most algorithms that I've seen make me a single point of failure. I still have to remember a set of weak passwords for every site I use. The algorithm may work to step up the overall complexity and entropy of the weak passwords I use, but I still have to rely on somewhat faulty memory for a series of passwords. Even if that information is easily accessible there's still a lot of variables and forgetfulness that can take place and sometimes it would be me trying to password crack my own passwords (Did I use "facebook" or "fb" or maybe it was "facebook.com"? Was this was password rotation number 12 or 13 or second quarter 2015?). Add in the encoding difficulties to make sure that you can generate a password within the arbitrary complexity requirements of sites themselves (I need a weak password that generates a strong password with no SQL keyword symbols, but at least one capital letter, one emoji, and at least one platitude to an elder god), and you really are just trading one set of complex passwords for an equally arbitrary set of weak passwords (to get the right output I had to use "facebook@2015", transpose odd characters into the Unicode astral plane by divination, and truncate the output to the first 12 code points). A benefit to a password manager is that my own faulty memory isn't itself a part of the threat model. I don't have to maintain a list of weak passwords and/or additional "clean up steps" to feed to an algorithm. On the flipside, I don't know anything about my Facebook password inside my password database. I just copy and paste it when it is needed. There are threat models where that is a benefit. If I'm asked, on the spot, in a location without access to devices which I trust to produce my Facebook password, I cannot, because I honestly do not know it. A judge or over zealous customs agent can't make me remember what I don't know. How likely of a threat that is, I don't know, but it's a threat model that an algorithm can't pass if a judge considers your weak password and knowledge of your algorithm as a password that you know and must divulge. That's of course entirely speculation, there's no US precedent on that yet, but on the flipside there are US precedents protecting "I don't have the right device on me", and most bets are off when your threat model includes a government actor specifically threatening you. But it's still a fringe benefit to certain threat models, ymmv. Not to make a long comment unnecessarily longer, but there are mitigations available based on your threat model to keep a password manager from being a single point of failure: * Use multiple databases with different master passwords for different threat models/risk level assessments/use cases. * Explore options for synchronization systems based on your threat models. For instance, I might have a low risk database synchronized with OneDrive/GDrive/Dropbox, but keep riskier databases in various combinations of Keybase file shares, or Resilio Sync encrypted shares, or a lone self-destructible USB thumb drive primarily kept in a safety deposit box. Similarly many file sharing systems allow you the means to explicitly manage which devices have which files/shares, and you can use that to your advantage as well. (I've stuck with KeePass over the years because it offers a lot of flexibility in how I maintain and sync my constellation of password databases.)

kinkrtyavimoodh 9y ago

It doesn't make sense to talk of an attack surface without talking about the kind of attack. Unless you are a high value target, there is a pretty good chance no one is sitting specifically bruteforcing your passwords. Your biggest source of attack is then a password dump, where you are one of the many millions compromised and now your other accounts (if you reused the same password) are now vulnerable to automated attacks. Even in this case, no one is going to sit around trying to figure out your password algorithm. Even when it comes to compromised accounts, not all of them are equal. For most people, their primary email, banking and social media accounts are paramount, because they are fundamentally linked to their identity (I would be horrified if my FB or GMail were to be compromised, but only mildly miffed if my etsy account where I have made one purchase were to be compromised). All in all, it seems that the most important thing to do is to never reuse a password for ANY of your primary accounts (email, finance, social media, other forms of identity). Ideally for those, don't use an algorithm either. And set up 2FA for these. And for other accounts, preferably never reuse passwords. Whether you use a password manager to manage them or an algorithm should not make too much of a material difference.

xkcd-sucks 9y ago
>Unless you are a high value target, there is a pretty good chance no one is sitting specifically bruteforcing your passwords. But... I don't want advice from plebs, I want advice from big winners!
- kinkrtyavimoodh 9y ago
  you are getting advice from big winners... for plebs :D
bradknowles 9y ago
No, but there is malware out there that specifically targets your password manager files. So, that is totally a legit concern.

ecesena 9y ago

I think you're assuming that the algorithm must be reversible, but I don't see why. For example, hash(site|strong_master_password) isn't reversible under reasonable assumptions. If the algorithm is not reversible, "one password is compromised, they all are" isn't true. Only if the master password is compromised, then all your passwords are (but this is exactly the same with any password manager.) The one thing that personally I don't like about vaults is availability of my passwords. You need your password manager (i.e. the app) to get your passwords. I've had multiple situations, typically when traveling, where I didn't have access to my devices, and thus I didn't have the app.

soccerdave 9y ago
In your scenario, what happens if you need to change strong_master_password? I’m assuming you now need to change every password on every single site or else remember your new strong password and your old.
- ecesena 9y ago
  If you have to change your master password, you have to change all passwords. With a vault, if you ever “leaked” your vault file, it’s the same. To me, it’s hard to think to a realistic case where your master password is leaked, but you’re 100% sure your vault file is not.

bradknowles 9y ago

Algorithmic password generation from a single master password works fine up to the point where it doesn’t. What happens when you run into a site that won’t accept your algorithmic generated passwords? Do you fall back to a traditional password manager? If so, then you’ve just increased your attack surface area by an order of magnitude. What happens when you need to change your master password because of a compromise, and now all of your passwords have to change at the same time?

ythn 9y ago
> What happens when you run into a site that won’t accept your algorithmic generated passwords? You maintain a public file that has metadata that is meaningless to an attacker. Metadata such as min/max length restrictions, etc.

ythn 9y ago

> Compare it to an algorithm, where your attack surface is "every service." If one password is compromised, they all are. My password for Amazon is "f3cfcb6ZUZ^". What's my algorithm?

karategeek6 9y ago
Doesn't really matter because it's too short. Crackable in 10 seconds if the password hashing is poorly implemented. (I assume Amazon implements good hashing, but that's besides the point. Your algorithm generates passwords that are just a bit too short.) https://lowe.github.io/tryzxcvbn/ https://lowe.github.io/tryzxcvbn/ https://blog.codinghorror.com/your-password-is-too-damn-short/ https://blog.codinghorror.com/your-password-is-too-damn-shor...