npm (Node's package manager) leaks all user password hashes and salts
gist.github.com
gist.github.com
> By default, CouchDB prior to version 1.2.0
> makes [the /_users] database world-readable.
I assume that "world-readable" in this case also means world-readable over HTTP, if your Couch server isn't firewalled.
Update: If you've already filled out npm's "reset password" form, but haven't received an email yet, @isaacs says that the email bot might be backlogged by a couple hours.
Deliberate passing the buck or accidental bad choice of words?
Deliberately exposing anything to the web should come with lots of... wait for it... deliberation. The npm guy is a core community member; this incident shows a lot of sloppiness and doesn't inspire faith.
There isnt any confusion over 'sensible defaults' because sensible defaults dont really exist, the way people use CouchDB is very varied, if you are going to expose any data to the world you need to know what that entails, in this case I believe it was done to help people run their own npm instance and couch introduced new functionality in order to handle that case in a more secure way.
tl;dr I dont believe this is a couch issue in the slightest, purely an issue with how npm was built
tl;dr I dont believe this is a couch issue in the slightest
That seems like a slightly generous interpretation...
If you want to expose anything, you have to do it very explicitly and as linked there are warnings and advice about doing so.
npm effed up is all.
https://github.com/iriscouch/npm/blob/master/doc/cli/registr...
He doesn't suggest that the password hash is per-user private data. I don't think he caught onto this issue until later.
Besides the misinformation, I disagree about CouchDB's involvement in this mistake. There's no common use case in which using the _users database for human-created passwords wouldn't be a bad idea. For machine-created passwords that are long, it might be OK.
It's just like the Rails issue from a few days back: insecure by design. Only with Rails there was an obvious workaround, which was used by many Rails shops (I was quite surprised to find that it wasn't as many as I thought). With CouchDB you basically have to skip out on one of CouchDB's major features.
Well this bullshit has to stop. I use the same password on most 'low-risk' sites, and I can't remember them all (can you remember all the blogs you have signed up for?) so I can't 'change the password on all other sites because CouchDB uses a retarded security scheme'.
So what? That's the trade off you signed up for when you decided to use the same password for 'low risk' sites.
Here's the actual problem.
You sound rather defeatist for someone who's on Hacker News. Here's a tip. Create a pattern of sorts, example follows:
1. Choose a keyboard sequence: say qwerhjkl
2. Pick 1 < 5 < N. Use the first N characters of the site/service, followed by N. npm3qwerhjkl
There are so many ways you can do this. It's fast, easy, yet completely unintelligible to a human. My personal favorite is to convolve it with a spatial pattern, like typing the password out in Dvorak while using qwerty. Or use each finger in sequence, with each finger taking a choice of the four keys near it depending on where the site name's letters are (i.e. ycombinator = 1xefmko.qwe).
I find it also helps to have three standard versions - a standard that may contain special characters, one that is guaranteed not to, and second that acts as a fail-safe in the event the password has tight length or character constraints.
It only sounds convoluted - the rules are simple and easy to memorize, and damnably difficult to see a pattern in outside of brute-forcing.
Once you've broken dictionary attacks I think the next goal should be to increase length as easily a possibly.
Personally I prefer a standard prefix/postfix with with a variable competent generated from the site name or url.
This allows you to use different standard substings for different sites depending on their importance. Since the substring can include the dictionary breaking portion you are free to use less complicated generation patterns for the variable part.
The end result should be longer passwords.
Not to be snarky or to minimise the impact of yet another critical security bug, but does anyone get the impression that instead of righteous fury the appropriate response to these situations is to assume insecurity and provide information to other parties with the prior understanding that compromise is not just a theoretical possibility? It stands to reason that for every compromise we actually hear about, there is plenty going on behind the scenes that never even emerges from obscurity. That doesn't make it less dangerous.
Encrypt your remote data, make it useless for anyone to compromise anything you have provided to anyone else through password management with autogenerated complex passwords for every last service you use. Use all the tools available to mitigate the impact of a provider security breach.
Most of all, if you can't deal with the potential fallout of a provider's security failing, simply do not use them in the way that requires you to rely absolutely upon their security that you do not have oversight or control over.
It's EASIER to use a password manager with very strong, unique passwords than it is to not. Not to mention the eliminated risk of "where did I use this password that just got leaked".
How many more leaks and how many more times do I have to repeat this to get people to take it seriously. Every time people whine that it's too much work (it's not, it seriously isn't) but they don't think about how much of a hassle these leaks can be. NPM, PS3, BitCoin reserves, how many more diverse things need to be hacked for people to realize that its simply a matter of time?
You might as well say, "Stop being human." That's never the right solution to network problems that require high reliability.
I'm still vulnerable to the "supercomputer cracks your encryption" attack but that's orders of magnitude better than having my bank account compromised because some blog leaked my universal password.
Edit: If there were no fix, changing all of your passwords would be the only option besides letting the Internet at large have your accounts. Unless I'm misreading you.
$ echo password@$(echo nonce+hackernews.com|md5sum|tr [[:lower:]] [[:upper:]])
password@FB85C2F638706D4BE4192391387C2879
And since I can't (and don't want to) remember which sites enforce which restriction, I end up having to resort to writing my passwords in a text file.
Oh and hash functions won't output symbols or banned chars. They output numbers and you can choose to represent those numbers in whatever mad way that you want, typically as hex, ie. letters and digits.
The length might be a problem but there's nothing to stop you truncating the hash.
The used hashing mechanism is quite weak. If you don't have a long high-entropy master password, it should be feasible for a site-owner to brute-force your master-password based on the site-specific password.
What product is going to solve every corner case you can throw at it?
FWIW my example string contained symbols, upper, lower and digits:
password@FB85C2F638706D4BE4192391387C2879
And what do I do when the password manager is, inevitably, broken into?
It seems to me that a password manager is a great theoretical idea, but they don't really work in practice.
Yes, yes, yes (make a text backup, another supported feature, also every device would have a local copy, etc, etc)
>And what do I do when the password manager is, inevitably, broken into?
Why? Because you left it open and unencrypted? How about, just not doing that? Mine is locked every time I close the browser. If you're paranoid only unlock it when you need to enter a site. Not only that, but even if your master password is "stolen" somehow... it's a single password to change and your other passwords are secure. Again, if you're paranoid, you'd at least have a list of the sites that you have to worry about.
>It seems to me that a password manager is a great theoretical idea, but they don't really work in practice.
It seems to me that you really don't understand what is out there or what you're talking about. These things are true of not just LastPass but other solutions as well.
But by broken into I mean hacked, as in 'due to $INSECURE_FEATURE $SOMEBODY copied the entire database and now have all your passwords'. If somebody breaks into my home and steals my computer, I can call the police (and activate the tracking beacon).
Like I said, it's all locally encrypted. I trust (at least LastPass's) model well enough that I'd be happy to let you have a copy of all the data LastPass has for me on their server.
1password works on all of those except Linux. I believe LastPass works on all.
> Do they automatically sync?
1password syncs to Dropbox.
> Can I be sure they won't be shut down and thereby leave me cut of from all my online services?
Yes, if it syncs to something like Dropbox that has a local copy.
> And what do I do when the password manager is, inevitably, broken into?
The same thing you have to currently do if you're using one password everywhere?
I think they call this feature "1Password Anywhere".. I'm surprised they don't talk about it more.
> Yes, if it syncs to something like Dropbox that has a local copy.
This isn't necessarily true. If Dropbox was legally coerced to do so, they have the technical means to erase any file in your Dropbox from each machine as it connects to the network. I believe they already do a best-effort version of this if someone stops sharing a folder with you. All it would take is a court order to remove a file and all its backups from Dropbox's server, which might happen without even targeting you specifically because Dropbox does deduplication and doesn't encrypt your data.
This may be very unlikely, especially with an encrypted password database unique to you, but it's not impossible. At least we can presume that a general takedown or Dropbox becoming unavailable for whatever reason won't cause this to happen.
You do need to remember a couple of passwords, though. Your LastPass password and your primary e-mail password (in the unlikely event that LastPass becomes unusable and you need to reset passwords on all of your other accounts).
That way you avoid storing your passwords in a huge hacking target like LastPass, but still get 90% of the utility (no web form autofill, gotta copy and paste, but that's not too intrusive since most sites keep you logged in indefinitely now).
EMAIL: - Take the time to learn a couple of strong passwords for your email. You can almost always reset forgotten passwords, don't forget that. - Insure you have two-step login enabled for your email service should it be supported, and make sure you have all the secret questions answers memorised. - By the way, secret questions are stupid. It's easier for me to get you to tell me your mothers maiden name and birthday than it is to make you tell me your password. - Have a phone number and other emails associated with your main email accounts, if possible.
OTHER STUFF: - Never use the same password at one site. - Develop a personal "scheme" that lets you form passwords easily.
For example, combine a couple of short words/sentences you know, some numbers related to the service (e.g. got an 'i' in the URL? add 99), add some #@~!"£$ with similar rules. Develop something that works for you. Now when you approach a service you use, you should already have a solid idea what the password is.
- Write down "reminders" but not actually passwords on paper. Don't label them. Write other things that don't make sense. Put it in your desk draw. - Can't do that? PGP/Truecrypt/bcrypt/whatever a text file.
Forgot your password? Press the forgot password button.
So it's "bullshit" that they've warned you of this?
When you use the same password in multiple sites you are taking the risk that any of those sites could be hacked and your password is put out in the open. CouchDB's security scheme isn't at fault, your personal security scheme is.
I am not so sure of that.
And evidently the CouchDB guys agree with me, because they switched to using PBKDF2 for password storage -- essentially, iterate SHA several thousand times to make it slower.
As surprising as getting lice after you let a hobo sleep in your bed.