[Lorel]

Because the average user will neither understand the implications nor really care, so whichever the default is, is the one vastly more likely to be used.

[Dannii]

But we wouldn't be looking at the password hash every page anyway, only when actually authenticating. All other times we'll use sessions.

[Lorel]

Oh yeah, that is true, had forgotten about that.

[[Unknown]]

Hmm, that's not a bad idea, though I'm not sure the idea of an extra query, or extra table join (and either way, an extra lock) on every page load is entirely desirable.

In any case, I don't think automatically jumping for the biggest and just pushing it into an extra table is worth the apparent extra benefit, there's no real practical need to go beyond SHA-256 anyway.

Yeah, definitely shouldn't hit the password every page view.  Instead, you should have a login hash (cookie, session id, whatever.)  The nice thing about this method is it allows the user to inspect other people who are using their account (see: Gmail does this.)  It's very beneficial, but it means that the login hashes (or sessions, whatever) must needs be in a separate table.

Such a feature is especially important for certain types of software, less important for forums specifically.  If talking about generic login management, this is important IMHO.

-[Unknown]

[Dannii]

I wasn't suggesting just having the session in another table, but also having the password hash in third table. Every page view will need user data, and sessions, but not the actual password hash. The password is normally in the user table but if its size is causing problems it could easily be in a third table.

[[Unknown]]

I wasn't suggesting just having the session in another table, but also having the password hash in third table. Every page view will need user data, and sessions, but not the actual password hash. The password is normally in the user table but if its size is causing problems it could easily be in a third table.

Oh, yes, I agree.  I was partly defending that; the extra table join would be fairly rare, so it makes lots of sense.

-[Unknown]