As these hacks are becoming more common place, I'd love to hear fellow HN reader's take on their password strategy/management. Many thanks in advance!
I use https://lastpass.com/ for generating passwords. $12/year and works on Linux & Android. Would prefer open source, but nothing else comes close. I tend to generate 32 char passwords with a mix of upper, lower, number, and special. Only a few websites insist on shorter passwords - or have character restrictions.
For 2FA I use either SMS or Authy https://www.authy.com/ Take a look at https://www.turnon2fa.com/ to see which sites support 2FA.
It does make logging in to some frequently used sites a bit of a pain (looking at you PayPal!) but I think it is worth it.
On to unique email addresses. I do this for two reasons.
1. Allows me to easily see where an email has come from & filter if necessary. I can tell if your company has leaked / lost / sold my address.
2. If I have reused a password, a database leak doesn't compromise other sites. An attacker doesn't know the login details for LinkedIn based on my GoToMyPC email.
I tend to use something like lnkdn@ mydomain / gtmypc@ ... / twttr@ ... - but if your mail provider lets you use a catch-all, it can be anything you like.
One word of warning - it really confuses people when you give the email over the phone! I usually say "I'm creating a unique email address for you so that the message doesn't go into spam. Ok? sound of me hitting random keys It's yourcompany@ ...."
Another nice property of this suffix is that one can identify who gave away their email address / which site it was scraped from when receiving spam; not sure where I have seen this written down originally.
Unique, non-guessable, machine-generated addresses are the way to go (do with emails just like password managers do with passwords), but no common person can use those, because they'll need a domain and self-hosted MDA.
E.g.
$ echo "$(echo -en "secretsalt\nsome.example.net" | sha1sum -b | xxd -r -p | base36 | cut -c-8)@me.example.org"
h6t8490d@me.example.org
(Sure, HMAC would be a better idea than this string concatenation, but meh...)
On a linux/unix system, one could use /dev/urandom:
tr -dc '[[:alnum:][:punct:]]' < /dev/urandom | head -16c
One could even put the following function in $HOME/.bash_profile or such
genpw() {
tr -dc '[[:alnum:][:punct:]]' < /dev/urandom | head -${1-16}c
}
LastPass does all of that. And I don't even have to drop into the terminal.
$ pwgen 16 1
siaJa9fohnie9aew
The hunt continues!
It does have browser integration, for both Chrome - ChromeIPass extension, and Firefox - KeeFox extension. Both extension work via KeePassHttp plugin. Works well on Arch Linux.
The "perform autotype" option in KeepassX Linux seems to work well enough for me in Firefox, Chromium and most applications (it basically seems to send <user><TAB><password><ENTER> which usually does the trick--and afaik it has some settings you can tweak when it doesnt, but I never bothered with those).
But if Lastpass works for you, that's cool. Getting to use a password manager in the first place is the most important step, IMHO.
The former reduces the efficiency of your spam filter, the later is not (fully) supported by many websites. AirBnB for example allowed me to set an mail address with a plus character, however, login did not work anymore, so I was locked out and had to create a new account … AirBnB support refused to change my mail address since they apparently did not get the plus character 'trick'.
This way the address can be some-web-app.somecompany.com@yourdomain.tld, you can whitelist *.com@ (or higher up on the subdomain if necessary).
Not sure if this would maintain the efficiency of your (or any) spam filter, but it does avoid the '+' character.
Rep: "Can you verify your email address?"
Me: "er, em-verizon@example.com"
Rep: "Hey, I didn't know you worked for Verizon!"
Me: "no..."
Also, more than one web forum has silently binned me until I removed the domain from my email address. Had one where I could post for a few days, then the admin deleted me and sent that email address a crazy anti-spam rant thinking I was a bot.
I still like using unique email addresses but I make sure they're obscure.
I've been using a catch all domain for at least 15 years. One thing I learned early is to use a subdomain, which avoids getting dictionary spam attacks.
For the last many years, I just forward it to a gmail account, where there is a corresponding filter to label it into an "accounts" group. I get essentially zero spam to this.
Also, I've had multiple times where it confused reps as well. It's kind of funny when it happens, but also sad that having "theircompany@sub.my domain.com" makes them go "oh, did you used to work here or something?".
How do you do this?
I feel like it's almost certain that Lastpass is owned, as are other popular online password stores.
No security is perfect; all you can do is make it more expensive than it's worth to the attacker.
How much would it be worth to have all the passwords to every account of every Lastpass user? Does Lastpass really have the resources and skill to protect something that valuable? Is it even possible?
Lastpass (supposedly) stores the encrypted password vault, never the decrypted. Decryption occurs on the users end. You would need to either have a keylogger on the target users machine to grab their master password, or compromise the software. Neither is impossible, but both are a little harder than simply break in and access Lastpass's storage.
I say supposedly because I do not know of any 3rd party verification.
When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
"I feel like it's almost certain that Lastpass is owned"
https://lastpass.com/support.php?cmd=showfaq&id=6926
"LastPass says they never receive my Master Password. Don’t I send it to the LastPass servers when I log in?
No, when you login to LastPass, two things are generated from your Master Password using our code discussed previously before anything is sent to the server: the password hash and the decryption key. This is all done locally.
The password hash is sent to our servers to verify you. Once verified, we send back your encrypted Vault. We are only sent your hash, not your Master Password.
The decryption key, which NEVER leaves your computer, is then used to decrypt your Vault once it comes back."The point was "all a hacker would really have to do is to intercept when you put your decryption key in and send it off to their own server" (emphasis added).
However this is more about keeping the Lastpass software secure than it is about keeping the encrypted user vaults secure. The documentation you quoted really obscures this by use of the passive voice, casting the end-user somehow as an active agent deliberately doing all the encryption/hashing and sending, implying that they are in full control :) Try this on for a change:
"LastPass says they never receive my Master Password. Doesn't the LastPass Software send it to the LastPass servers when I log in?
No, when you login to LastPass, the LastPass Software generates two things when you give it your Master Password, before the LastPass Software sends anything to the server: the password hash and the decryption key. The LastPass Software does all this locally.
The LastPass Software sends your password hash to our servers to verify you. Once verified, our server sends back your encrypted Vault. The LastPass Software only sends your hash to our server, not your Master Password that you just entered into the LastPass Software.
The LastPass Software then uses this decryption key, which should NEVER leave your computer, to decrypt your Vault once it comes back."
-
The above is IMHO a much better way to word the same documentation, since it doesn't try to gloss over a rather important part of the attack surface. It's not really fair to on the one hand congratulate a user for being security-aware enough to use a password manager, but then ignore this part. Good security software documentation should proudly present the last few exposed parts of the attack surface, especially if they are minor ones, so that a user can assess the limits of their trust--there are always limits, no sense in pretending there aren't, and it's better to know them so that the user gets to decide what they're okay with.
That reasoning only holds if it's in fact significantly harder to compromise the software than it is to "simply break in and access Lastpass's storage". If you believe that might be possible, then the security of your password vault basically depends on the differential difficulty compared to "simply break in and compromise the login form / browser extension / update channel to make it do <whatever>".
My point is not that this would be easy, rather that if someone went as far to break in and grab the storage[0], given the sheer value of the data, the barrier to go a step further and compromise the software isn't big enough to make me go "okay well that's all right then, that might happen, but this surely won't".
The biggest difference in risk between those two scenarios is that yes some cybercriminal that is "just poking around" might easier stumble upon access and just grab the vault than to set up a compromised login form and wait--not so much more difficult but just more effort.
[0] which I agree is fair to trust Lastpass to have properly encrypted, cause if you can't trust the people you pay $12/year to keep your most sensitive data secure, then who can you trust?
Also, use 2FA wherever available. Google Authenticator is good enough.
Store your backup codes somewhere safe (your keepass db, for example. Although that goes a bit counter to the point of 2FA, if someone cracks your keepass db, you're pretty screwed regardless).
When you switch your device, you have to set up your 2FA credentials again …
Also, as other people mentioned, it's technically possible to back up your initial seed.
SMS auth is a disgrace, when we have 2fa standards.
Get anonymous identity and VPN.
Using KeePassX/LastPass/1Password is a bit problematic. They become a single point of failure. Someone can get my master password (https://github.com/cxxr/lostpass) or can pwn LastPass. To improved that my passwords becomes <last_pass_gen_pass> + <random_nonce_that_i_know_how_to_generate_in_my_head> + <helper_password>
I divided accounts into tiers:
Tier0: The most important account: Macbook, Gmail, Github Tier1: Still important, but not as much as Tier0: Youtube Tier2: I don't really care. Tier3: Testing accounts for local dev server: Single simple password like qwerty1234.
I just need to remember 5 passwords(Gmail, Macbook, Github, LastPass, helper password). I think this strategy gives a nice balance between connivance and security.
echo "secret123|google" | sha1sum
echo "secret123|facebook" | sha1sum
EDIT: it is best to write a script for this
Can somebody with sense please explain if this is a good or bad idea?
It's a cute trick, but I don't think it really scales well for the number of accounts we tend to have these days, and the frequency with which passwords must be changed due to hacks, password aging policies, validation ("must have 1 punctuation character"), etc.
As for entropy, it's limited by the master password, and whatever obscurity the hashing and service name provide. If you have a short master password, you're not getting the as much uniqueness as you might think by looking at the length of the hash output.
In addition, I try use different E-Mail adresses whenever I sign up, a catchall makes sure they end up in the same inbox. This might not stop a sophisticated targeted attack, but it should throw off a lot of automated runs since the email they got is seemingly not used at another service. A litte obscurity to strengthen the rest of my security ;)
It's basically a SHA1 of an alias and a secret (similar to amelius' approach https://news.ycombinator.com/item?id=11932624). I've also started recoding the extension for Windows and other DEs: https://github.com/jhasse/pwcalculator
I like this as a solution as it's not dependent on any third parties like cloud services, its pretty portable and I have a unique password per site, so I'm not really that bothered when the inevitable breaches happen.
Downside to this approach is that I have to have a device which has the password safe to hand to use it (there are clients for Windows/Linux/Mac/iOS/Android), I'm responsible for managing the file and if I lose the file + passphrase I'm stuffed :)
Wherever two-factor is available, it's turned on. Usually through my phone, which has its own passcode and won't display text messages on my screen. I'm curious as to how secure this really is, but I suspect this is reasonably difficult enough to hack that someone would have to be targeting me specifically to be able to reliably pull my SMS token out of the air and match it up to my login before I used it within a few seconds and invalidated it. If someone decides to target me specifically, I have bigger problems.
For my email, my banking sites, and all the things that I really would rather someone else please not log into, I have a unique password. This is still long and easy to type; the only advantage of these passwords is that I am sure to not share them in any modified form anywhere else on the internet, which protects against these sorts of cross-site password theft attacks. (Even for my shared password I have a pattern that makes it uniqueish, but that pattern is simple enough that a human could probably reverse engineer it.)
The only real exception to this strategy is things that can be password-less, though that carries its own weirdness. All of my remotely-accessible SSH servers use private key authentication and have passwords enabled for sudo, but don't allow SSHing in using that password. (So they are effectively single-factor for login and userland access, which can still do a lot of damage but requires a computationally difficult key, and two-factor for root access.) This carries its own issues; I have to keep my private key files somewhere, and even if I use multiple keys for each machine I log in from, all it takes is one rogue login to hose my server. I either put all my eggs into one basket by using some sort of encrypted store, or I spread out my attack surface, increasing its complexity, and decreasing the chance that I'll have successfully patched all the holes up. I also don't like that there's no way I could reasonably memorize a private key, so the option of NOT storing it kind of doesn't exist. At best I can try to protect the key in some way.
Would love to find a credit card which allowed me to offer up fake billing details - obviously the CC provider would need to know who I was, but there's no reason who I'm paying needs to.
https://www.passwordstore.org/
It simply manages gpg-encrypted files in a directory hierarchy. Very flexible to set up whatever organization makes sense for you.
I find it suits my needs.