> By default, CouchDB prior to version 1.2.0
> makes [the /_users] database world-readable.
Note that the current stable version of CouchDB is 1.1.1.
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.
My bad, just realized you aren't e-mail writer or npm admin. Thrown off by gist author.
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.
by default CouchDB gives everyone in the world admin access to your instance, it also doesnt listen on an external interface.
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
I'm wondering what you mean here when you say "on the local device". Are you implying that it is guaranteed that the local device is not exposed? I don't see why you would have to explicitly expose something. The entire instance is exposed by default.
But that has nothing to do with the instance access control or the database access. Changing the listening interface isn't going to magically fix the default security setup.
That's so you can get started developing quickly. You're supposed to configure your users and permissions before you release to the public, and CouchDB helpfully displays a message in Futon saying, "You're in Admin Party mode!" to remind you of this.
Exactly. Which makes it all the more surprising that this could have happened. As soon as you realize your entire instance is left open by default, it should immediately cause you to check the default security settings on the system databases to see if there is a "party" going on there as well.
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.
CouchDB introduced new functionality that allows extra use cases, in particular it can now handle npms use case in a secure manner, just because it didnt handle npms use case before and npm decided to expose that information does not mean it was ever couch's problem.
So just to be clear, this is only a problem for npm package maintainers/admins right? Regular users of npm wouldn't have registry accounts. The headline reads as if the npm client is the risk.
> Reset/change the password of any service that has the same password.
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'.
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.
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.
This doesn't make sense. If you only used that password on 'low-risk' sites, then you are by definition only at very low risk here, right? So go ahead, don't change anything.
If these are random blogs you've signed up for, it probably won't matter too much if someone is able to log in as you. But if you used the same password for your banking you'll probably want to change it.
I don't understand what you are complaining about here. They are warning you that your email address and password might be available to crackers. It then follows that if you are concerned about your security, you change these credentials if you have used them anywhere.
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.
What else? Have a third-party keylog you with 100% success rate, at once. But I kid I kid, either way, if you are compromised, you're going to lose those passwords no matter what.
Stop using the same password anywhere. There are password management system that do encryption client side, have extensions for every major browser, have mobile apps, support two-factor authentication, will prepopulate both registration and login forms and more.
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?
It's the right solution for anyone who actually cares about security. No amount of indignation (and no amount of concern for security in your own work) will prevent third parties that don't care about security from leaking your data wherever possible.
But security across multiple sites _has_ to be fixed on the person end, because it can't be fixed on the system end. If you use the same password for 10,000 sites, there's no fix on the 'system' end to make them all secure, because they're all run by different people. It only takes one of them to fuck up.
I fixed it for myself by using a password manager. I only have to worry about securing the (encrypted) database, which is comparatively trivial.
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.
Good security comes in layers. You are right that you can't control all the layers, but you can make the layers you do control stronger. In today's world (which isn't ideal) that means good password management.
I wish I could do something like this all the time, but there are always some sites that force you to put symbols in your password, or to use both lower and upper case, or to be between 6 and 8 characters long, or whatever weird requirement they thought would be a good idea.
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.
Actually, I don't think you should trust anyone or anything with your passwords except for yourself. Trusting any one system is giving yourself a single point of failure.
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.
Do they work on all platforms (Linux, Windows, Android, MacOX and IOS)? Do they automatically sync (so I don't end up being locked out of one account)? Can I be sure they won't be shut down and thereby leave me cut of from all my online services?
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.
Have you used LastPass? It really works in practice. Syncs instantly to Windows, OSX, Linux, and all major mobile platforms. They were broken into sometime last year, but IIRC they handled the situation superbly, and no passwords were leaked thanks to client-side encryption.
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).
1Password actually has, hidden inside the '1password.agilekeychain' folder, a file called 1Password.html, which can be opened in any modern browser. So you can actually get at your passwords from a Linux machine by opening this .html file and supplying your master password.
I think they call this feature "1Password Anywhere".. I'm surprised they don't talk about it more.
Yes, I love this. I store my 1Password file in Dropbox, so in a pinch, I can log into Dropbox on someone else's computer and grab any password I might need.
>> 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.
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.
Use a local pwd manager like KeePassX or KeePass2, and back up the database to a secure service like Tarsnap or SpiderOak (or both for redundancy).
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).
>Do they work on all platforms (Linux, Windows, Android, MacOX and IOS)? Do they automatically sync (so I don't end up being locked out of one account)? Can I be sure they won't be shut down and thereby leave me cut of from all my online services?
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.
You are right, I don't understand what I out there because I haven't look. Based on your response I have determined that it might be worth looking into, but I don't know which to choose.
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).
>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.
At the time we choose sha1 because the password hashing for creating new user documents was done by the client, often in the browser. At the time there were no good bcrypt implementations in JavaScript. Here is the related bug tracker issue https://issues.apache.org/jira/browse/COUCHDB-1060
That's part of bcrypt's reason for existing. In order to protect against brute-forcing stolen hashes, bcrypt has to be slow enough to make brute force impractical. This isn't a bug; it's a necessary feature. If the server they're running npm on is so old or so overloaded that the slowdown from using bcrypt would even be particularly noticeable, then they have other problems.
The sites that have easily scaled bcrypt include many so large that this argument has basically been mooted, but if you want to nerd around with it: you would hypothetically just turn the cost factor down to accommodate load.
The operations npm needs to log in for are a fairly small percentage of the total. If you need to upload a new version of a package, then that takes a password. If you just need to search for a package, or download its latest version, those don't need authentication. The overhead from using proper slow password hashing would be minimal.
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.
Software which is supposed to be installed by running under sudo a shell script wgetted from a site somewhere without ever reviewing it ends up leaking all passwords.
As surprising as getting lice after you let a hobo sleep in your bed.
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.