Database leak exposes 3.3M Hello Kitty fans

No, because even this would be a total cock-up. Don't give anybody your password, and just can't mess it up. So i'm not really in favour of fixing backends at all. I think the password problem is entirely the browser vendors reponsibility. Solid password authentication already exists in TLS (which you need anyway), it's just not widely implemented or exposed via browser UIs.

There are too many vested interests from the big players, where the hope is that deliberately making authentication ever more burdensome for users will just lead them to give up and select 'login with Facebook/Google/Live' and hand them the keys to the kingdom.

The elephant in the room is what you return when you SELECT.

My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should simply fail.

One thought is that it puts the computational load of verifying user-provided passwords in your database tier, rather than in your application tier, where it exists today. Let's say that right now, you have a 200ms computation necessary to verify a bcrypt-secured password. If you have that in your application tier, you can easily scale that horizontally with more CPUs if necessary. It may be a bit more difficult to scale CPU capacity in the database tier.

However, another approach would be extension of the database's client-server protocol and driver(s) such that the hash verification occurs within the application tier (as part of the driver). Or, moving further along that path, the field could be annotated in your ORM, exposing special set and verify methods. But at that point, you're very close to the current condition, where the hashing occurs within your web application framework.

Or hashing could be done on the client side.

Just use one of the existing key derivation functions. Scrypt and bcrypt should be good enough for most use cases, but you may want to google a bit before settling on one.

What you describe is easy to bruteforce using oclhashcat. Use scrypt or bcrypt or pbkdf2, in that order of preference.

There's no way to beat around the bush: No, it is not good. It's better than a lot of sites, but it's still nowhere near good enough.

The key is speed: it's too fast. Far faster than you need it to be. Fast enough that attackers could attempt very large numbers of passwords per second.

What you want is something slow, to slow down the attackers.

Probably the most popular choice is bcrypt, and you can't go wrong making that decision. In some environments you may need something more standardised / accepted, in which case you want to look at PBDKF2. There's also scrypt, which is a bit stronger than bcrypt, but a bit newer.

_Any of these three are uncontroversial choices._ Using any of them is better than using just about anything else, and the gap between each of them is much smaller than the gulf between those three and schemes such as yours.

Once you've picked one you also need to tune it: make it as slow as you can bear. If your users won't be driven away by login taking a whole second, then make it take a whole second! The key is making it slow.

---

One broader piece of advice: Don't reinvent the wheel when it comes to security things. Passwords, sessions, and so on, you should be looking for well-supported, maintained, high-quality libraries that have been vetted for design and implementation mistakes. There's libraries out there to solve these problems, if you aren't a security expert you should be using them :)

Start here: http://codahale.com/how-to-safely-store-a-password

There's now an actual standard for this: https://password-hashing.net/

The catch is one of "what platform are you using", as bindings are somewhat limited.

Oh I see. Assumed it was like mysql/mariadb where secure_installation by default asks to remove access from outside.

It also implies frontend server includes the DB, typically a sysadmin would de-couple it so this shows lack of experience.

> i.e. the default configuration

The default configuration for MongoDB is to listen on localhost only. Someone changed the configuration if it was listening on a public IP.

Why is everybody immediately making these types of diversion responses regarding relational datastores to mongodb breaches? Mongo has popularity and 2 fixable issues that make the exposure numbers outweigh those of every other datastore right now.

1. There is no password prompt during installation. This was the same problem many relational databases had back in the day with default user credentials. Today, I don't know of a single relational datastore that comes with default credentials during installation. (ignoring things that shouldn't go to production like homebrew) Individually, they all said it was a "security threat" and did something about it.

2. Things like MMS or other offering from MongoDB itself expect you expose your nodes externally so they can manage things for you. This can easily be made secure... but its contradictory in nature. It suggests to somebody who probably doesn't know what they're doing on the IT or DevOps fronts to do something more easily dangerous than not... just so they can sell their vendor services to you. Its a recipe for disaster but its also easily fixable with a few design changes on their side.

> the mostly universal opinion ... downloading and investigating people's private data that was illegally obtained and distributed is okay

[citation needed]

It's interesting to look at? I don't think most people looking at the leaks are trying to profit (exception of people exploiting people based on the data). Ad systems however, are always looking at the data as a way to increase profits.

Often vegetarians will eat meat that was served to them by mistake. They don't want to contribute to demand for meat products, but if one has already been served to them it can't be taken back. There's no further harm in eating it.

Crooks will look at it to see what they can get out of it. Passwords, email, blackmail material. If nobody benevolent looks at it would we ever know what was actually leaked?

After previous leaks, the data has been looked over to produce lists of compromised accounts which at least one website lets you search to know if your account was in the leak (Kotaku/Gawker leaked my shit years ago). The data can be used to provide stats on the most common passwords.