Previous Entry Share Next Entry
Release 0.3.23
jducoeur wrote in querki_project
Today's release was a minor one from the user-features perspective, but critical. Major changes:

Login is now finally Real: up until now, Querki's logins were all hardcoded into the system configuration -- while I was testing, that was good enough, and easy to set up when I was starting out. Now, it's finally working for real: login looks up your email address in the Identity Table, and authenticates the password through there. (Yes, the password column is salted and hashed.) Login is principally by email address, but if you have a Querki handle, you can use that instead. (Handles are probably going to be a paid-user perk, but they'll be free and grandfathered in for Alpha and probably Beta users.)

Introduced User Levels: we're not doing anything with them yet, but there is now an official distinction between, eg, "admin", "paid user", "free user" and so on. That will allow me to add admin features that I will need for managing Alpha.

Renamed "Display Text" Property to "Default View": now that we have Search in place, I could do this without as much danger of blithely breaking the world. Thanks to mindways for the name suggestion -- I believe the semantics are spot-on.

Now, to continue pushing on towards Alpha. This is mainly going to consist of an entirely new Invitation system, which I'm going to talk about in my next post...

  • 1
Sanity check: what hash? I mean, I have no need to know details; but the question is, are you using a slow hash, like bcrypt, or a fast hash, like sha1? Slow hashes make offline dictionary attacks much harder; and they shouldn't slow down your site too much, because you don't check passwords that often.

(I figure there's a good chance you know this, because I know it from Ars Technica articles—security is not a domain I've had to worry about for most of the past decade—but I thought I'd ask just in case.)

(No reason not to talk details -- the thing's open-source, so it wouldn't take a good programmer long to figure all this out. Security should never depend on obscurity.)

At the moment, I'm using Java's bog-standard "PBKDF2WithHmacSHA1", which seems to be the consensus standard for the JVM. Everything I've read says that, while SHA1 on its own is miserably inadequate, PBKDF2 on top of it, configured with a decently large number of iterations, is at least halfway decent, good enough to get started. It's not proof against a determined attacker with serious hardware resources, but if properly salted against rainbow tables, it should frustrate the routine hackers.

(Not that I'm planning on anybody getting access to the password table in the first place, of course -- the advantage of having Aaron as CIO is that he's much better about security issues than I, and he forces a lot of best practices on me. But belt and suspenders and all that.)

My current tentative plan is to move to scrypt, which seems to be most folks' pick for the current best-in-class, but not quite yet -- my understanding is that scrypt's strength is its intense memory usage, and I don't want to do that while we're still running on a single server. (Clustering is on the near horizon, but is a big enough project that I'm not holding up Alpha for it. I really should write up a post about where the architecture is, and where it is going.) Once we're running on at least half-a-dozen parallel machines, so I'm less concerned about the problem, I'll be more willing to dedicate the CPU and memory to scrypt.

And thanks for checking. I *have* been reading into this quite a bit in the past few months, but it was pretty new to me before that. Always best to check that I'm asking the right questions...

OK, glad to hear you're on top of it. :-)

...yeah, PBKDF2 with 10,000 iterations sounds pretty strong: it supposedly cuts multicore+GPU attackers down to a few hundred attempts per second.

  • 1

Log in

No account? Create an account