This is an interesting idea. I think you could take it a little further though.

How about databases explicitly disallow direct comparison or materialization of any field named 'Password', 'Passwd' etc. I'm aware that this would be a breaking change, and would require overrides to support legacy software. That said, the defaults would lead developers to a secure by default mindset. If n00b dev1 realizes that s/he can't store a password and get it back again, they go looking for why and find that the only way is to call something like:

  SELECT IsPasswordValid(Password, @Password) FROM Users
  UPDATE Users
  SET Password = StorePassword(@Password)

Edit: I realize that there are security issues with the suggested sql. A PAKE is probably necessary.

Any good tutorial on how to deal with passwords? In a site of mine I generate a salt with UUIDv4 and generate a sha512 of the passsword+salt and store both the salt and hash. When the user authenticates I regenerate the hash and check. This is good, right? I still don't know how to deal with cookies/sessions though. And have no idea how basic http auth works.

I'd search myself but I'm afraid to find a "bad" tutorial.

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 :)

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.

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

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

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.

This sounds like such an obviously great idea that I don't know how I haven't heard it before. Can someone who understands how databases are built explain why this isn't an obviously great idea?

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.

> Or hashing could be done on the client side.

Only if you use a proper PAKE. A vanilla password hash is still a bearer token on the wire.

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 = '[email protected]' 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.

Note that this approach can expose the user entered password in application debug logs, MySQL's slow queries log (if you're not using bind variables), etc.

That's true currently of any HTTP-level logs

Yes, it is, but that doesn't excuse doing it here.

If there are other ways to confirm whether a user exists or not (signup email check for example) --

I would add that the 'bonus' of not informing of the correct error provides minimal security gain and hurts usability.

> If there are other ways to confirm whether a user exists or not (signup email check for example) --

This would be a bug. There should be no way for someone with my e-mail address to determine if I use any particular service.

Postgres has plenty of awesome data formats (JSON! Polygon areas!) that are rarely used, either because developers aren't aware, or Hibernate/ORMs don't support it, or devs only use features that are in all databases, you know, in case someone decides to switch dbs.

Almost as you said below: Passwords are long overdue. They are lost, written down, or 1password becomes the single point of failure, keylogged, recoverable by email, prone to brute-force or more clever attacks, the user types them in the username field (my security teacher did exactly that in front of the whole class while saying it), or worse, in the group chat window that just popped up...

We needed Persona. We needed an open marketplace for password replacement. Bash & SSH have pretty much gotten rid of passwords. I'd bet a year in prison that Mozilla has been served an NSL and ordered to shut down the project.

That is a decent idea I've never heard of before. Have you tried submitting an issue to various database issue trackers?

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.